Using AES256 cipher directly...?

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

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!

--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto
Reply | Threaded
Open this post in threaded view
|

Re: Using AES256 cipher directly...?

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,,,

On Fri, Dec 7, 2018 at 9:18 AM Paul Smith <[hidden email]> wrote:
> I have a session key from SRP.  I need the following:
>  * 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..

>  * 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

>  * 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.
--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto
Reply | Threaded
Open this post in threaded view
|

Re: Using AES256 cipher directly...?

Paul Smith
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
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto
Reply | Threaded
Open this post in threaded view
|

Re: Using AES256 cipher directly...?

Martin Thomson
On Fri, Dec 7, 2018 at 12:26 PM Paul Smith <[hidden email]> 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
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto
Reply | Threaded
Open this post in threaded view
|

Re: Using AES256 cipher directly...?

Hubert Kario
In reply to this post by Paul Smith
On Friday, 7 December 2018 18:24:38 CET Paul Smith wrote:

> 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.
all that sounds like something that will be very painful to do in multiple
libraries; having to support two, not just one legacy implementation when the
migration happens to TLS doesn't seem to me as something that will help with
that (not to mention that leaving such dead and already vulnerable code is a
huge liability)

--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purky┼łova 115, 612 00  Brno, Czech Republic
--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto

signature.asc (849 bytes) Download Attachment