Thanks for answer, Steve.
May be you help me find way to attach Windows CryptoAPI to OPENSSL1.0.0 TLS
methods.
I am using OmniOrb4.1 and want replace current SSL transport implementation(in
OPENSSL) with CryptoAPI calls.
-Original Message-
From: Dr. Stephen Henson st...@openssl.org
To:
* Eisenacher, Patrick wrote on Tue, Feb 23, 2010 at 12:30 +0100:
[...]
The selection of a trust anchor is a matter of policy: it
could be the top CA in a hierarchical PKI, the CA that
issued the verifier's own certificate(s), or any other CA in
a network PKI.
And no, I don't need
On Sun, Feb 28, 2010, ashuahen wrote:
I am using AES_CBC with padding (using PKCS#5 to pad) on C++ side:
AES_set_encrypt_key( keyBuf, 128, key )
keyBuf contains key string
key is the key generated
Block Lenght is 16
AES_cbc_encrypt (ibuf, obuf, lenpad, key, iv, AES_ENCRYPT)
ibuf =
I am using OpenSSL 0.9.8l from
http://www.slproweb.com/products/Win32OpenSSL.html
I link to these libraries for debugging:
C:\OpenSSL\lib\VC\ssleay32MTd.lib
C:\OpenSSL\lib\VC\libeay32MTd.lib
And these ones for release:
C:\OpenSSL\lib\VC\ssleay32MT.lib
C:\OpenSSL\lib\VC\libeay32MT.lib
I compile
Tim Hudson wrote:
Can you make a small test program which demonstrates this behaviour?
Typically some cleanup code is being missed when this is sort of thing is
raised; however a bit of test code makes it fairly easy to track down
using a
combination of the malloc
Does anyone else have any speculation on why I'm failing the padding
check? I'm definitely using the public exponent and public modulus from
the CAVP sample request file. After conversion to BIGNUMs, the bytes in
the d, top, and dmax fields of each BIGNUM seem to be correct.
I don't see
On Mon, Mar 01, 2010, Paul Suhler wrote:
Does anyone else have any speculation on why I'm failing the padding
check? I'm definitely using the public exponent and public modulus from
the CAVP sample request file. After conversion to BIGNUMs, the bytes in
the d, top, and dmax fields of each
