[openssl-users] [AES-GCM] TLS packet nounce_explicit overflow

[Michael Wojcik]

> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf
> Of Jakob Bohm
> Sent: Thursday, March 09, 2017 19:05
> To: openssl-users at openssl.org
> Subject: Re: [openssl-users] [AES-GCM] TLS packet nounce_explicit overflow

First, note my original calculation was wrong - I was thinking the counter was 64 bits. In fact the nonce is 64 bits, and the counter is 32. So even if you only generate one packet per millisecond, you could wrap in under 50 days.

Can you send a packet per millisecond? Let's assume Ethernet framing, TCP, and IPv4. That's 64 bytes of overhead. TLS adds around 45 bytes of overhead to each packet. I can't be bothered to check now, but let's assume you can send a TLS packet with no application data, so that's 109 bytes per packet. At one per millisecond that's 8.72e5 b/s, so network bandwith isn't a problem (we'll assume this is over a LAN). Can the receiver keep up? (We can't sustain the rate if the receiver's window keeps filling.) Let's hope so; the node's not much use if it can't keep up with its network interface. (Also assume we've disabled Nagle.)

Now, 50 days is still a rather long-lived conversation. Maybe we can do one or two orders of magnitude better. We're still fine on bandwidth (for a LAN), so should still be OK on the receiver's stack as well. OpenSSL should be able to verify and decrypt 100,000 messages a second on modern hardware, I'd think; I've never bothered to benchmark that, but it can certainly do the individual operations much faster.

So now we're down to about 11 hours. At this point we seem to have a legitimate concern; not for every application, but for some, certainly.

I haven't looked to see what the RFC says about AES with GCM combining and what measures implementations should take to avoid the counter wrapping. In any case, my apologies to Akshar Kanak. (And, of course, I may have bungled my back-of-the-envelope calculations again...)

> But if the starting value is random, the number of increments
> before overflow or wrap will be random too (and could
> hypothetically, but rarely, be as little as 1).

It should be computed modulo 2**32 (i.e. as an unsigned 64-bit integer). It's not overflow or wrapping past the maximum value that would be a problem; it's wrapping all the way back around so a value is repeated.

I note that the recently revealed CIA guidelines for using cryptography (part of Year Zero) say the counter should always start at 0. (The explicit nonce is supposed to avoid ever using the same IV twice with a given key in GCM.)

> Anyway, I thought TLS records were limited to slightly more than
> 16K each, so the in-record block counter would not count very far.

Perhaps it's too late, or perhaps I'm just being dense, but I'm not sure what you're getting at with this.

RFC 5246 says the TLSv1.2 record sequence number is a 64-bit value, that it starts at 0, and that if it would wrap you have to renegotiate (or start another six-hundred-year conversation, I guess).

Probably I'm just misunderstanding your point here though.

Michael Wojcik 
Distinguished Engineer, Micro Focus