Re: Safe signed certificate generation during server installation ?
* David Schwartz wrote on Mon, Sep 24, 2007 at 07:42 -0700: Storing some fingerprint of a certificate or public key locally in some trusted place (such as a local file system) seems to be quite secure (should be the same level as having a CAs root certificate in a file), however, I'm not sure if this works with OpenSSL which seems to expect to be able to verifiy the whole certificate chain up to the root certificate even if intermediate certificates are locally avialable. As far as I know / understood - please correct me if I'm wrong! Remember, he's using his own server and client code. So he can disable certificate checking in OpenSSL and do his own. [...] After the SSL session is established but before any important data is exchanged, perform your own verification step that meets your own security requirements. In this second step of verification, you can exchange public keys, certificates, challenges, responses, and so on. Each side can verify what it is talking to on the other side by whatever mechanism you want. Ahh, yes, ok. But the result would not be SSL but something-SSL-based, right? Well, by this someone could use e.g. symetric keys for authentication - if it fails the session could be discarded, right. Again, the only serious potential gotcha is a MITM who might replace the single SSL session with his two (one to each end) and proxy the second step and then takeover or monitor the data connection. Ensuring that each side's SSL_get_finished matches the other side's SSL_get_peer_finished should be sufficient to prevent this. (Include these in the signed objects you exchange.) I'm not sure if I understand ...including these If, for instance, each side (and only them) share a secret 3DES key and use it for some challenge-response-authentication inside a SSL tunnel then I would assume that this is secure because it would be secure without the SSL and thus should be with it. beside the fact, that I don't see the advantages of SSL here. A MITM could forward this authentication, so based on the challenge-response some session key needs to be derived to be used as encryption key (to make the MITM unable to read or change the forwarded data). Is that right so far (in such a setup, what is the SSL for BTW)? So your point is that some property from the original certificate (lets say some hash or so) could be included in the extra authentication to detect a MITM (or whatever faked) certificate? In that case, SSL would be used basically for encryption only, right? Are such schemes used in practice? Or is it more a theoretical idea showing what would be possible? oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Safe signed certificate generation during server installation ?
* Victor Duchovni wrote on Mon, Sep 24, 2007 at 21:05 -0400: Whatever you want to call it. The point is, if the client can't validate the self-signed cert, you need some other way to make sure the server and client have opposite ends of the *same* SSL connection, rather than ends of two SSL connections to a MITM. A simple way to do this is to compare each sides 'finished' with the other side's 'peer finished'. No, the challenge is key management. TLS is just fine. What do you mean, `TLS is just fine'? Doesn't it depend on the requirements? I think, for key management itself (like transferring secret keys), TLS is not suited. TLS AFAIK is limited to one session key (someone could wish one for authentication and a second one for encryption). Also, because of asymetric keys, keys cannot be derived (which would be possible for instance with 3DES keys). Revealing a secret keys can be used to decrypt pre-recorded chiphertext (AFAIK). TLS can be at most as good as the PKI (so in standard PC browsers and the many different CAs that are installed with the many different policies and stuff this probably is not so much). Ohh, and not to forget that the X.509 (just BTW, there even is a v1 :)) subject names are more or less `informal'. Some CA may require a `Ltd' company to contain the `Ltd' in the subject, others may not or may allow to omit the country. Today something like a `Extended Validation Certificate' exist which indicates that there are fun-level-security certificates that can only be used for the same level of SSL strength :-) If CAs don't solve key management for you, roll your own key management, but use existing protocols. If for some application (not meaning only a computer program) the usual CAs are inappropriate, maybe for this application PKI is not suited at all, could happen. Maybe I missunderstand you, but I think, when SSL/TLS is not suited then it should not be needed, even if with OpenSSL such a nice lib is avialable :) Or do you mean `existing protocols' in general? Like `do not invent your own cryptosystem' to avoid designing weaknesses but favor well-analysed systems? I would like to see GSSAPI support in TLS (so would Microsoft and a few others). This addresses key management, without requiring secondary protocols, and ties into the dominant standard intra-mural authentication system. This would use a certificate-less cipher-suite, but the point remains that authentication should be within TLS, not an add-on. ohh, now I got so many questions :) According to Wikipedia, this is an API to standardise how the application uses something like e.g. OpenSSL, is that correct? Or is it something completely different? You wrote `GSSAPI support in TLS' - this would be a standard or would it be an implementation? How would it help with key management? Do you mean in this can you could use any standard GSSAPI-using key management tool? You said `without requiring secondary protocols', but wouldn't the implementation of that API be nothing else than such a secondary protocol (OCSP or so)? What is meant by certificate-less cipher-suite? A protocol not using certificates, such as SSL without X.509 certificates at all? How would the authentication work? Did I understand correctly that GSSAPI means, that applications do not depend on the implementation (vendor) of some `GSSLIB' but that the applications can `talk' via GSSAPI only to some peer if it uses the same implementation (vendor), because this implementation can use whatever message to transmit tokes? Sorry for my boring noob questions but maybe the one or other could be answered by some URL/link? oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses
RE: intermediate CA configuration
Please send me your extensions file, CA cert/Key and the CSR you are using for your intermediate. I am assuming that what you have so far is for testing purposes. Otherwise, I would not ask for the CA key (obviously). Send them to me as a zip file and I'll take a look. Don. [EMAIL PROTECTED] Donald E. Bynum Director, Architecture Integration O: 703.668.5616 | M: 301.367.2072 | www.networksolutions.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of mallika Sent: Friday, September 21, 2007 1:39 AM To: openssl-users@openssl.org Subject: RE: intermediate CA configuration I have given the command openssl x509 -req -days 365 -in intermediate.csr -CA root.certkey -CAcreateserial -out intermediate.crt -extensions usr_cert -extfile /etc/sll/openssl.cnf after creating the root CA, the root.certkey is having key and crt files.Is this command enough for creating the intermediate CA. if i create a user certificate with this intermediate CA.In SSL authentication it is giving error 24,Unknown CA. In client machine i installed all the certificates root CA and Intermediate CA and client certificate.It is showing clear hierarchy.ROOTintermediate.client. i copied the root and intermediate certificates in /etc/ssl/certs and did c_rehash.BUT with the intermediate client certificate ,client could able to authenticate and showing the ERROR 24 and UNKNOWN CA.if i provide any other root ca , the client can be able to authenticate with that root CA client certificate.please help me... Bynum, Don wrote: This should be good for most purposes. Note the basicConstraints attribute of pathlen. Unlike the root CA which has no pathlen, the intermediate has a pathlen of 0. ### subjectKeyIdentifier=hash authorityKeyIdentifier=keyid:always crlDistributionPoints=URI:http://crl1.somedomain.com/IntCA.crl,URI:http: //crl2.somedomain.com/IntCA.crl basicConstraints = critical, CA:true,pathlen:0 keyUsage=critical, keyCertSign,cRLSign extendedKeyUsage = serverAuth, clientAuth, codeSigning, emailProtection, timeStamping nsCertType = server, client certificatePolicies=ia5org,@polsect1 [polsect1] policyIdentifier = 1.3.6.1.4.1.0.1.2.1.2.1 CPS=http://www.somedomain.com/legal/cps-intCA.pdf ### Donald E. Bynum Director, Architecture Integration O: 703.668.5616 | M: 301.367.2072 | www.networksolutions.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of mallika Sent: Thursday, September 20, 2007 4:06 AM To: openssl-users@openssl.org Subject: intermediate CA configuration i want to create intermediate CA from root CA by using openssl.cnf. how to configure openssl.cnf file for creating intermediate ca which contains all attributes like root ca which is having obj signing,certificate revocation...can any body help me -- View this message in context: http://www.nabble.com/intermediate-CA-configuration-tf4485967.html#a12 79 2609 Sent from the OpenSSL - User mailing list archive at Nabble.com. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/intermediate-CA-configuration-tf4485967.html#a1281 0885 Sent from the OpenSSL - User mailing list archive at Nabble.com. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Safe signed certificate generation during server installation ?
On Tue, Sep 25, 2007 at 11:58:45AM +0200, Steffen DETTMER wrote: No, the challenge is key management. TLS is just fine. What do you mean, `TLS is just fine'? TLS is a sound protocol, the problem is not the protocol, the problem is key management. Doesn't it depend on the requirements? TLS is fine protocol for establishing a secure channel over a reliable transport. Despite all appearances, TLS is not exclusively tied to a CA centric X.509v3 trust model with RSA keys and RSA CA signatures. I think, for key management itself (like transferring secret keys), TLS is not suited. I am making no claims that TLS is (or is not) suited for key management. Key management is a pre-requisite for TLS, one model for key management is X.509v3 CAs issuing certs and revocation lists. This is not the only key management model compatible with TLS, though it is the one most commonly found in products that use TLS. TLS AFAIK is limited to one session key (someone could wish one for authentication and a second one for encryption). This is false. If CAs don't solve key management for you, roll your own key management, but use existing protocols. If for some application (not meaning only a computer program) the usual CAs are inappropriate, maybe for this application PKI is not suited at all, could happen. Maybe I missunderstand you, but I think, when SSL/TLS is not suited then it should not be needed, even if with OpenSSL such a nice lib is avialable :) Don't confuse TLS with PKI. I would like to see GSSAPI support in TLS (so would Microsoft and a few others). This addresses key management, without requiring secondary protocols, and ties into the dominant standard intra-mural authentication system. This would use a certificate-less cipher-suite, but the point remains that authentication should be within TLS, not an add-on. ohh, now I got so many questions :) Well, Kerberos is already supported, but only with DES. If TLS is to see wide-scale use *inside* large organizations where CAs are entirely the wrong model, and GSSAPI is already prevalent, we need a GSSAPI (X.509v3 certificate-less) cipher-suite for TLS with modern symmetric ciphers (AES-256, ...). This an IETF issue, not an OpenSSL issue. According to Wikipedia, this is an API to standardise how the application uses something like e.g. OpenSSL, is that correct? Or is it something completely different? You wrote `GSSAPI support in TLS' - this would be a standard or would it be an implementation? A new TLS ciphersuite, GSSAPI is both a standard and a protocol. How would it help with key management? Do you mean in this can you could use any standard GSSAPI-using key management tool? GSSAPI uses Keberos-5 KDCs for key management. You said `without requiring secondary protocols', but wouldn't the implementation of that API be nothing else than such a secondary protocol (OCSP or so)? The programmer would not need to develop a secondary authentication protocol and intergrate it with TLS, it would be correctly used in a standard fashion inside the TLS protocol. X.509v3 signature verification is also a protocol, it is just that the KDCs are off-line (which is most often a bug, not a feature). What is meant by certificate-less cipher-suite? A protocol not using certificates, such as SSL without X.509 certificates at all? How would the authentication work? Do some homework. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
EC Oddity
I have been doing some EC test code with the Sept. 5 snapshot and have
observed something that I find a little odd. So I thought I would
mention it so someone could take a look to see if it is a bug or what is
supposed to occur.
I have a PEM file with an EC private key.
I want to create an ephemeral private key for the same group.
So my code fragments are as follows:
EC_KEY *ecc_A=NULL;
EC_KEY *ecc_E=NULL;
const EC_GROUP *group=NULL;
ecc_A = PEM_read_bio_ECPrivateKey( bio_in, NULL, NULL, NULL );
group = EC_KEY_get0_group(ecc_A);
ecc_E = EC_KEY_new();
EC_KEY_set_group( ecc_E, group );
EC_KEY_generate_key( ecc_E );
Now the oddity occurs when I free the objects. If I have:
if( ecc_E != NULL ) {EC_KEY_free( ecc_E ); printf(ecc_E
freed\n);}
if( ecc_A != NULL ) {EC_KEY_free( ecc_A ); printf(ecc_A
freed\n);}
if( group != NULL ) {EC_GROUP_free( (EC_GROUP*)group );
printf(group freed\n);}
I see the messages:
ecc_E freed
ecc_A freed
Killed
If I reverse the order of the last two:
if( ecc_E != NULL ) {EC_KEY_free( ecc_E ); printf(ecc_E
freed\n);}
if( group != NULL ) {EC_GROUP_free( (EC_GROUP*)group);
printf(group freed\n);}
if( ecc_A != NULL ) {EC_KEY_free( ecc_A ); printf(ecc_A
freed\n);}
I see the messages:
ecc_E freed
group freed
Killed
It is almost as if the group object and the ec key object are combined,
such that freeing one automatically frees the other.
Is this the way it is supposed to be?
Also when doing the group free, I had to add the cast to prevent
compiler warnings. It seems that EC_GROUP is inconsistently defined in
the include files between its various uses. Is this also expected?
Bill
Re: Safe signed certificate generation during server installation ?
* Victor Duchovni wrote on Tue, Sep 25, 2007 at 09:27 -0400: On Tue, Sep 25, 2007 at 11:58:45AM +0200, Steffen DETTMER wrote: I would like to see GSSAPI support in TLS (so would Microsoft and a few others). This addresses key management, without requiring secondary protocols, and ties into the dominant standard intra-mural authentication system. This would use a certificate-less cipher-suite, but the point remains that authentication should be within TLS, not an add-on. ohh, now I got so many questions :) Well, Kerberos is already supported, but only with DES. If TLS is to see wide-scale use *inside* large organizations where CAs are entirely the wrong model, and GSSAPI is already prevalent, we need a GSSAPI (X.509v3 certificate-less) cipher-suite for TLS with modern symmetric ciphers (AES-256, ...). This an IETF issue, not an OpenSSL issue. According to Wikipedia, this is an API to standardise how the application uses something like e.g. OpenSSL, is that correct? Or is it something completely different? You wrote `GSSAPI support in TLS' - this would be a standard or would it be an implementation? A new TLS ciphersuite, GSSAPI is both a standard and a protocol. How would it help with key management? Do you mean in this can you could use any standard GSSAPI-using key management tool? GSSAPI uses Keberos-5 KDCs for key management. Ahh, you mean creating a new TLS (version) standard/RFC, that is using GSSAPI and is to be used e.g. inside large organizations that already have some GSSAPI available (because they use Kerberos) to eliminate the need to additionally worry about keys/certificates for this new TLS (but using Kerberos protocol / authentication instead)? oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Safe signed certificate generation during server installation ?
On Tue, Sep 25, 2007 at 05:20:28PM +0200, Steffen DETTMER wrote: GSSAPI uses Keberos-5 KDCs for key management. Ahh, you mean creating a new TLS (version) standard/RFC, that is using GSSAPI and is to be used e.g. inside large organizations that already have some GSSAPI available (because they use Kerberos) to eliminate the need to additionally worry about keys/certificates for this new TLS (but using Kerberos protocol / authentication instead)? Approximately correct, not a new TLS standard, the existing TLS 1.1 is likely sufficient, rather a new standard cipher-suite for TLS 1.1. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: intermediate CA configuration
On Tue, Sep 25, 2007, Bynum, Don wrote: Please send me your extensions file, CA cert/Key and the CSR you are using for your intermediate. I am assuming that what you have so far is for testing purposes. Otherwise, I would not ask for the CA key (obviously). Send them to me as a zip file and I'll take a look. You just need to specify the correct extension section when you sign the request v3_ca for example. If you used the simpler CA.pl script (see FAQ et al) then the option -signCA will do the trick. 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 Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: EC Oddity
On Tue, Sep 25, 2007, Bill Colvin wrote:
I have been doing some EC test code with the Sept. 5 snapshot and have
observed something that I find a little odd. So I thought I would
mention it so someone could take a look to see if it is a bug or what is
supposed to occur.
I have a PEM file with an EC private key.
I want to create an ephemeral private key for the same group.
So my code fragments are as follows:
EC_KEY *ecc_A=NULL;
EC_KEY *ecc_E=NULL;
const EC_GROUP *group=NULL;
ecc_A = PEM_read_bio_ECPrivateKey( bio_in, NULL, NULL, NULL );
group = EC_KEY_get0_group(ecc_A);
ecc_E = EC_KEY_new();
EC_KEY_set_group( ecc_E, group );
EC_KEY_generate_key( ecc_E );
Now the oddity occurs when I free the objects. If I have:
if( ecc_E != NULL ) {EC_KEY_free( ecc_E ); printf(ecc_E
freed\n);}
if( ecc_A != NULL ) {EC_KEY_free( ecc_A ); printf(ecc_A
freed\n);}
if( group != NULL ) {EC_GROUP_free( (EC_GROUP*)group );
printf(group freed\n);}
Some of the newer functions in OpenSSL follow a naming convention. If they
have a '0' such as *get0*() then the pointer retrieved is internal to the
parent structure and should *NOT* be freed up after use because it will be
freed when the parent structure is. If you free both up you get double frees
and undefined results.
If there is a '1' then a copy is retrieved and it *should* be freed up as well
as the parent structure.
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 Listopenssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
RE: EC Oddity
Thanks for the explanation as to why this is occurring. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dr. Stephen Henson Sent: September 25, 2007 11:49 AM To: openssl-users@openssl.org Subject: Re: EC Oddity Some of the newer functions in OpenSSL follow a naming convention. If they have a '0' such as *get0*() then the pointer retrieved is internal to the parent structure and should *NOT* be freed up after use because it will be freed when the parent structure is. If you free both up you get double frees and undefined results. If there is a '1' then a copy is retrieved and it *should* be freed up as well as the parent structure. 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 Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
via padlock support much slower in 0.9.8e than in 0.9.8d, why?
With a VIA C5 board I get a huge difference in speed with engine padlock support (same machine same OS etc.). Where is the difference coming from. Are there any changes regarding buffering or block sizes? Look at this results: 0.9.8e: #./openssl speed -evp aes-256-cbc -engine padlock engine padlock set. Doing aes-256-cbc for 3s on 16 size blocks: 9477714 aes-256-cbc's in 2.99s Doing aes-256-cbc for 3s on 64 size blocks: 5371202 aes-256-cbc's in 3.00s Doing aes-256-cbc for 3s on 256 size blocks: 2058449 aes-256-cbc's in 2.99s Doing aes-256-cbc for 3s on 1024 size blocks: 645381 aes-256-cbc's in 3.00s Doing aes-256-cbc for 3s on 8192 size blocks: 93456 aes-256-cbc's in 3.00s OpenSSL 0.9.8e 23 Feb 2007 built on: Wed Aug 22 17:00:48 CEST 2007 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 -DL_ENDIAN -DTERMIO -O3 -fomit-frame-pointer -Wall -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32_SSE2 -DSHA1_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM available timing options: TIMES TIMEB HZ=100 [sysconf value] timing function used: times The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes aes-256-cbc 50716.86k 114585.64k 176241.79k 220290.05k 255197.18k # 0.9.8d: # ./openssl speed -evp aes-256-cbc -engine padlock engine padlock set. Doing aes-256-cbc for 3s on 16 size blocks: 13856973 aes-256-cbc's in 2.99s Doing aes-256-cbc for 3s on 64 size blocks: 10520959 aes-256-cbc's in 3.00s Doing aes-256-cbc for 3s on 256 size blocks: 5370328 aes-256-cbc's in 3.00s Doing aes-256-cbc for 3s on 1024 size blocks: 1807981 aes-256-cbc's in 3.00s Doing aes-256-cbc for 3s on 8192 size blocks: 251498 aes-256-cbc's in 3.00s OpenSSL 0.9.8d 28 Sep 2006 built on: Fri Nov 10 20:44:47 CET 2006 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 -DL_ENDIAN -DTERMIO -O3 -fomit-frame-pointer -Wall -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32_SSE2 -DSHA1_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM available timing options: TIMES TIMEB HZ=100 [sysconf value] timing function used: times The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes aes-256-cbc 74151.03k 224447.13k 458267.99k 617124.18k 686757.21k # __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Safe signed certificate generation during server installation ?
* Victor Duchovni wrote on Tue, Sep 25, 2007 at 11:40 -0400: On Tue, Sep 25, 2007 at 05:20:28PM +0200, Steffen DETTMER wrote: creating a new TLS (version) standard/RFC Approximately correct, not a new TLS standard, the existing TLS 1.1 is likely sufficient, rather a new standard cipher-suite for TLS 1.1. Thank you for the explanation! oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Run ssl application
Hello, When I run ssl_server (after compiling ssl_server.c ), there is a error below. Please help me to solve this error. [EMAIL PROTECTED] Codevidu]# ./sslserver 8000 3691:error:140A90A1:SSL routines:SSL_CTX_new:library has no ciphers:ssl_lib.c:1424: Aborted Did you initialize OpenSSL library properly ? Look at man page of SSL_library_init. Best regards, -- Marek Marcola [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: via padlock support much slower in 0.9.8e than in 0.9.8d, why?
Hi! I cannot confirm these performance differences between 0.9.8d and 0.9.8e. My results on a Via CPU are: 0.9.8d == engine padlock set. Doing aes-256-cbc for 3s on 16 size blocks: 11906104 aes-256-cbc's in 3.00s Doing aes-256-cbc for 3s on 64 size blocks: 9088256 aes-256-cbc's in 2.99s Doing aes-256-cbc for 3s on 256 size blocks: 4744283 aes-256-cbc's in 2.98s Doing aes-256-cbc for 3s on 1024 size blocks: 1624804 aes-256-cbc's in 3.00s Doing aes-256-cbc for 3s on 8192 size blocks: 226672 aes-256-cbc's in 2.99s OpenSSL 0.9.8d 28 Sep 2006 built on: Tue Sep 25 20:13:59 GMT 2007 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 -DL_ENDIAN -DTERMIO -O3 -fomit-frame-pointer -Wall - DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32_SSE2 -DSHA1_ASM -DMD5_ASM - DRMD160_ASM -DAES_ASM available timing options: TIMES TIMEB HZ=100 [sysconf value] timing function used: times The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes aes-256-cbc 63499.22k 194531.23k 407562.57k 554599.77k 621035.79k 0.9.8e == engine padlock set. Doing aes-256-cbc for 3s on 16 size blocks: 11597661 aes-256-cbc's in 3.01s Doing aes-256-cbc for 3s on 64 size blocks: 8927779 aes-256-cbc's in 3.00s Doing aes-256-cbc for 3s on 256 size blocks: 4708369 aes-256-cbc's in 3.01s Doing aes-256-cbc for 3s on 1024 size blocks: 1622241 aes-256-cbc's in 3.00s Doing aes-256-cbc for 3s on 8192 size blocks: 227275 aes-256-cbc's in 2.97s OpenSSL 0.9.8e 23 Feb 2007 built on: Tue Sep 25 20:21:15 GMT 2007 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 -DL_ENDIAN -DTERMIO -O3 -fomit-frame-pointer -Wall - DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32_SSE2 -DSHA1_ASM -DMD5_ASM - DRMD160_ASM -DAES_ASM available timing options: TIMES TIMEB HZ=100 [sysconf value] timing function used: times The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes aes-256-cbc 61648.70k 190459.29k 400446.00k 553724.93k 626881.08k Regards, Harald Am 25.09.2007 um 19:35 schrieb Buddy Butterfly: With a VIA C5 board I get a huge difference in speed with engine padlock support (same machine same OS etc.). Where is the difference coming from. Are there any changes regarding buffering or block sizes? Look at this results: 0.9.8e: #./openssl speed -evp aes-256-cbc -engine padlock engine padlock set. Doing aes-256-cbc for 3s on 16 size blocks: 9477714 aes-256-cbc's in 2.99s Doing aes-256-cbc for 3s on 64 size blocks: 5371202 aes-256-cbc's in 3.00s Doing aes-256-cbc for 3s on 256 size blocks: 2058449 aes-256-cbc's in 2.99s Doing aes-256-cbc for 3s on 1024 size blocks: 645381 aes-256-cbc's in 3.00s Doing aes-256-cbc for 3s on 8192 size blocks: 93456 aes-256-cbc's in 3.00s OpenSSL 0.9.8e 23 Feb 2007 built on: Wed Aug 22 17:00:48 CEST 2007 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 -DL_ENDIAN -DTERMIO -O3 -fomit-frame-pointer -Wall -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32_SSE2 -DSHA1_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM available timing options: TIMES TIMEB HZ=100 [sysconf value] timing function used: times The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes aes-256-cbc 50716.86k 114585.64k 176241.79k 220290.05k 255197.18k # 0.9.8d: # ./openssl speed -evp aes-256-cbc -engine padlock engine padlock set. Doing aes-256-cbc for 3s on 16 size blocks: 13856973 aes-256-cbc's in 2.99s Doing aes-256-cbc for 3s on 64 size blocks: 10520959 aes-256-cbc's in 3.00s Doing aes-256-cbc for 3s on 256 size blocks: 5370328 aes-256-cbc's in 3.00s Doing aes-256-cbc for 3s on 1024 size blocks: 1807981 aes-256-cbc's in 3.00s Doing aes-256-cbc for 3s on 8192 size blocks: 251498 aes-256-cbc's in 3.00s OpenSSL 0.9.8d 28 Sep 2006 built on: Fri Nov 10 20:44:47 CET 2006 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 -DL_ENDIAN -DTERMIO -O3 -fomit-frame-pointer -Wall -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32_SSE2 -DSHA1_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM available timing options: TIMES TIMEB HZ=100 [sysconf value] timing function used: times The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes aes-256-cbc 74151.03k 224447.13k 458267.99k 617124.18k
AW: via padlock support much slower in 0.9.8e than in 0.9.8d, why?
Hi, strange. What could be the reason then? I have 2 systems available for testing. C5 and C7. C5 runs Suse 9.3 (kernel 2.6.11) which shows the difference I have posted below. C7 runs Debian etch (kernel 2.6.18 type i686). On the C7 I see no difference between openssl version d and e but speed seems to be much slower (max 292MB/s) with both versions and not going up to over 600MB/s like you posted. Any clues? -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Harald Latzko Gesendet: Dienstag, 25. September 2007 20:25 An: openssl-users@openssl.org Betreff: Re: via padlock support much slower in 0.9.8e than in 0.9.8d, why? Hi! I cannot confirm these performance differences between 0.9.8d and 0.9.8e. My results on a Via CPU are: 0.9.8d == engine padlock set. Doing aes-256-cbc for 3s on 16 size blocks: 11906104 aes-256-cbc's in 3.00s Doing aes-256-cbc for 3s on 64 size blocks: 9088256 aes-256-cbc's in 2.99s Doing aes-256-cbc for 3s on 256 size blocks: 4744283 aes-256-cbc's in 2.98s Doing aes-256-cbc for 3s on 1024 size blocks: 1624804 aes-256-cbc's in 3.00s Doing aes-256-cbc for 3s on 8192 size blocks: 226672 aes-256-cbc's in 2.99s OpenSSL 0.9.8d 28 Sep 2006 built on: Tue Sep 25 20:13:59 GMT 2007 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 -DL_ENDIAN -DTERMIO -O3 -fomit-frame-pointer -Wall - DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32_SSE2 -DSHA1_ASM -DMD5_ASM - DRMD160_ASM -DAES_ASM available timing options: TIMES TIMEB HZ=100 [sysconf value] timing function used: times The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes aes-256-cbc 63499.22k 194531.23k 407562.57k 554599.77k 621035.79k 0.9.8e == engine padlock set. Doing aes-256-cbc for 3s on 16 size blocks: 11597661 aes-256-cbc's in 3.01s Doing aes-256-cbc for 3s on 64 size blocks: 8927779 aes-256-cbc's in 3.00s Doing aes-256-cbc for 3s on 256 size blocks: 4708369 aes-256-cbc's in 3.01s Doing aes-256-cbc for 3s on 1024 size blocks: 1622241 aes-256-cbc's in 3.00s Doing aes-256-cbc for 3s on 8192 size blocks: 227275 aes-256-cbc's in 2.97s OpenSSL 0.9.8e 23 Feb 2007 built on: Tue Sep 25 20:21:15 GMT 2007 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 -DL_ENDIAN -DTERMIO -O3 -fomit-frame-pointer -Wall - DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32_SSE2 -DSHA1_ASM -DMD5_ASM - DRMD160_ASM -DAES_ASM available timing options: TIMES TIMEB HZ=100 [sysconf value] timing function used: times The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes aes-256-cbc 61648.70k 190459.29k 400446.00k 553724.93k 626881.08k Regards, Harald Am 25.09.2007 um 19:35 schrieb Buddy Butterfly: With a VIA C5 board I get a huge difference in speed with engine padlock support (same machine same OS etc.). Where is the difference coming from. Are there any changes regarding buffering or block sizes? Look at this results: 0.9.8e: #./openssl speed -evp aes-256-cbc -engine padlock engine padlock set. Doing aes-256-cbc for 3s on 16 size blocks: 9477714 aes-256-cbc's in 2.99s Doing aes-256-cbc for 3s on 64 size blocks: 5371202 aes-256-cbc's in 3.00s Doing aes-256-cbc for 3s on 256 size blocks: 2058449 aes-256-cbc's in 2.99s Doing aes-256-cbc for 3s on 1024 size blocks: 645381 aes-256-cbc's in 3.00s Doing aes-256-cbc for 3s on 8192 size blocks: 93456 aes-256-cbc's in 3.00s OpenSSL 0.9.8e 23 Feb 2007 built on: Wed Aug 22 17:00:48 CEST 2007 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 -DL_ENDIAN -DTERMIO -O3 -fomit-frame-pointer -Wall -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32_SSE2 -DSHA1_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM available timing options: TIMES TIMEB HZ=100 [sysconf value] timing function used: times The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes aes-256-cbc 50716.86k 114585.64k 176241.79k 220290.05k 255197.18k # 0.9.8d: # ./openssl speed -evp aes-256-cbc -engine padlock engine padlock set. Doing aes-256-cbc for 3s on 16 size blocks: 13856973 aes-256-cbc's in 2.99s Doing aes-256-cbc for 3s on 64 size blocks: 10520959 aes-256-cbc's in 3.00s Doing aes-256-cbc for 3s on 256 size blocks: 5370328 aes-256-cbc's in 3.00s Doing aes-256-cbc for 3s on
RE: Safe signed certificate generation during server installation ?
In this second step of verification, you can exchange public keys, certificates, challenges, responses, and so on. Each side can verify what it is talking to on the other side by whatever mechanism you want. Ahh, yes, ok. But the result would not be SSL but something-SSL-based, right? Well, by this someone could use e.g. symetric keys for authentication - if it fails the session could be discarded, right. It would be SSL for everything except the MITM detection. SSL provides the transport encryption. Again, the only serious potential gotcha is a MITM who might replace the single SSL session with his two (one to each end) and proxy the second step and then takeover or monitor the data connection. Ensuring that each side's SSL_get_finished matches the other side's SSL_get_peer_finished should be sufficient to prevent this. (Include these in the signed objects you exchange.) I'm not sure if I understand ...including these If, for instance, each side (and only them) share a secret 3DES key and use it for some challenge-response-authentication inside a SSL tunnel then I would assume that this is secure because it would be secure without the SSL and thus should be with it. No, because a MITM could interpose his own SSL connection to both sides, proxy the challenge-response authentication and then view or modify the plaintext. If you don't verify the name in the certificate, SSL provides everything you need *except* MITM detection. So you just need to add that. Once you verify that the two programs that are going to exchange secure data have opposite ends of the *same* SSL connection, SSL does everything you need. beside the fact, that I don't see the advantages of SSL here. A MITM could forward this authentication, so based on the challenge-response some session key needs to be derived to be used as encryption key (to make the MITM unable to read or change the forwarded data). Is that right so far (in such a setup, what is the SSL for BTW)? If a MITM forwarded the authentication, the authentication would fail because the authentication objects would not match the 'finished' data. If a MITM interposes his own SSL connections, then the 'finished' data will not match, So your point is that some property from the original certificate (lets say some hash or so) could be included in the extra authentication to detect a MITM (or whatever faked) certificate? In that case, SSL would be used basically for encryption only, right? Exactly. Are such schemes used in practice? Or is it more a theoretical idea showing what would be possible? Yes, they are. DS __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Fwd: openssl ECC/ECDSA question
Hello, Oops, forgot to include the functions. These are: i2d_ECDSA_SIG d2i_ECDSA_SIG This functions are implemented in file crypto/ecdsa/ecs_asn1.c. Proof (after compiling): $ nm crypto/ecdsa/ecs_asn1.o | grep -E 'i2d|d2i' 00a0 T d2i_ECDSA_SIG 0060 T i2d_ECDSA_SIG Looking at this file I have no better one :-) Best regards, -- Marek Marcola [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Fwd: openssl ECC/ECDSA question
On Wed, Sep 26, 2007, Marek Marcola wrote: Hello, Oops, forgot to include the functions. These are: i2d_ECDSA_SIG d2i_ECDSA_SIG This functions are implemented in file crypto/ecdsa/ecs_asn1.c. Proof (after compiling): $ nm crypto/ecdsa/ecs_asn1.o | grep -E 'i2d|d2i' 00a0 T d2i_ECDSA_SIG 0060 T i2d_ECDSA_SIG Looking at this file I have no better one :-) In common with all the ASN1 functions they are implemented through macros normally beginning IMPLEMENT_ASN1_* the dependency tree will end up dragging in most of the ASN1 library as a result. 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 Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Fwd: openssl ECC/ECDSA question
Hello, Hello, Oops, forgot to include the functions. These are: i2d_ECDSA_SIG d2i_ECDSA_SIG This functions are implemented in file crypto/ecdsa/ecs_asn1.c. Proof (after compiling): $ nm crypto/ecdsa/ecs_asn1.o | grep -E 'i2d|d2i' 00a0 T d2i_ECDSA_SIG 0060 T i2d_ECDSA_SIG Looking at this file I have no better one :-) In common with all the ASN1 functions they are implemented through macros normally beginning IMPLEMENT_ASN1_* the dependency tree will end up dragging in most of the ASN1 library as a result. I've forgot to add: $ gcc -E ecs_asn1.c -I../../include as a method to look at this file after preprocessing by cpp. Best regards, -- Marek Marcola [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
