Re: Using AES256 cipher directly...?

On Fri, Dec 7, 2018 at 12:26 PM Paul Smith <[email protected]> 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
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-crypto