Quantcast

[AES-GCM] TLS packet nounce_explicit overflow

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[AES-GCM] TLS packet nounce_explicit overflow

Akshar Kanak
Dear team
    In AES-GCM mode i know that the final counter will be
    [4 bytes salt which is negotiated between client and serevr ]
    +
    [8 bytes of random bytes which are generated using RAND_bytes (nounce_explicit).
     nounce]
    +
    [32 bit counter ]
   
    nounce_explicit will be incremented for every TLS packet and will be sent in the packet .
    if the nounce _explicit overflows or overlaps , then does openssl code handles it (atleast by initiating renegotiation )?
    I know that it will take 2^64 TLS packets in one direction . It is practically not possible
    but theoritically possible .

    32 bit counter should not be a problem , since individual TLS packet has to be more than 68GB
    for this counter to overflow or overlap . This will not be possible . Please correct me if I am wrong ?
   
    Thanks and regards
    Akshar    

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [AES-GCM] TLS packet nounce_explicit overflow

OpenSSL - User mailing list

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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [AES-GCM] TLS packet nounce_explicit overflow

Michael Wojcik

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:[hidden email]] On Behalf Of Salz, Rich via openssl-users
Sent: Thursday, March 09, 2017 05:49
To: [hidden email]
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [AES-GCM] TLS packet nounce_explicit overflow

Jakob Bohm-7
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:[hidden email]] *On
> Behalf Of *Salz, Rich via openssl-users
> *Sent:* Thursday, March 09, 2017 05:49
> *To:* [hidden email]
> *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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [AES-GCM] TLS packet nounce_explicit overflow

Michael Wojcik
> From: openssl-users [mailto:[hidden email]] On Behalf
> Of Jakob Bohm
> Sent: Thursday, March 09, 2017 19:05
> To: [hidden email]
> 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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [AES-GCM] TLS packet nounce_explicit overflow

Jakob Bohm-7
On 10/03/2017 04:34, Michael Wojcik wrote:

>> From: openssl-users [mailto:[hidden email]] On Behalf
>> Of Jakob Bohm
>> Sent: Thursday, March 09, 2017 19:05
>> To: [hidden email]
>> 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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [AES-GCM] TLS packet nounce_explicit overflow

Michael Wojcik
> From: openssl-users [mailto:[hidden email]] On Behalf
> Of Jakob Bohm
> Sent: Thursday, March 09, 2017 21:43
> To: [hidden email]
> 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
Loading...