Sureware / PKCS#11 engine
I am developing a software which will make use of the AEP Sureware KeyPer. I don't have one for testing pusrposes, but I know that the AEP Sureware KeyPer has a PKCS#11 interface, so what I am doing now is developing my software using the PKCS#11 engine, testing it with a smartcard. I've seen that OpenSSL comes with a sureware engine. Do you know if the sureware engine works fine with this version of Sureware? Once it was produced by Baltimore, and the engine is written by a developer from Baltimore, but now it is produced by another company... Or is it better to use the PKCS#11 engine? I know, the best thing to do is to give it a try, anyway it is not very easy to me to find one. and i think I will only have a little time to test my software with it. What would you sugget? Thanks Giovanni __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: revoking expired certificates
What if my cert happened to expire 1 month later? Would that mean if someone did compromise my cert and sent signed e-mails before it expired (but *after* I added to the CRL), then after it expires, that signed e-mail would appear VALID - as it wouldn't be in the CRL anymore? No, it will be in the CRL. The rules say that a revoked cert must appear in (at least?) one CRL after its expiration period. Without that, as you point out, there is a gap during which the cert could appear valid. /r$ -- Rich Salz, Chief Security Architect DataPower Technology http://www.datapower.com XS40 XML Security Gateway http://www.datapower.com/products/xs40.html XML Security Overview http://www.datapower.com/xmldev/xmlsecurity.html __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
x509_verify_cert and revocation checking
Just for curiosity, why openssl checks revocation status of the
certificate before checking whether it has expired or not? E.g. if one
certificate in a certificate chain has expired then X509_verify_cert
should fail (which it actually does), but before failing it checks the
revocation status. I would like to know this is what we wanted or it is
an error.
X509_verify_cert
{
ok = ctx->check_revocation(ctx);
if(!ok) goto end;
/* At this point, we have a chain and just need to verify it */
if (ctx->verify != NULL)
ok=ctx->verify(ctx);
else
ok=internal_verify(ctx);
}
Regards,
Amar
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Playing nice between OpenSSL and Microsoft libraries with 3DES pass phrases?
I have a requirement to implement cross-platform 3DES encryption (driven by a text pass phrase) between Microsoft and various UNIX platforms.Both platforms use the vendor supplied libraries: In the case of UNIX that's OpenSSL, and in the case of Microsoft it's the Windows routines declared by . Invoking 3DES on either platform looks straightforward, except for the transformation of the pass phrase into a key. On the Microsoft platform, I can hash the pass phrase which is directly passed into the 3DES processing. The OpenSSL environment provides DES_string_to_key() but its use is discouraged in place of a cryptographic hash function. .. but the man page doesn't define a standard procedure to do so. So, I am open to suggestions (read: NEED HELP) as to how to consistently use a pass phrase with both libraries. -ahd- -- "OS/2, the system so good you can't install it just once" -- Dave Gomberg __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Hardware crypto speed anyone?
Markus Lorch wrote: Marton, I think your card is simply slow. I've done similar test (RSA only) using an IBM 2058 eServer Cryptographic Accelerator (ICA), which has 5 ultracyper crypto processors on it. The machine is a dual xeon 2.4 box running Linux 2.4.20 I used openssl 0.9.7b with IBM's ibmca engine and libica, threading activated, both CPU's at 100% with the hardware engine deactivated, minimal main CPU usage with the engine activated. For 2048bits the ICA could do almost 70 times as many signing operations than the two main CPUs could handle. No, it's only a factor 1.5, see below. /opt/src/openssl-0.9.7b/apps # ./openssl speed rsa Doing 512 bit private rsa's for 10s: 11089 512 bit private RSA's in 9.99s Doing 512 bit public rsa's for 10s: 120057 512 bit public RSA's in 10.00s Doing 1024 bit private rsa's for 10s: 2124 1024 bit private RSA's in 10.00s Doing 1024 bit public rsa's for 10s: 40108 1024 bit public RSA's in 10.00s Doing 2048 bit private rsa's for 10s: 347 2048 bit private RSA's in 10.02s Doing 2048 bit public rsa's for 10s: 11800 2048 bit public RSA's in 9.99s Doing 4096 bit private rsa's for 10s: 52 4096 bit private RSA's in 10.14s Doing 4096 bit public rsa's for 10s: 3321 4096 bit public RSA's in 9.99s OpenSSL 0.9.7b 10 Apr 2003 built on: Thu Sep 25 17:47:01 EDT 2003 options:bn(64,32) md2(int) rc4(idx,int) des(ptr,risc1,16,long) aes(partial) idea(int) blowfish(idx) compiler: gcc -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DOPENSSL_NO_KRB5 -DL_ENDIAN -DTERMIO -O3 -fomit-frame-pointer -m486 -Wall -DSHA1_ASM -DMD5_ASM -DRMD160_ASM available timing options: TIMES TIMEB HZ=100 [sysconf value] timing function used: times signverifysign/s verify/s rsa 512 bits 0.0009s 0.0001s 1110.0 12005.7 rsa 1024 bits 0.0047s 0.0002s212.4 4010.8 rsa 2048 bits 0.0289s 0.0008s 34.6 1181.2 rsa 4096 bits 0.1950s 0.0030s 5.1332.4 The following run of the speed program measures RSA operations per host cpu time, not per elapsed time; in other words it gives the performance of an hypothetical system using an accelerator card with infinitely high speed. /opt/src/openssl-0.9.7b/apps # ./openssl speed -engine ibmca rsa engine "ibmca" set. Doing 512 bit private rsa's for 10s: 6942 512 bit private RSA's in 0.43s ^^ This is host CPU time, the elapsed time is 10s +/-. Doing 512 bit public rsa's for 10s: 30522 512 bit public RSA's in 0.50s Doing 1024 bit private rsa's for 10s: 2139 1024 bit private RSA's in 0.32s Doing 1024 bit public rsa's for 10s: 19278 1024 bit public RSA's in 0.55s Doing 2048 bit private rsa's for 10s: 529 2048 bit private RSA's in 0.23s Doing 2048 bit public rsa's for 10s: 6651 2048 bit public RSA's in 0.14s RSA sign failure. No RSA sign will be done. 31561:error:8606706E:ibmca engine:IBMCA_MOD_EXP:mexp length to large:hw_ibmca.c:1051: RSA verify failure. No RSA verify will be done. 31561:error:04077077:rsa routines:RSA_verify:wrong signature length:rsa_sign.c:154: OpenSSL 0.9.7b 10 Apr 2003 built on: Thu Sep 25 17:47:01 EDT 2003 options:bn(64,32) md2(int) rc4(idx,int) des(ptr,risc1,16,long) aes(partial) idea(int) blowfish(idx) compiler: gcc -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DOPENSSL_NO_KRB5 -DL_ENDIAN -DTERMIO -O3 -fomit-frame-pointer -m486 -Wall -DSHA1_ASM -DMD5_ASM -DRMD160_ASM available timing options: TIMES TIMEB HZ=100 [sysconf value] timing function used: times signverifysign/s verify/s rsa 512 bits 0.0001s 0.s 16144.2 61044.0 rsa 1024 bits 0.0001s 0.s 6684.4 35050.9 rsa 2048 bits 0.0004s 0.s 2300.0 47507.1 Relating the measured numbers to 10 sec elapsed time gives following results: sign/s verify/s rsa 512 bits 694 3052 rsa 1024 bits 214 1928 rsa 2048 bits 53665 Redo the measurement with the -elapsed option, it should reproduce the just given results. Ciao, Richard -- Dr. Richard W. Könning Fujitsu Siemens Computers GmbH __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Playing nice between OpenSSL and Microsoft libraries with 3DES pass phrases?
On Mon, Jan 26, 2004, Andrew H. Derbyshire wrote: > I have a requirement to implement cross-platform 3DES encryption (driven by > a text pass phrase) between Microsoft and various UNIX platforms.Both > platforms use the vendor supplied libraries: In the case of UNIX that's > OpenSSL, and in the case of Microsoft it's the Windows routines declared by > . > > Invoking 3DES on either platform looks straightforward, except for the > transformation of the pass phrase into a key. On the Microsoft platform, I > can hash the pass phrase which is directly passed into the 3DES processing. > The OpenSSL environment provides DES_string_to_key() but its use is > discouraged in place of a cryptographic hash function. .. but the man page > doesn't define a standard procedure to do so. > > So, I am open to suggestions (read: NEED HELP) as to how to consistently use > a pass phrase with both libraries. > There are a few other complications which you may not be aware of. Under CryptoAPI you can't directly set the actual key. There are various tricks involving things like exponent of one RSA keys to get round this though. CryptoAPI does some weird stuff when the key length exceeds the digest length. This is true for 3DES since SHA1 is 160 bits and it uses 192 bits for 3DES. This is however documented in that some postings to the CryptoAPI mailing list documented it. OpenSSL allows you to set the actual key and has support for various standard key derivation algorithms like PKCS#12 or PKCS#5v2.0 . Its advisable to use the EVP interface on OpenSSL rather the the low level routines. It isn't a good idea to just make up a key derivation algorithm: there are lots of these about that are horribly insecure. Many don't even use a salt whcih makes them vulnerable to attack. What this means for 3DES is that there isn't a common password based key derivation algorithm. The solution would be to implement one in either CryptoAPI or OpenSSL. For example you could implement PKCS#5 v2.0 under CryptoAPI or even the odd 3DES derivation algorithm under OpenSSL. Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Funding needed! Details on homepage. Homepage: http://www.drh-consultancy.demon.co.uk __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Playing nice between OpenSSL and Microsoft libraries with 3DES pass phrases?
> There are a few other complications which you may not be aware of. But I am terrified that they exist. I'm a generic multiplatform network applications type, not a crypto geek. > Under CryptoAPI you can't directly set the actual key. There are various > tricks involving things like exponent of one RSA keys to get round this > though. I realized this. I feed it the hash, it makes a key. Cool, unless you need to replicate the "it makes a key" using OpenSSL. > OpenSSL allows you to set the actual key and has support for various standard > key derivation algorithms like PKCS#12 or PKCS#5v2.0 . (I'd rant about the OpenSSL man pages, but I'd be off my own topic.) Since my first post, I've tripped PKCS#5v2.0; I guess my primary comment would be that the OpenSSL DES/EVP pages don't make it clear what is used for what ... for example that PKCS includes the key generation routines that may not be public key. > Its advisable to use the EVP interface on OpenSSL rather the the low level > routines. I realize that. But I didn't see the obvious path way to do using the low level or EVP routines. > It isn't a good idea to just make up a key derivation algorithm: there are > lots of these about that are horribly insecure. Many don't even use a salt > which makes them vulnerable to attack. I wasn't planning to. I know of weaknesses (which I won't advertise) in exactly what I'm doing, but it's a major improvement on the "simply XOR against a fixed key" which the current implementation does. I prefer not add more *unknown* weaknesses. (All this is a mere fallback to running the whole sebang over SSL from client to server -- and I'm using SHA1 passwords when possible, which is whenever not calling external authenication facilities.) > What this means for 3DES is that there isn't a common password based key > derivation algorithm. The solution would be to implement one in either > CryptoAPI or OpenSSL. For example you could implement PKCS#5 v2.0 under > CryptoAPI or even the odd 3DES derivation algorithm under OpenSSL. Have you seen the Secure Programming Cookbook for C and C++ (by Viega & Messier, from O'Reilly)? I'm looking at recipe (section) 4.10, which has PKCS#5 for Windows and OpenSSL.Of course, that leads off other parts of the book, so back to my reading ... -ahd- __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Playing nice between OpenSSL and Microsoft libraries with 3DES pass phrases?
Do yourself a favor and just have one of the OpenSSL crypto experts do the function on a consulting basis. Will save you a lot of time, and misery! And it will be crypto correct. Ken > > There are a few other complications which you may not be aware of. > > But I am terrified that they exist. I'm a generic multiplatform network > applications type, not a crypto geek. > > > Under CryptoAPI you can't directly set the actual key. There are various > > tricks involving things like exponent of one RSA keys to get round this > > though. > > I realized this. I feed it the hash, it makes a key. Cool, unless you need > to replicate the "it makes a key" using OpenSSL. > > > OpenSSL allows you to set the actual key and has support for various > standard > > key derivation algorithms like PKCS#12 or PKCS#5v2.0 . > > (I'd rant about the OpenSSL man pages, but I'd be off my own topic.) > > Since my first post, I've tripped PKCS#5v2.0; I guess my primary comment > would be that the OpenSSL DES/EVP pages don't make it clear what is used for > what ... for example that PKCS includes the key generation routines that may > not be public key. > > > Its advisable to use the EVP interface on OpenSSL rather the the low level > > routines. > > I realize that. But I didn't see the obvious path way to do using the low > level or EVP routines. > > > It isn't a good idea to just make up a key derivation algorithm: there are > > lots of these about that are horribly insecure. Many don't even use a salt > > which makes them vulnerable to attack. > > I wasn't planning to. I know of weaknesses (which I won't advertise) in > exactly what I'm doing, but it's a major improvement on the "simply XOR > against a fixed key" which the current implementation does. I prefer not > add more *unknown* weaknesses. > > (All this is a mere fallback to running the whole sebang over SSL from > client to server -- and I'm using SHA1 passwords when possible, which is > whenever not calling external authenication facilities.) > > > What this means for 3DES is that there isn't a common password based key > > derivation algorithm. The solution would be to implement one in either > > CryptoAPI or OpenSSL. For example you could implement PKCS#5 v2.0 under > > CryptoAPI or even the odd 3DES derivation algorithm under OpenSSL. > > Have you seen the Secure Programming Cookbook for C and C++ (by Viega & > Messier, from O'Reilly)? I'm looking at recipe (section) 4.10, which has > PKCS#5 for Windows and OpenSSL.Of course, that leads off other parts of > the book, so back to my reading ... > > -ahd- > > __ > OpenSSL Project http://www.openssl.org > User Support Mailing List[EMAIL PROTECTED] > Automated List Manager [EMAIL PROTECTED] __ Support InterSoft International, Inc. Voice: 888-823-1541, International 281-398-7060 Fax: 888-823-1542, International 281-398-0221 [EMAIL PROTECTED] http://www.securenetterm.com __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Playing nice between OpenSSL and Microsoft libraries with 3DES pass phrases?
- Original Message - From: "Kenneth R. Robinette" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, January 26, 2004 2:46 PM Subject: Re: Playing nice between OpenSSL and Microsoft libraries with 3DES pass phrases? > Do yourself a favor and just have one of the OpenSSL crypto experts > do the function on a consulting basis. Will save you a lot of time, > and misery! And it will be crypto correct. I'd love to. Constraints prevent such a course of action. (If we doing this crypto correct, we would using only SSL connections and not having to worry about half the problems I've got.) __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: normal vs openssl sockets
If you are using OpenSSL then you must pass in the native sockets to the OpenSSL BIOs. The BIOs as they are called are the abstracted version of the I/O descriptor used to access the socket by the SSL library. You are not going to get out of coding for the platform specific connection/listen, you still need WinSock and socket()/accept() calls. See the BIO_new_socket man page. Regards, Fred Crable > -Original Message- > From: Darren McDonald [mailto:[EMAIL PROTECTED] > Sent: Thursday, January 22, 2004 9:38 AM > To: [EMAIL PROTECTED] > Subject: Re: normal vs openssl sockets > > > What I ment was when using ssl. > > >>> [EMAIL PROTECTED] 1/22/04 03:39:53 >>> > OpenSSL "sockets" are built on top of winsock, or whatever your native > > platform is. If you don't need SSL, etc., then just write > your code to > > use your local socket API directly. > /r$ > -- > Rich Salz, Chief Security Architect > DataPower Technology > http://www.datapower.com > > XS40 XML Security Gateway > http://www.datapower.com/products/xs40.html > > XML Security Overview > http://www.datapower.com/xmldev/xmlsecurity.html > > > __ > OpenSSL Project http://www.openssl.org > > User Support Mailing List[EMAIL PROTECTED] > > Automated List Manager [EMAIL PROTECTED] > __ > OpenSSL Project http://www.openssl.org > User Support Mailing List[EMAIL PROTECTED] > Automated List Manager [EMAIL PROTECTED] > __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
