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 List openssl-users@openssl.org Automated List Manager majord...@openssl.org
