Thanks for your reply Martin! On Fri, 2018-12-07 at 10:46 -0500, Martin Thomson wrote: > Unfortunately, we can't say that we have a PAKE, so I appreciate that > you aren't able to just drop that in.
A concern is that I have to support full backward-compatibility, not a "flag day" upgrade, so unless a new PAKE behaves identically to my existing SRP implementation it's probably not worth it to switch. When I move to TLS I'll also have to maintain control of the initial connection message, at least, to support backward compatibility... that'll be its own brand of fun. > For key derivation, you probably want HKDF with SHA-256 rather than a > straight hash function. Another thing that I didn't bring up: I need to implement this in other languages (at least Java and Python), so clients can connect to the service. So I need to consider availability in other crypto libraries like Python ssl and javax crypto or BouncyCastle. I'm sure they have HKDF too of course. My session key is already larger than 256bits so I don't need expansion, and I'll only ever extract a single AES key from each session key. Is HKDF still recommended? I'm definitely no expert. Currently the code uses SHA1 to get a 160bit key for use with RC4 (sigh). > I think that what you want is AES-GCM rather than one of the modes > closer to the block function. Do you have a constraint that prevents > records from being expanded? I have two concerns with GCM. One is that the folks pushing for this change specifically requested CTR. I can certainly counter-propose but it could be one of these "the customer is always right" things, at least until we get to full TLS support. We understand that CTR doesn't provide any MAC facilities. The second concern is that I understood you can only safely encrypt 64GiB with a given key/IV in GCM. Because our connections are so long- lived and are constantly sending traffic I'm confident that we will need to send more than that over a connection lifetime. Of course I don't understand GCM as well as CTR so maybe I'm wrong about the specifics of this limitation. > Random nonces are probably not as good as a deterministic nonce (like > a counter). My plan was to use a 64bit random nonce appended with a 64bit counter for CTR mode. I appreciate the code pointers and will study them; if you could narrow it down or give more specifics (even just function names I should be looking for) that would be very helpful. Starting from its man pages I was able to read the libressl code to get an idea of how to use that interface, but I couldn't find any similar API docs for NSS; I'll try delving into the NSS code as well if I can find my footing. Cheers! -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
