On Fri, Dec 7, 2018 at 12:26 PM Paul Smith <p...@mad-scientist.net> wrote: > 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.
I have code in nodejs and Python that uses all the primitives I mentioned, so yeah. The crypto libraries on github.com/web-push-libs should be a gold mine if you have to go cross-language. > 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. Yes, HKDF is best practice here. > 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. GCM is just CTR mode with a MAC. So all the limitations of CTR apply, plus the lack of authentication means that the ciphertext will be malleable. I don't believe that there are many settings where lack of authentication is safe. > 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. The limits on GCM derive mostly from the limits on authentication and risk of collision. See http://www.isg.rhul.ac.uk/~kp/TLS-AEbounds.pdf for that analysis. If you have individual records (which I believe that you do), then you can send 2^28 (ish) records of 2^14 bytes each provided that the IV is guaranteed unique. If you need more, then you can generate new key/IV pairs with rekeying. See https://tools.ietf.org/html/draft-irtf-cfrg-re-keying-13 Without a MAC the limit is 1. I can't emphasize the value of AEAD enough here. > > 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. You can derive a random part from the SRP secret, just like TLS does and XOR that with a counter. For CTR mode, that might be better than relying on a CSPRNG. It also means that you don't need to send randomness with every record. > 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. The code points to specific functions. Take a look at the PK11_* calls. > 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. Yeah, it's a failing. NSS isn't very well documented (we spend our time on de-crufting it mostly). -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
