On 10/03/2017 04:34, Michael Wojcik wrote:
From: openssl-users [mailto:openssl-users-bounces@xxxxxxxxxxx] On Behalf
Of Jakob Bohm
Sent: Thursday, March 09, 2017 19:05
To: openssl-users@xxxxxxxxxxx
Subject: Re: [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.
But that's not what you asked, and doing circular mod 2**bitsize is
a good solution as long as you don't go full circle.
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.)
I assumed the counter started at 0 for each record and the 64 bit
value was the one incremented.
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.
I seem to recall (I haven't looked at GCM details in years) that
the 128 bit value is incremented for each 128 bit block of plaintext,
plus once more for the mac-like tag.
From this I assumed the 32 bit field was the per-128-bit counter and the
64 bit field you asked about was the per-record counter.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
