Re: [openssl-users] [AES-GCM] TLS packet nounce_explicit overflow
> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf > Of Jakob Bohm > Sent: Thursday, March 09, 2017 21:43 > To: openssl-users@openssl.org > Subject: Re: [openssl-users] [AES-GCM] TLS packet nounce_explicit overflow > > 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. I'll have to check the spec myself; I haven't read it in years either. > 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. A minor correction - it wasn't my question. I had followed up after Rich's initial reply. But no matter; it's a discussion now. Thanks, Michael Wojcik Distinguished Engineer, Micro Focus -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] [AES-GCM] TLS packet nounce_explicit overflow
On 10/03/2017 04:34, Michael Wojcik wrote: From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of Jakob Bohm Sent: Thursday, March 09, 2017 19:05 To: openssl-users@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. 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
Re: [openssl-users] [AES-GCM] TLS packet nounce_explicit overflow
> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf > Of Jakob Bohm > Sent: Thursday, March 09, 2017 19:05 > To: openssl-users@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 -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] [AES-GCM] TLS packet nounce_explicit overflow
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). Anyway, I thought TLS records were limited to slightly more than 16K each, so the in-record block counter would not count very far. On 09/03/2017 16:26, Michael Wojcik wrote: And there's no reason for it to do so, because it isn't needed. If you generate one TLS packet every nanosecond, it will take nearly six centuries to overflow, by which time the version of TLS you're using will have been deprecated and all security guarantees are moot anyway. In general, most security experts recommend against keeping a TLS conversation open for years at a time. Michael Wojcik Distinguished Engineer, Micro Focus *From:*openssl-users [mailto:openssl-users-boun...@openssl.org] *On Behalf Of *Salz, Rich via openssl-users *Sent:* Thursday, March 09, 2017 05:49 *To:* openssl-users@openssl.org *Subject:* Re: [openssl-users] [AES-GCM] TLS packet nounce_explicit overflow No, it does not do this automatically. *if the nounce _explicit overflows or overlaps , then does openssl code handles it (atleast by initiating renegotiation )?* 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
Re: [openssl-users] [AES-GCM] TLS packet nounce_explicit overflow
And there's no reason for it to do so, because it isn't needed. If you generate one TLS packet every nanosecond, it will take nearly six centuries to overflow, by which time the version of TLS you're using will have been deprecated and all security guarantees are moot anyway. In general, most security experts recommend against keeping a TLS conversation open for years at a time. Michael Wojcik Distinguished Engineer, Micro Focus From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of Salz, Rich via openssl-users Sent: Thursday, March 09, 2017 05:49 To: openssl-users@openssl.org Subject: Re: [openssl-users] [AES-GCM] TLS packet nounce_explicit overflow No, it does not do this automatically. if the nounce _explicit overflows or overlaps , then does openssl code handles it (atleast by initiating renegotiation )? -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] [AES-GCM] TLS packet nounce_explicit overflow
No, it does not do this automatically. if the nounce _explicit overflows or overlaps , then does openssl code handles it (atleast by initiating renegotiation )? -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
