Re: How to separate ECC Public Key from keypairs and convert it to EVP_PKEY?
On Wed, Jan 30, 2013, cellecial wrote: Hi, I write some code to generate an ECC certificate, it works partly. The certificate can be parsed by IE but prompt signature corrupt. Are you sure that version of Windows supports ECC cerrificates? So I dump the cert using X509_print_fp(),here is the information: /*=*/ Certificate: Data: Version: 1 (0x0) Serial Number: 0 (0x0) Signature Algorithm: ecdsa-with-SHA1 Issuer: C=AU, ST=SS, L=LL, O=LONG, OU=DEV, CN=CA/emailAddress=ad...@long.com Validity Not Before: Jan 29 07:39:02 2013 GMT Not After : Jan 29 07:39:02 2014 GMT Subject: C=AU, ST=SS, L=LL, O=LONG, OU=DEV, CN=CA/emailAddress=ad...@long.com Subject Public Key Info: Public Key Algorithm: id-ecPublicKey Public-Key: (256 bit) pub: 04:c6:f8:32:9a:99:ff:8f:66:f4:05:57:33:86:b1: 6d:18:2b:71:38:35:67:f9:37:b6:3b:e7:fc:26:dc: 9b:bc:40:76:64:53:ef:b4:1d:18:24:79:bc:93:ab: 2f:5d:50:4c:63:fb:e6:4c:d5:2e:44:8b:f2:05:e9: 4c:ca:4c:3d:49 Field Type: prime-field Prime: 00:ff:ff:ff:ff:00:00:00:01:00:00:00:00:00:00: 00:00:00:00:00:00:ff:ff:ff:ff:ff:ff:ff:ff:ff: ff:ff:ff A: 00:ff:ff:ff:ff:00:00:00:01:00:00:00:00:00:00: 00:00:00:00:00:00:ff:ff:ff:ff:ff:ff:ff:ff:ff: ff:ff:fc B: 5a:c6:35:d8:aa:3a:93:e7:b3:eb:bd:55:76:98:86: bc:65:1d:06:b0:cc:53:b0:f6:3b:ce:3c:3e:27:d2: 60:4b Generator (uncompressed): 04:6b:17:d1:f2:e1:2c:42:47:f8:bc:e6:e5:63:a4: 40:f2:77:03:7d:81:2d:eb:33:a0:f4:a1:39:45:d8: 98:c2:96:4f:e3:42:e2:fe:1a:7f:9b:8e:e7:eb:4a: 7c:0f:9e:16:2b:ce:33:57:6b:31:5e:ce:cb:b6:40: 68:37:bf:51:f5 Order: 00:ff:ff:ff:ff:00:00:00:00:ff:ff:ff:ff:ff:ff: ff:ff:bc:e6:fa:ad:a7:17:9e:84:f3:b9:ca:c2:fc: 63:25:51 Cofactor: 1 (0x1) Seed: c4:9d:36:08:86:e7:04:93:6a:66:78:e1:13:9d:26: b7:81:9f:7e:90 Signature Algorithm: ecdsa-with-SHA1 30:45:02:20:1f:7a:53:12:6f:7f:79:f8:8a:f8:15:dd:f0:3a: b4:cd:4e:46:1d:f3:bd:89:53:33:88:ab:c6:dc:7f:d8:4b:33: 02:21:00:ca:87:43:6b:35:8f:44:db:ee:56:2a:52:4a:86:8c: f4:14:b3:ae:71:49:e5:1f:94:67:a5:2a:e2:c9:27:22:90 /*=*/ As you can see, there are some extra info in Public Key Info section. I thought I know the reason, here is my origin code snippet: That extra info is the default way the EC key is currently encoded by OpenSSL: explicitly giving all the EC curve details. If you want it to just use the curve name instead you have to call: EC_KEY_set_asn1_flag(eckey, OPENSSL_EC_NAMED_CURVE); Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: How to separate ECC Public Key from keypairs and convert it to EVP_PKEY?
FYI ECC was added to Windows VISTA, Ryan Hurst Sent from my phone, please forgive the brevity. On Jan 30, 2013, at 5:51 AM, Dr. Stephen Henson st...@openssl.org wrote: On Wed, Jan 30, 2013, cellecial wrote: Hi, I write some code to generate an ECC certificate, it works partly. The certificate can be parsed by IE but prompt signature corrupt. Are you sure that version of Windows supports ECC cerrificates? So I dump the cert using X509_print_fp(),here is the information: /*=*/ Certificate: Data: Version: 1 (0x0) Serial Number: 0 (0x0) Signature Algorithm: ecdsa-with-SHA1 Issuer: C=AU, ST=SS, L=LL, O=LONG, OU=DEV, CN=CA/emailAddress=ad...@long.com Validity Not Before: Jan 29 07:39:02 2013 GMT Not After : Jan 29 07:39:02 2014 GMT Subject: C=AU, ST=SS, L=LL, O=LONG, OU=DEV, CN=CA/emailAddress=ad...@long.com Subject Public Key Info: Public Key Algorithm: id-ecPublicKey Public-Key: (256 bit) pub: 04:c6:f8:32:9a:99:ff:8f:66:f4:05:57:33:86:b1: 6d:18:2b:71:38:35:67:f9:37:b6:3b:e7:fc:26:dc: 9b:bc:40:76:64:53:ef:b4:1d:18:24:79:bc:93:ab: 2f:5d:50:4c:63:fb:e6:4c:d5:2e:44:8b:f2:05:e9: 4c:ca:4c:3d:49 Field Type: prime-field Prime: 00:ff:ff:ff:ff:00:00:00:01:00:00:00:00:00:00: 00:00:00:00:00:00:ff:ff:ff:ff:ff:ff:ff:ff:ff: ff:ff:ff A: 00:ff:ff:ff:ff:00:00:00:01:00:00:00:00:00:00: 00:00:00:00:00:00:ff:ff:ff:ff:ff:ff:ff:ff:ff: ff:ff:fc B: 5a:c6:35:d8:aa:3a:93:e7:b3:eb:bd:55:76:98:86: bc:65:1d:06:b0:cc:53:b0:f6:3b:ce:3c:3e:27:d2: 60:4b Generator (uncompressed): 04:6b:17:d1:f2:e1:2c:42:47:f8:bc:e6:e5:63:a4: 40:f2:77:03:7d:81:2d:eb:33:a0:f4:a1:39:45:d8: 98:c2:96:4f:e3:42:e2:fe:1a:7f:9b:8e:e7:eb:4a: 7c:0f:9e:16:2b:ce:33:57:6b:31:5e:ce:cb:b6:40: 68:37:bf:51:f5 Order: 00:ff:ff:ff:ff:00:00:00:00:ff:ff:ff:ff:ff:ff: ff:ff:bc:e6:fa:ad:a7:17:9e:84:f3:b9:ca:c2:fc: 63:25:51 Cofactor: 1 (0x1) Seed: c4:9d:36:08:86:e7:04:93:6a:66:78:e1:13:9d:26: b7:81:9f:7e:90 Signature Algorithm: ecdsa-with-SHA1 30:45:02:20:1f:7a:53:12:6f:7f:79:f8:8a:f8:15:dd:f0:3a: b4:cd:4e:46:1d:f3:bd:89:53:33:88:ab:c6:dc:7f:d8:4b:33: 02:21:00:ca:87:43:6b:35:8f:44:db:ee:56:2a:52:4a:86:8c: f4:14:b3:ae:71:49:e5:1f:94:67:a5:2a:e2:c9:27:22:90 /*=*/ As you can see, there are some extra info in Public Key Info section. I thought I know the reason, here is my origin code snippet: That extra info is the default way the EC key is currently encoded by OpenSSL: explicitly giving all the EC curve details. If you want it to just use the curve name instead you have to call: EC_KEY_set_asn1_flag(eckey, OPENSSL_EC_NAMED_CURVE); Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org smime.p7s Description: S/MIME cryptographic signature
Re: Obtaining a TLS session key
On 1/30/2013 6:42 AM, Viktor Dukhovni wrote: On Wed, Jan 30, 2013 at 05:29:51PM +1300, T J wrote: How does one obtain the session key from a SSL structure after a successful TLS handshake? You don't, but, you shold instead obtain the tls-unique channel binding data ( https://tools.ietf.org/html/rfc5929#section-3 ) and run the result through a KDF (HKDF should work well) on both ends to obtain a suitable key for a symmetric algorithm of your choice. Sorry, not such a good idea. As I read RFC5929 and the TLS 1.2 RFC, it seems that despite some vaguely promising language in RFC5929, the tls-unique value is *not* suitable as the basis of an encryption key for the following reasons: 1. It is quite vague (underspecified) if and when the form of the finished message used as the tls-unique value is A) sent in the clear B) The already encrypted form of the message as sent over the network or C) The plaintext passed to the TLS encryption mechanism before transmission. In interpretation A and B the value is known to any attackers, while in interpretation C it is known to attackers only if the negotiated TLS encryption is NULL or weak. 2. The TLS 1.2 RFC seems clear that the raw input tls-unique value will often be only 12 bytes (96 bits) which is not enough input to generate a 128 bit or stronger encryption key, no matter how clever the KDF. It seems that the only proper use of the tls-unique value is as a way to use an outside channel to authenticate the TLS session, not the other way around. The use that seems to be suggested in the text of RFC5929 is to use it as an extra input to any strong authentication protocols (such as SRP or HTTP-digest) done over the TLS session to prove to the other end that the authentication is for this TLS session, and not for some TLS session you are having with a man in the middle. This is safe even if an attacker knows the value as long as he cannot force both ends of a MitM compromised connection to use the same value and cannot compute the needed changes in authentication messages to compensate for the difference between the two tls-unique values from the two halfs of the connection. (snip code to extract the tls-unique binary value from an SSL_CTX handle without a specific API for this task) For HKDF see: https://tools.ietf.org/html/rfc5869 Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2730 Herlev, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
aNULL cipher order and TLS 1.2 ciphers
With aRSA ciphers we see that the new TLS 1.2 ciphers with SHA-2 MACs are by default preferred over the older TLS 1.1 SHA-1 ciphers. For example, looking at just the AES subset we see groups of 3 in which the first is always GCM, the second SHA-2 and the 3rd SHA-1: $ openssl ciphers -v aRSA+AES+HIGH ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDHAu=RSA Enc=AESGCM(256) Mac=AEAD ECDHE-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(256) Mac=SHA384 ECDHE-RSA-AES256-SHASSLv3 Kx=ECDH Au=RSA Enc=AES(256) Mac=SHA1 -- DHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(256) Mac=AEAD DHE-RSA-AES256-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AES(256) Mac=SHA256 DHE-RSA-AES256-SHA SSLv3 Kx=DH Au=RSA Enc=AES(256) Mac=SHA1 -- AES256-GCM-SHA384 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(256) Mac=AEAD AES256-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA256 AES256-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA1 -- ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDHAu=RSA Enc=AESGCM(128) Mac=AEAD ECDHE-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(128) Mac=SHA256 ECDHE-RSA-AES128-SHASSLv3 Kx=ECDH Au=RSA Enc=AES(128) Mac=SHA1 -- DHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(128) Mac=AEAD DHE-RSA-AES128-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AES(128) Mac=SHA256 DHE-RSA-AES128-SHA SSLv3 Kx=DH Au=RSA Enc=AES(128) Mac=SHA1 -- AES128-GCM-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(128) Mac=AEAD AES128-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA256 AES128-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA1 However, when we look at the aNULL ciphers the picture changes. Looking for simplicity at aNULL+AES+HIGH:-SRP, we get: $ openssl ciphers -v aNULL+AES+HIGH:-SRP AECDH-AES256-SHASSLv3 Kx=ECDH Au=None Enc=AES(256) Mac=SHA1 ADH-AES256-GCM-SHA384 TLSv1.2 Kx=DH Au=None Enc=AESGCM(256) Mac=AEAD ADH-AES256-SHA256 TLSv1.2 Kx=DH Au=None Enc=AES(256) Mac=SHA256 ADH-AES256-SHA SSLv3 Kx=DH Au=None Enc=AES(256) Mac=SHA1 AECDH-AES128-SHASSLv3 Kx=ECDH Au=None Enc=AES(128) Mac=SHA1 ADH-AES128-GCM-SHA256 TLSv1.2 Kx=DH Au=None Enc=AESGCM(128) Mac=AEAD ADH-AES128-SHA256 TLSv1.2 Kx=DH Au=None Enc=AES(128) Mac=SHA256 ADH-AES128-SHA SSLv3 Kx=DH Au=None Enc=AES(128) Mac=SHA1 Here the SHA1 variants have unexpectedly higher preference, but it is fair to note, that the TLS 1.2 ciphers use prime DH key exchage, while the SSLv3 ciphers use ephemeral ECDH. So the preference for EECDH is stronger than the preference for a stronger MAC. Are there no TLS 1.2 anonymous ciphersuites with kEECDH, or just none implemented in OpenSSL 1.0.1c? $ openssl ciphers -v kEECDH+aNULL AECDH-AES256-SHASSLv3 Kx=ECDH Au=None Enc=AES(256) Mac=SHA1 AECDH-DES-CBC3-SHA SSLv3 Kx=ECDH Au=None Enc=3DES(168) Mac=SHA1 AECDH-AES128-SHASSLv3 Kx=ECDH Au=None Enc=AES(128) Mac=SHA1 AECDH-RC4-SHA SSLv3 Kx=ECDH Au=None Enc=RC4(128) Mac=SHA1 AECDH-NULL-SHA SSLv3 Kx=ECDH Au=None Enc=None Mac=SHA1 I don't see any TLS_ECDH_anon_mumble listed by IANA: https://www.iana.org/assignments/tls-parameters/tls-parameters.xml so perhaps the issue is really with the IETF issue rather than OpenSSL. Does anyone know whether the IETF has any plans for anon ECDHE ciphers with stronger hashes? It appears that only prime DH variants were added: $ openssl ciphers -v aNULL | grep 'TLSv1.2' ADH-AES256-GCM-SHA384 TLSv1.2 Kx=DH Au=None Enc=AESGCM(256) Mac=AEAD ADH-AES256-SHA256 TLSv1.2 Kx=DH Au=None Enc=AES(256) Mac=SHA256 ADH-AES128-GCM-SHA256 TLSv1.2 Kx=DH Au=None Enc=AESGCM(128) Mac=AEAD ADH-AES128-SHA256 TLSv1.2 Kx=DH Au=None Enc=AES(128) Mac=SHA256 -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Obtaining a TLS session key
On Wed, Jan 30, 2013 at 07:03:09PM +0100, Jakob Bohm wrote: You don't, but, you shold instead obtain the tls-unique channel binding data ( https://tools.ietf.org/html/rfc5929#section-3 ) and run the result through a KDF (HKDF should work well) on both ends to obtain a suitable key for a symmetric algorithm of your choice. Sorry, not such a good idea. As I read RFC5929 and the TLS 1.2 RFC, it seems that despite some vaguely promising language in RFC5929, the tls-unique value is *not* suitable as the basis of an encryption key for the following reasons: 1. It is quite vague (underspecified) if and when the form of the finished message used as the tls-unique value is A) sent in the clear B) The already encrypted form of the message as sent over the network or C) The plaintext passed to the TLS encryption mechanism before transmission. In interpretation A and B the value is known to any attackers, while in interpretation C it is known to attackers only if the negotiated TLS encryption is NULL or weak. The finished message is always sent (by both parties) after ChangeCipherSpec, and thus always encrypted, provided the handshake did not negotiate an eNULL bulk cipher. This is explicitly stated the TLS RFCs. 2. The TLS 1.2 RFC seems clear that the raw input tls-unique value will often be only 12 bytes (96 bits) which is not enough input to generate a 128 bit or stronger encryption key, no matter how clever the KDF. This is fair, the tls-unique value is in practice only 96 bits. And indeed its intended use is channel-binding with GSSAPI, ... If 96-bits is not enough, one needs to get at the master secret on both sides, and run that through a KDF together with client and server random plus a suitable application-specific salt. Does OpenSSL provide a public interface for getting at the master secret or otherwise generating application-specific derived keys? -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Obtaining the master secret after TLS the handshake.
On 31/01/13 07:15, Viktor Dukhovni wrote: This is fair, the tls-unique value is in practice only 96 bits. And indeed its intended use is channel-binding with GSSAPI, ... If 96-bits is not enough, one needs to get at the master secret on both sides, and run that through a KDF together with client and server random plus a suitable application-specific salt. Does OpenSSL provide a public interface for getting at the master secret or otherwise generating application-specific derived keys? Good question... Still trying to understand how to approach this (I'm somewhat new to cryptography). I need a symmetric key for encrypting bulk data with AES256. Wouldn't I need an input to the KDF with keyspace of at least 256 bits to generate the same key at both ends after the TLS handshake? T J __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Obtaining a TLS session key
On 1/30/2013 7:15 PM, Viktor Dukhovni wrote: On Wed, Jan 30, 2013 at 07:03:09PM +0100, Jakob Bohm wrote: You don't, but, you shold instead obtain the tls-unique channel binding data ( https://tools.ietf.org/html/rfc5929#section-3 ) and run the result through a KDF (HKDF should work well) on both ends to obtain a suitable key for a symmetric algorithm of your choice. Sorry, not such a good idea. As I read RFC5929 and the TLS 1.2 RFC, it seems that despite some vaguely promising language in RFC5929, the tls-unique value is *not* suitable as the basis of an encryption key for the following reasons: 1. It is quite vague (underspecified) if and when the form of the finished message used as the tls-unique value is A) sent in the clear B) The already encrypted form of the message as sent over the network or C) The plaintext passed to the TLS encryption mechanism before transmission. In interpretation A and B the value is known to any attackers, while in interpretation C it is known to attackers only if the negotiated TLS encryption is NULL or weak. The finished message is always sent (by both parties) after ChangeCipherSpec, and thus always encrypted, provided the handshake did not negotiate an eNULL bulk cipher. This is explicitly stated the TLS RFCs. In the basic non-renegotiation form of a TLS connection, the Finished messages are the only handshake messages that are encrypted (Protected). Different descriptions of the protocol may thus (with no change in meaning) refer to the encryption of that message to be either part of the message or part of its framing. Unfortunately neither the tls-unique spec at https://tools.ietf.org/html/rfc5929#section-3.1 nor version 1.2 of the TLS spec at https://tools.ietf.org/html/rfc5246#section-7.4.9 specify (without a search of all other document parts) if the Finished struct, not the TLS record layer message containing it refers to the encrypted or unencrypted message, hence the confusion. Adding an appropriate adjective such as unencrypted or plaintext to this phrase in RFC5929 would have avoided the confusion and risk of incorrect implementations (remember the HTTP deflate debacle caused by similar vagueness). 2. The TLS 1.2 RFC seems clear that the raw input tls-unique value will often be only 12 bytes (96 bits) which is not enough input to generate a 128 bit or stronger encryption key, no matter how clever the KDF. This is fair, the tls-unique value is in practice only 96 bits. And indeed its intended use is channel-binding with GSSAPI, ... If 96-bits is not enough, one needs to get at the master secret on both sides, and run that through a KDF together with client and server random plus a suitable application-specific salt. Thanks, agreed. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2730 Herlev, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
