Using AES256 cipher directly...?

[Paul Smith]

Hi all. Hopefully this is the right place.

I have a system (first created ~8 years ago) based on SRP and RC4 (I
know). This system creates TCP connections rarely and uses them for a
very long time, and they cannot be dropped/reconnected without user-
visible disruption, so it's very different from a browser/web server
setup.

In the fullness of time I'd like to update the system to use full TLS
1.3 but what I need to do in the very immediate future (like, the next
month or so) is replace RC4 with something secure while keeping my
existing SRP key exchange. I'm looking at AES256-CTR.

I have a session key from SRP. I need the following:
* SHA256 (?) to convert the session key into a 256bit key for AES
* AES256, preferably in CTR mode but I can handle that myself easily
if I have access to the block cipher.
* Strong RNG for generating a CTR nonce. I can use my own RNG if it's
easier.

I hoped to use NSS for this, especially because I'd like to be able to
use the same library to get TLS 1.3 in the future, but I must confess
to being utterly stymied by the lack of API descriptions.

Is there anywhere I can look to find documentation for, or examples of,
accessing the various ciphers and hash functions through the NSS API?
Or, can someone jot down some quick pseudo-code to get me going in the
right direction?

Or, is NSS just not an appropriate solution for my situation?

Thanks!

[Martin Thomson]

Hi Paul,

I think NSS has all you need here. Including TLS 1.3 should you
prefer that. Unfortunately, we can't say that we have a PAKE, so I
appreciate that you aren't able to just drop that in. In the
meantime,,,

Post by Paul Smith
* SHA256 (?) to convert the session key into a 256bit key for AES

For key derivation, you probably want HKDF with SHA-256 rather than a
straight hash function.

I have an example of this that you can look at:
https://searchfox.org/nss/source/lib/ssl/tls13hkdf.c - that's ALL the
code for TLS 1.3, but a good basis for a design..

Post by Paul Smith
* AES256, preferably in CTR mode but I can handle that myself easily
if I have access to the block cipher.

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?

There are examples of how to use that in the TLS 1.3 code:
https://searchfox.org/nss/rev/3b6a2dd92c56b13f15ad3d0bf2a0e451b898612f/lib/ssl/tls13con.c#3571

Post by Paul Smith
* Strong RNG for generating a CTR nonce. I can use my own RNG if it's
easier.

Random nonces are probably not as good as a deterministic nonce (like
a counter). But if you need one, then PK11_GenerateRandom() works
very well. Use the above site to look for examples.

[Paul Smith]

Thanks for your reply Martin!

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!

[Martin Thomson]

Post by Paul Smith
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.

Post by Paul Smith
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.

Post by Paul Smith
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.

Post by Paul Smith
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.

Post by Paul Smith

Post by Martin Thomson
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.

Post by Paul Smith
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.

Post by Paul Smith
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).