RE: trying to understand ECDHE operations
Michael D wrote on Tue, 12 Jan 2010 06:01:23 -0800 (but some of my mail got lost or dropped for some reason and I only later found in mail-archive) (and majordomo 'which' is either broken or deceptive, which didn't help matters!) Dave, I think I have been getting ahead of myself and need to do some more reading. More quick questions, if you don't mind me asking. I have included an answer you gave me months ago regarding Yc. For a 192bit curve, the number of bytes is 50. I imagine one of the bytes is if the point is compressed or uncompressed. (Is that right?) What is the length prefix? Is that what is referred to as PublicValueEncoding in RFC4492? Where can I read about that and how it is set? Thanks for your help, I really appreciate it. I seem to be having trouble explaining effectively. Let's try an example. From s_client -msg per below: TLS 1.0 Handshake [length 00bb], ServerKeyExchange 0c 00 00 b7 03 00 13 31 04 d6 f9 6d 02 15 3a 88 0d da ac ed d7 94 8a ff 6d fa 09 c5 9b ad 39 18 43 24 34 8d 67 7b ca 22 6e 14 fd ab 32 1a 76 19 00 a2 39 8e c8 f8 41 6f b6 00 80 1a a7 e3 92 04 9f 42 db 75 7f 5f 66 7f 43 90 d0 e3 b4 87 e4 9d 27 17 49 1b c2 68 7e eb 20 c3 a2 b0 a3 df 7a fa ab 23 4e 61 b7 8e 11 12 0f 73 74 d0 e9 38 ce 33 ba 07 21 77 0b a5 fe 40 8d a0 51 12 b7 bf ad 0a a3 88 de ce fb a1 a7 73 48 2b 20 48 cd 01 3c f4 5b 14 b7 a2 70 4f 6d 80 07 4a 2d 9e d8 61 37 71 28 1f 55 ec 59 69 ba de 40 87 12 ec d5 06 6e 86 0b ae e6 9e cc f8 ea 27 04 ba dd I interleave the relevant definitions from 4492 and 4346 with (hex)offset: bytes selected from the above. Handshake: HandshakeType msg_type;/* handshake type */ 0: 0c =server_key_exchange uint24 length; /* bytes in message */ 3: 00 00 b7 ServerKeyExchange for case ec_diffie_hellman: ServerECDHParamsparams; Signature signed_params; params: ECParameterscurve_params; ECPoint public; curve_params: ECCurveTypecurve_type; 4: 03 =named_curve (other cases omitted) case named_curve: NamedCurve namedcurve; 5: 00 13 =secp192r1 point: opaque point 1..2^8-1; 7: 31 =length=49decimal + 49bytes beginning at 8: All vectors in TLS begin with a length prefix, see 4.3. So those 49 bytes are the server's point. Per 5.4 it is encoded per ANSI X9.62 and can be uncompressed or compressed; I don't know/have that standard so I just skip 49 bytes. If I ever need to fully understand this I'll read through the code. Apparently here it was uncompressed, since 2*192b = 48 bytes matches almost exactly. Probably first byte 04 means uncompressed. Then Signature has length 39: 00 80 =128decimal followed by 128bytes. (In this example it's an RSA-1k signature because I was that cert i.e. I negotiated ECDHE-RSA-AES128-SHA.) Per 5.7 PublicValueEncoding is used in *Client*KeyExchange to specify a client with an EC cert uses that subjectkey for its (public) point. Otherwise ClientKeyExchange contains the client's ephemeral point, as ECPoint. It doesn't need to specify the curve, because it must share the one specified by the server; and isn't (directly) signed, instead it is included in client's CertificateVerify if used and of course the whole negotiation is verified by Finished. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: trying to understand ECDHE operations
Dave, I think I have been getting ahead of myself and need to do some more reading. More quick questions, if you don't mind me asking. I have included an answer you gave me months ago regarding Yc. For a 192bit curve, the number of bytes is 50. I imagine one of the bytes is if the point is compressed or uncompressed. (Is that right?) What is the length prefix? Is that what is referred to as PublicValueEncoding in RFC4492? Where can I read about that and how it is set? Thanks for your help, I really appreciate it. Mike First, a caveat: I set up a test to verify my understanding, and found (to my surprise) that s_server at least doesn't try to use the same curve for kECDHE as for aECDSA; it's a separate choice, and defaults to sectp163r2. Are you sure either your server or your client is selecting (forcing) prime192r1 for keyagreement AS WELL AS signing/authentication? That said, I get *49* bytes of ECDH data (Yc), plus a 1-byte length prefix totalling 50, in a ClientKeyExchange message totalling 54, in a (clear) handshake record totalling 59. Combined with other records/messages into a TCP segment etc. If that's not what you got, you did something different. --- On Mon, 1/11/10, Dave Thompson dave.thomp...@princetonpayments.com wrote: From: Dave Thompson dave.thomp...@princetonpayments.com Subject: RE: trying to understand ECDHE operations To: openssl-users@openssl.org Date: Monday, January 11, 2010, 5:48 PM From: owner-openssl-us...@openssl.org On Behalf Of Michael D Sent: Friday, 08 January, 2010 08:53 Based on the old message snippet below, two questions: 1) Are the session keys then used by the symmetric cipher going forward? Or is there another step used to get those keys. Session keys are for symmetric data cipher AND data HMAC. (TLS actually calls the HMAC secret parameter secret although RFC 2104 and IME most other usage calls it key.) For example, if I am using 192 bit ECC, and using AES-128, what do I use for the 128 bit key? Two specified 128bit chunks of TLSPRF(master,otherstuff) where master = TLSPRF(premaster,otherstuff). See RFC 4346 8.1 and 6.3 (and 5) as modified by 4492 5.10. If I used AES 256, would I need a larger number of bits in the ECC curve? You don't NEED it. TLS key derivation generates enough key material, regardless of the size of premaster. However, premaster must contain enough entropy to support the desired security; per Kerckhoff (sp?) everything else is knowable by the attacker. 128bit symmetric is plenty for many years; like Schneier's stake it's stronger than the rest of your system. So AES256 versus 128 should only be needed for interop and/or buzzword compliance -- which can be useful, and (here) doesn't hurt. If you really want 128bit or more security level, you do need to use for keyagreement an EC curve big enough to provide that security level. According to NIST in SP 800-57, EC of 2N bits is roughly equivalent to symmetric of N bits, so even for full AES128 you should be using EC=256. But you may find other experts with different judgements. And you must also have enough good random-data generation involved (in ECDHE transients, or as noted static-ECDH nonces). I believe in practice this has more often been a weakness (and successful attack) than actual cryptography. But it's harder to analyze and basically impossible to prove. 2) The last part of the Where can I read about how SSL makes session unique with a nonce, how is that done and or where can I read about it? Much of RFC 4346. Static aka fixed ECDH (or DH) does use the certified key as the server part of keyagreement. Client similarly if client auth i.e. cert is used, which it usually isn't; but even though that gives a fixed (EC)DH result, SSL still makes the sessionkeys unique by adding per-session/handshake nonces. __ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: trying to understand ECDHE operations
From: owner-openssl-us...@openssl.org On Behalf Of Michael D Sent: Friday, 08 January, 2010 08:53 Based on the old message snippet below, two questions: 1) Are the session keys then used by the symmetric cipher going forward? Or is there another step used to get those keys. Session keys are for symmetric data cipher AND data HMAC. (TLS actually calls the HMAC secret parameter secret although RFC 2104 and IME most other usage calls it key.) For example, if I am using 192 bit ECC, and using AES-128, what do I use for the 128 bit key? Two specified 128bit chunks of TLSPRF(master,otherstuff) where master = TLSPRF(premaster,otherstuff). See RFC 4346 8.1 and 6.3 (and 5) as modified by 4492 5.10. If I used AES 256, would I need a larger number of bits in the ECC curve? You don't NEED it. TLS key derivation generates enough key material, regardless of the size of premaster. However, premaster must contain enough entropy to support the desired security; per Kerckhoff (sp?) everything else is knowable by the attacker. 128bit symmetric is plenty for many years; like Schneier's stake it's stronger than the rest of your system. So AES256 versus 128 should only be needed for interop and/or buzzword compliance -- which can be useful, and (here) doesn't hurt. If you really want 128bit or more security level, you do need to use for keyagreement an EC curve big enough to provide that security level. According to NIST in SP 800-57, EC of 2N bits is roughly equivalent to symmetric of N bits, so even for full AES128 you should be using EC=256. But you may find other experts with different judgements. And you must also have enough good random-data generation involved (in ECDHE transients, or as noted static-ECDH nonces). I believe in practice this has more often been a weakness (and successful attack) than actual cryptography. But it's harder to analyze and basically impossible to prove. 2) The last part of the Where can I read about how SSL makes session unique with a nonce, how is that done and or where can I read about it? Much of RFC 4346. Static aka fixed ECDH (or DH) does use the certified key as the server part of keyagreement. Client similarly if client auth i.e. cert is used, which it usually isn't; but even though that gives a fixed (EC)DH result, SSL still makes the sessionkeys unique by adding per-session/handshake nonces. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: trying to understand ECDHE operations
Hello, As always, I appreciate all the help. Based on the old message snippet below, two questions: 1) Are the session keys then used by the symmetric cipher going forward? Or is there another step used to get those keys. For example, if I am using 192 bit ECC, and using AES-128, what do I use for the 128 bit key? If I used AES 256, would I need a larger number of bits in the ECC curve? 2) The last part of the Where can I read about how SSL makes session unique with a nonce, how is that done and or where can I read about it? Thank you, Mike Static aka fixed ECDH (or DH) does use the certified key as the server part of keyagreement. Client similarly if client auth i.e. cert is used, which it usually isn't; but even though that gives a fixed (EC)DH result, SSL still makes the sessionkeys unique by adding per-session/handshake nonces. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: trying to understand ECDHE operations
Ok, I reran my tests again...This time I added the -named_curve parameter...and do indeed get 50 byte key for the prime192v1 curve. However, if I run the server with my certificate and key, the client crashes processing the certificate. One more question. If the public key is in the certificate, why does the server send a server key exchange? Thank you everybody for your help. -Mike --- On Tue, 9/29/09, Michael D bsd_m...@yahoo.com wrote: From: Michael D bsd_m...@yahoo.com Subject: RE: trying to understand ECDHE operations To: openssl-users@openssl.org Date: Tuesday, September 29, 2009, 6:52 PM Dave, Thank you very much for your efforts. I must be doing something incorrect, as today I tried to re-run what I had done before, and the Linux PC running the s_client crashes processing the certificate. I am running snapshot builds. If you don't mind me pestering a bit more, how did you run the test? Thanks, I appreciate your help. Mike --- On Mon, 9/28/09, Dave Thompson dave.thomp...@princetonpayments.com wrote: From: Dave Thompson dave.thomp...@princetonpayments.com Subject: RE: trying to understand ECDHE operations To: openssl-users@openssl.org Date: Monday, September 28, 2009, 7:16 PM From: owner-openssl-us...@openssl.org On Behalf Of Michael D Sent: Friday, 25 September, 2009 09:32 Thank you for your reply. Maybe we can drill down on the client key exchange message first. Looking at the rfc I see it should hold: ECPoint ecdh_Yc; But for the prime192 curve, I would have expected an uncompressed point to be only 48 bytes. The size of the client key exchange message is 66 bytes. What is in the remaining bytes? First, a caveat: I set up a test to verify my understanding, and found (to my surprise) that s_server at least doesn't try to use the same curve for kECDHE as for aECDSA; it's a separate choice, and defaults to sectp163r2. Are you sure either your server or your client is selecting (forcing) prime192r1 for keyagreement AS WELL AS signing/authentication? That said, I get *49* bytes of ECDH data (Yc), plus a 1-byte length prefix totalling 50, in a ClientKeyExchange message totalling 54, in a (clear) handshake record totalling 59. Combined with other records/messages into a TCP segment etc. If that's not what you got, you did something different. __ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: trying to understand ECDHE operations
From: owner-openssl-us...@openssl.org On Behalf Of Michael D Sent: Wednesday, 30 September, 2009 13:12 (superseding previous, I assume) Ok, I reran my tests again...This time I added the -named_curve parameter...and do indeed get 50 byte key for the prime192v1 curve. However, if I run the server with my certificate and key, the client crashes processing the certificate. s_client or something else? can you narrow it down? One more question. If the public key is in the certificate, why does the server send a server key exchange? ECDHE = Elliptic Curve Diffie-Hellman EPHEMERAL Like DHE = Diffie-Hellman Ephemeral, both parties choose per-session(handshake) DH keypairs X,Y. Server sends Ys in ServerKeyExchange, client sends Yc in ClientKeyExchange. The only difference is DHE uses Z_p, ECDHE uses elliptic. The key in the cert is used only for authentication (signing). Static aka fixed ECDH (or DH) does use the certified key as the server part of keyagreement. Client similarly if client auth i.e. cert is used, which it usually isn't; but even though that gives a fixed (EC)DH result, SSL still makes the sessionkeys unique by adding per-session/handshake nonces. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: trying to understand ECDHE operations
Dave, Thank you for your kind help, I really appreciate it. I forgot to mention in my last email, which showed the results of the crash,..That it was running s_client. Thanks again, -Mike --- On Wed, 9/30/09, Dave Thompson dave.thomp...@princetonpayments.com wrote: From: Dave Thompson dave.thomp...@princetonpayments.com Subject: RE: trying to understand ECDHE operations To: openssl-users@openssl.org Date: Wednesday, September 30, 2009, 5:53 PM From: owner-openssl-us...@openssl.org On Behalf Of Michael D Sent: Wednesday, 30 September, 2009 13:12 (superseding previous, I assume) Ok, I reran my tests again...This time I added the -named_curve parameter...and do indeed get 50 byte key for the prime192v1 curve. However, if I run the server with my certificate and key, the client crashes processing the certificate. s_client or something else? can you narrow it down? One more question. If the public key is in the certificate, why does the server send a server key exchange? ECDHE = Elliptic Curve Diffie-Hellman EPHEMERAL Like DHE = Diffie-Hellman Ephemeral, both parties choose per-session(handshake) DH keypairs X,Y. Server sends Ys in ServerKeyExchange, client sends Yc in ClientKeyExchange. The only difference is DHE uses Z_p, ECDHE uses elliptic. The key in the cert is used only for authentication (signing). Static aka fixed ECDH (or DH) does use the certified key as the server part of keyagreement. Client similarly if client auth i.e. cert is used, which it usually isn't; but even though that gives a fixed (EC)DH result, SSL still makes the sessionkeys unique by adding per-session/handshake nonces. __ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: trying to understand ECDHE operations
Dave, Thank you very much for your efforts. I must be doing something incorrect, as today I tried to re-run what I had done before, and the Linux PC running the s_client crashes processing the certificate. I am running snapshot builds. If you don't mind me pestering a bit more, how did you run the test? Thanks, I appreciate your help. Mike --- On Mon, 9/28/09, Dave Thompson dave.thomp...@princetonpayments.com wrote: From: Dave Thompson dave.thomp...@princetonpayments.com Subject: RE: trying to understand ECDHE operations To: openssl-users@openssl.org Date: Monday, September 28, 2009, 7:16 PM From: owner-openssl-us...@openssl.org On Behalf Of Michael D Sent: Friday, 25 September, 2009 09:32 Thank you for your reply. Maybe we can drill down on the client key exchange message first. Looking at the rfc I see it should hold: ECPoint ecdh_Yc; But for the prime192 curve, I would have expected an uncompressed point to be only 48 bytes. The size of the client key exchange message is 66 bytes. What is in the remaining bytes? First, a caveat: I set up a test to verify my understanding, and found (to my surprise) that s_server at least doesn't try to use the same curve for kECDHE as for aECDSA; it's a separate choice, and defaults to sectp163r2. Are you sure either your server or your client is selecting (forcing) prime192r1 for keyagreement AS WELL AS signing/authentication? That said, I get *49* bytes of ECDH data (Yc), plus a 1-byte length prefix totalling 50, in a ClientKeyExchange message totalling 54, in a (clear) handshake record totalling 59. Combined with other records/messages into a TCP segment etc. If that's not what you got, you did something different. __ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: trying to understand ECDHE operations
From: owner-openssl-us...@openssl.org On Behalf Of Michael D Sent: Friday, 25 September, 2009 09:32 Thank you for your reply. Maybe we can drill down on the client key exchange message first. Looking at the rfc I see it should hold: ECPoint ecdh_Yc; But for the prime192 curve, I would have expected an uncompressed point to be only 48 bytes. The size of the client key exchange message is 66 bytes. What is in the remaining bytes? First, a caveat: I set up a test to verify my understanding, and found (to my surprise) that s_server at least doesn't try to use the same curve for kECDHE as for aECDSA; it's a separate choice, and defaults to sectp163r2. Are you sure either your server or your client is selecting (forcing) prime192r1 for keyagreement AS WELL AS signing/authentication? That said, I get *49* bytes of ECDH data (Yc), plus a 1-byte length prefix totalling 50, in a ClientKeyExchange message totalling 54, in a (clear) handshake record totalling 59. Combined with other records/messages into a TCP segment etc. If that's not what you got, you did something different. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: trying to understand ECDHE operations
Thank you for your reply. Maybe we can drill down on the client key exchange message first. Looking at the rfc I see it should hold: ECPoint ecdh_Yc; But for the prime192 curve, I would have expected an uncompressed point to be only 48 bytes. The size of the client key exchange message is 66 bytes. What is in the remaining bytes? Thanks, -Mike --- On Thu, 9/24/09, Dave Thompson dave.thomp...@princetonpayments.com wrote: From: Dave Thompson dave.thomp...@princetonpayments.com Subject: RE: trying to understand ECDHE operations To: openssl-users@openssl.org Date: Thursday, September 24, 2009, 6:23 PM From: owner-openssl-us...@openssl.org On Behalf Of Michael D Sent: Thursday, 24 September, 2009 09:12 I have been playing with an the command line tools of open SSL and am examining traces in hopes to get an understanding of how ECDHE works in real life. Remember commandline s_client and s_server can do their own 'tracing' (-msg and -debug displays); that may be helpful. My confusion focuses on the Client Key Exchange, Change Cipher Spec, Encrypted Handshake message. The server has selected: TLS_ECDHE_ECDSA_WITH_AES256_CBC_SHA (0x00a) for the cipher suite. My EC Public Key is: (from my certificate) 04:b9:53:3e:60:db:02:2c:6e:c4:ed:15:95:87:26: 1b:c9:96:ae:c9:a8:64:03:3a:6a:8d:14:ce:69:05: fc:4b:ea:4c:ed:a1:7f:6e:9f:37:74:20:f0:42:e2: 69:a0:02:48 The algorithm is: ASN1 OID: prime192v1 For ECDHE (E=ephmeral) the key in the cert is only for signing. The key-agreement key is in ServerKeyExchange for the server, and ClientKeyExchange for the client. I believe technically those don't have to be the same parameters (hence point size) as the signing key, but in practice they probably will be. So, to make this short, what exactly is contained in the: - Client Key Exchange message? Is this the clients 'public key', so should be the same size as the server public key? The same size as the server's (ephemeral) *key-agreement* key, yes, which as above is *probably* the same as the fixed-signing key. - Change cipher spec. Does this tell the server server to switch to the AES256? There is a ChangeCipherSpec message in each direction. Each one tells the recipient of that message to begin using the ciphersuite and (session) keys determined by the handshake, which in this case is AES256-CBC and HMAC-SHA1. - Encrypted handshake message? Does this contain a new key with which to use with AES256? The first message you see after ChangeCipherSpec, again in each direction, is actually the Finished message. It contains a (quasi) signature of the handshake sequence, which verifies the handshake wasn't tampered with. It shows up in a trace only as 'encrypted handshake message' because it is encrypted and so the trace tool can't decode its contents. Unless you have an SSL-aware trace tool with the privatekey material(s?) available to it. The session keys are derived from the 'premaster secret' agreed by the handshake plus nonces from each party in the Hello messages. This derivation is the same for all ciphersuites, only the premaster secret agreement varies; for ECDH(E) it uses elliptic Diffie-Hellman. __ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: trying to understand ECDHE operations
From: owner-openssl-us...@openssl.org On Behalf Of Michael D Sent: Thursday, 24 September, 2009 09:12 I have been playing with an the command line tools of open SSL and am examining traces in hopes to get an understanding of how ECDHE works in real life. Remember commandline s_client and s_server can do their own 'tracing' (-msg and -debug displays); that may be helpful. My confusion focuses on the Client Key Exchange, Change Cipher Spec, Encrypted Handshake message. The server has selected: TLS_ECDHE_ECDSA_WITH_AES256_CBC_SHA (0x00a) for the cipher suite. My EC Public Key is: (from my certificate) 04:b9:53:3e:60:db:02:2c:6e:c4:ed:15:95:87:26: 1b:c9:96:ae:c9:a8:64:03:3a:6a:8d:14:ce:69:05: fc:4b:ea:4c:ed:a1:7f:6e:9f:37:74:20:f0:42:e2: 69:a0:02:48 The algorithm is: ASN1 OID: prime192v1 For ECDHE (E=ephmeral) the key in the cert is only for signing. The key-agreement key is in ServerKeyExchange for the server, and ClientKeyExchange for the client. I believe technically those don't have to be the same parameters (hence point size) as the signing key, but in practice they probably will be. So, to make this short, what exactly is contained in the: - Client Key Exchange message? Is this the clients 'public key', so should be the same size as the server public key? The same size as the server's (ephemeral) *key-agreement* key, yes, which as above is *probably* the same as the fixed-signing key. - Change cipher spec. Does this tell the server server to switch to the AES256? There is a ChangeCipherSpec message in each direction. Each one tells the recipient of that message to begin using the ciphersuite and (session) keys determined by the handshake, which in this case is AES256-CBC and HMAC-SHA1. - Encrypted handshake message? Does this contain a new key with which to use with AES256? The first message you see after ChangeCipherSpec, again in each direction, is actually the Finished message. It contains a (quasi) signature of the handshake sequence, which verifies the handshake wasn't tampered with. It shows up in a trace only as 'encrypted handshake message' because it is encrypted and so the trace tool can't decode its contents. Unless you have an SSL-aware trace tool with the privatekey material(s?) available to it. The session keys are derived from the 'premaster secret' agreed by the handshake plus nonces from each party in the Hello messages. This derivation is the same for all ciphersuites, only the premaster secret agreement varies; for ECDH(E) it uses elliptic Diffie-Hellman. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
