Hey Martin,
You're right, this analysis works for any block cipher with 128 bit
output that is "good enough" (a pseudorandom permutation), and so for
all versions of AES regardless of the key size. Determining the
appropriate key size for the block cipher relies on accounting for
possible att
On 9 March 2016 at 09:16, aluykx wrote:
> Kenny Paterson and I prepared a document providing an overview of how much
> data ChaCha20+Poly1305 and AES-GCM can process with a single key. Besides
> summarizing the results, the document also gives an explanation of why the
> limits are there. The docu
* aluykx [23/03/2016 09:12:02] wrote:
> >Finally, and this calls for an opinion: do you believe that given these
> >results
> >we should include a KeyUpdate feature in TLS 1.3?
>
> Ideally it would be better to include a KeyUpdate feature, but the added
> complexity could risk introducing vulnera
Hey,
1. As I understand it, failure in these models is fairly catastrophic,
so I should be reading Table 1 as "chance of total collapse of
confidentiality",
not "chance of being able to read one plaintext" value. Is that
correct?
Actually, confidentiality will not collapse, the limit indicate
Atul, Kenny,
Thanks for doing this. My initial impression is that these results are
uncomfortably
close to the line for AES-GCM, especially for the scenario where we have
multiple
keys: there are probably well upward of 2^{32} HTTPS connections a day.
A few questions:
1. As I understand it, fai
Kenny Paterson and I prepared a document providing an overview of how
much data ChaCha20+Poly1305 and AES-GCM can process with a single key.
Besides summarizing the results, the document also gives an explanation
of why the limits are there. The document confirms the analysis done by
Watson and
On 01/04/2016 06:22 AM, Florian Weimer wrote:
> On 01/04/2016 01:19 PM, Hubert Kario wrote:
>
>>> Dealing with this during the initial handshake is fine. But
>>> supporting direction-switching after that is *really* difficult.
>> yes, this is a bit more problematic, especially for one-sided transf
On 01/04/2016 01:19 PM, Hubert Kario wrote:
>> Dealing with this during the initial handshake is fine. But
>> supporting direction-switching after that is *really* difficult.
>
> yes, this is a bit more problematic, especially for one-sided transfers.
> For example, when one side is just sendin
On Monday 04 January 2016 13:02:57 Florian Weimer wrote:
> On 01/04/2016 12:59 PM, Hubert Kario wrote:
> > On Monday 28 December 2015 21:08:10 Florian Weimer wrote:
> >> On 12/21/2015 01:41 PM, Hubert Kario wrote:
> >>> if the rekey doesn't allow the application to change
> >>> authentication
> >>>
On 12/28/2015 10:09 PM, Salz, Rich wrote:
>> When the key is changed, the change procedure should involve new randomness.
>
> I don't think this is necessary, and I don't think the common crypto
> expertise agrees with you, either. But I am not a cryptographer, maybe one of
> the ones on this l
On 01/04/2016 12:59 PM, Hubert Kario wrote:
> On Monday 28 December 2015 21:08:10 Florian Weimer wrote:
>> On 12/21/2015 01:41 PM, Hubert Kario wrote:
>>> if the rekey doesn't allow the application to change authentication
>>> tokens (as it now stands), then rekey is much more secure than
>>> reneg
On Monday 28 December 2015 21:08:10 Florian Weimer wrote:
> On 12/21/2015 01:41 PM, Hubert Kario wrote:
> > if the rekey doesn't allow the application to change authentication
> > tokens (as it now stands), then rekey is much more secure than
> > renegotiation was in TLS <= 1.2
>
> You still have
> "ER" == Eric Rescorla writes:
ER> In TLS, we use a distinct nonce for each record and then a block counter
ER> inside the record. So, it's true that you couldn't encrypt a record that
ER> was more than 2^{32} * 256 bits long, but since TLS records can't be
ER> more than 16KB long anyway, th
On Fri, Jan 1, 2016 at 4:42 PM, James Cloos wrote:
> > "ER" == Eric Rescorla writes:
>
> ER> Can you elaborate on this point a bit? I haven't been focusing on
> ER> ChaCha, but we're not quite done with ChaCha yet, so if changes are
> ER> needed, now would be the time.
>
> The switch from 64
On Tue, Dec 29, 2015 at 2:10 PM, Brian Smith wrote:
> Ilari Liusvaara wrote:
>>
>> OTOH, you can't drop an attacker knowing older key without doing
>> new key exchange.
>
>
> I think it would be very unfortunate to have the complexity of key update
> (the new keys are derived from the old keys) w
> "ER" == Eric Rescorla writes:
ER> Can you elaborate on this point a bit? I haven't been focusing on
ER> ChaCha, but we're not quite done with ChaCha yet, so if changes are
ER> needed, now would be the time.
The switch from 64 bit nonce + 64 bit counter to 96 bit nonce + 32 bit
counter mean
On Fri, Jan 01, 2016 at 02:00:07PM -0500, James Cloos wrote:
> [Msg for followup picked at random from this thread -JimC]
>
> One thing we should remember on this thread is that it does not only
> apply to aes and its' 128-bit block size.
>
> Because TLS chose to create a NotQuiteChaCha rather th
On Fri, Jan 1, 2016 at 11:00 AM, James Cloos wrote:
> [Msg for followup picked at random from this thread -JimC]
>
> One thing we should remember on this thread is that it does not only
> apply to aes and its' 128-bit block size.
>
> Because TLS chose to create a NotQuiteChaCha rather than use Ch
Quoting Aaron Zauner :
On the other hand, after 2^60 OCB messages of 2^16 blocks (and thus 2^76
total blocks), a block collision is almost guaranteed to have happened,
enabling the aforementioned forgeries.
Sure. Would you see any way to improve this situation in the draft,
i.e. give implement
[Msg for followup picked at random from this thread -JimC]
One thing we should remember on this thread is that it does not only
apply to aes and its' 128-bit block size.
Because TLS chose to create a NotQuiteChaCha rather than use ChaCha,
its chacha20poly1305 also has a small data volume limit (2
Hi,
* sne...@dei.uc.pt [01/01/2016 18:19:26] wrote:
> The contention with GCM in this thread has been, so far, focused on
> confidentiality. This is because, by a result of Bernstein [1] (see also
> Appendix C of [2]), after q = 2^60 messages sent, plus q' = 2^60 attempted
> forgeries by an attac
Quoting Aaron Zauner :
* Samuel Neves [01/01/2016 12:19:36] wrote:
OCB is, if anything, worse than GCM when it comes to data volume
limits. It has the same confidentiality bounds as GCM
(slightly worse, in fact), but once you hit a collision you also
lose authenticity and enable simple forg
Hi Samuel,
* Samuel Neves [01/01/2016 12:19:36] wrote:
> OCB is, if anything, worse than GCM when it comes to data volume limits. It
> has the same confidentiality bounds as GCM
> (slightly worse, in fact), but once you hit a collision you also lose
> authenticity and enable simple forgeries [1
On Fri, Jan 01, 2016 at 01:54:00PM +0100, Henrick Wibell Hellström wrote:
> I think it is a good idea to rekey AES-GCM after approximately 2^32 records,
> give or take a few magnitudes.
>
> The question for me isn't whether AES-GCM requires frequent rekeying (it
> does), but exactly how much compl
I think it is a good idea to rekey AES-GCM after approximately 2^32
records, give or take a few magnitudes.
The question for me isn't whether AES-GCM requires frequent rekeying (it
does), but exactly how much complexity the rekeying mechanism would add,
to the protocol and to implementations.
On 01/01/2016 06:35 AM, Aaron Zauner wrote:
> This might be a good time to point again to my existing AES-OCB
> draft that hasn't really seen a lot of discussion nor love lately.
> It expired but I've recently updated the draft (not yet uploaded
> to IETF as I'm waiting for implementer feedback fro
On Fri, Jan 01, 2016 at 08:04:11AM +0100, Aaron Zauner wrote:
> * Aaron Zauner [01/01/2016 07:35:26] wrote:
> > This might be a good time to point again to my existing AES-OCB
> > draft that hasn't really seen a lot of discussion nor love lately.
> > It expired but I've recently updated the draft
* Aaron Zauner [01/01/2016 07:35:26] wrote:
> This might be a good time to point again to my existing AES-OCB
> draft that hasn't really seen a lot of discussion nor love lately.
> It expired but I've recently updated the draft (not yet uploaded
> to IETF as I'm waiting for implementer feedback fr
Hi,
* Simon Josefsson [16/12/2015 09:44:55] wrote:
> I don't like re-keying. It is usually a sign that your primitives are
> too weak and you are attempting to hide that fact. To me, it is similar
> to discard the first X byte of RC4 output.
>
> If AES-GCM cannot provide confidentiality beyond
I like option (2) from Eric's taxonomy.
Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network.
From: Eric Rescorla
Sent: Tuesday, December 29, 2015 18:12
To: Dave Garrett
Cc: Florian Weimer; tls@ietf.org
Subject: Re: [TLS] Data volume limits
On Tue, Dec 29, 2015 at
On Tue, Dec 29, 2015 at 5:08 PM, Dave Garrett
wrote:
> On Tuesday, December 29, 2015 02:10:25 pm Brian Smith wrote:
> > Note that NIST Special Publication 800-133 [1] defines these separate
> > terms, and I suggest we use them in this conversation to avoid confusion:
> >
> > Key update: A procedu
On Tuesday, December 29, 2015 02:10:25 pm Brian Smith wrote:
> Note that NIST Special Publication 800-133 [1] defines these separate
> terms, and I suggest we use them in this conversation to avoid confusion:
>
> Key update: A procedure in which a new cryptographic key is computed as a
> function
On Tue, Dec 29, 2015 at 2:10 PM, Brian Smith wrote:
> Ilari Liusvaara wrote:
>
>> OTOH, you can't drop an attacker knowing older key without doing
>> new key exchange.
>>
>
> I think it would be very unfortunate to have the complexity of key update
> (the new keys are derived from the old keys)
Ilari Liusvaara wrote:
> OTOH, you can't drop an attacker knowing older key without doing
> new key exchange.
>
I think it would be very unfortunate to have the complexity of key update
(the new keys are derived from the old keys) without having the benefits of
rekeying (the new keys are indepen
.
From: TLS on behalf of Dang, Quynh
Sent: Friday, December 18, 2015 10:49 AM
To: tls@ietf.org
Subject: Re: [TLS] Data volume limits
The collision probability of ciphertext blocks also depends on the size of the
plaintext (record size in a TLS
Blumenthal, Uri - 0553 - MITLL; Eric Rescorla
Cc: Florian Weimer; tls@ietf.org
Subject: RE: [TLS] Data volume limits
> When the key is changed, the change procedure should involve new randomness.
I don't think this is necessary, and I don't think the common crypto expertise
agrees
> When the key is changed, the change procedure should involve new randomness.
I don't think this is necessary, and I don't think the common crypto expertise
agrees with you, either. But I am not a cryptographer, maybe one of the ones on
this list can chime in.
"Crank the KDF" suffices.
On Mon, Dec 28, 2015 at 08:51:01PM +, Blumenthal, Uri - 0553 - MITLL wrote:
> When too much plaintext has been encrypted with the same key, the
> key needs to be changed. When the key is changed, the change
> procedure should involve new randomness.
>
> What's the confusion here???
OTOH, you
Eric Rescorla
Sent: Monday, December 28, 2015 15:47
To: Blumenthal, Uri - 0553 - MITLL
Cc: Florian Weimer; tls@ietf.org
Subject: Re: [TLS] Data volume limits
To be clear, the concern that we are trying to alleviate is encrypting too much
plaintext with the
same key (see the discussion by Watson a
;
>
> Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network.
> *From: *Eric Rescorla
> *Sent: *Monday, December 28, 2015 15:37
> *To: *Florian Weimer
> *Cc: *tls@ietf.org
> *Subject: *Re: [TLS] Data volume limits
>
>
>
> On Mon, Dec 28, 2015 at 3:
Off-hand, key update or re-key without new/fresh randomness sounds weird.
Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network.
From: Eric Rescorla
Sent: Monday, December 28, 2015 15:37
To: Florian Weimer
Cc: tls@ietf.org
Subject: Re: [TLS] Data volume limits
On Mon
On Mon, Dec 28, 2015 at 3:33 PM, Florian Weimer wrote:
> On 12/28/2015 09:11 PM, Eric Rescorla wrote:
>
> >> You still have the added complexity that during rekey, you need to
> >> temporarily switch from mere sending or receiving to at least
> >> half-duplex interaction.
> >>
> >
> > That's not
On 12/28/2015 09:11 PM, Eric Rescorla wrote:
>> You still have the added complexity that during rekey, you need to
>> temporarily switch from mere sending or receiving to at least
>> half-duplex interaction.
>>
>
> That's not intended. Indeed, you need to be able to handle the old key
> in order
On Mon, Dec 28, 2015 at 3:08 PM, Florian Weimer wrote:
> On 12/21/2015 01:41 PM, Hubert Kario wrote:
>
> > if the rekey doesn't allow the application to change authentication
> > tokens (as it now stands), then rekey is much more secure than
> > renegotiation was in TLS <= 1.2
>
> You still have
On 12/21/2015 01:41 PM, Hubert Kario wrote:
> if the rekey doesn't allow the application to change authentication
> tokens (as it now stands), then rekey is much more secure than
> renegotiation was in TLS <= 1.2
You still have the added complexity that during rekey, you need to
temporarily swi
Scott, Henrick,
Are you persuaded by Watson's analysis?
Thanks,
-Ekr
On Mon, Dec 21, 2015 at 7:41 AM, Hubert Kario wrote:
> On Tuesday 15 December 2015 20:01:58 Bill Frantz wrote:
> > So we have to trade off the risks of too much data vs. the risks
> > of a complex rekey protocol vs. the ri
On Tuesday 15 December 2015 20:01:58 Bill Frantz wrote:
> So we have to trade off the risks of too much data vs. the risks
> of a complex rekey protocol vs. the risks having the big data
> applications build new connections every 2**36 or so bytes.
>
> If we don't have rekeying, then the big data
d IND-* property, the above restriction is not needed.
Quynh.
From: TLS on behalf of Yoav Nir
Sent: Thursday, December 17, 2015 6:07 AM
To: Nikos Mavrogiannopoulos
Cc: tls@ietf.org; Simon Josefsson
Subject: Re: [TLS] Data volume limits
> On 17 Dec 2015, at
> On 17 Dec 2015, at 10:19 AM, Nikos Mavrogiannopoulos wrote:
>
> On Wed, 2015-12-16 at 09:57 -1000, Brian Smith wrote:
>
>> Therefore, I think we shouldn't add the rekeying mechanism as it is
>> unnecessary and it adds too much complexity.
>
> Any arbitrary limit for a TLS connection is almo
On Wed, 2015-12-16 at 09:57 -1000, Brian Smith wrote:
> Therefore, I think we shouldn't add the rekeying mechanism as it is
> unnecessary and it adds too much complexity.
Any arbitrary limit for a TLS connection is almost guaranteed to cause
problems in the future. We cannot predict whether 2^x
On Dec 16, 2015 5:26 PM, "Brian Smith" wrote:
>
> Watson Ladd wrote:
>
>> Brian Smith wrote:
>> > So, if [2] is correct, then we can take Watson's 2^36 and multiply it
by
>> > 2^17 to get 2^53 bytes as the limit? It seems so, since [2] claims that
>> > they've improved the bounds by 2^17. Note t
Watson Ladd wrote:
> Brian Smith wrote:
> > So, if [2] is correct, then we can take Watson's 2^36 and multiply it by
> > 2^17 to get 2^53 bytes as the limit? It seems so, since [2] claims that
> > they've improved the bounds by 2^17. Note that 3 out of 4 of the authors
> of
> > [2] are the same
On Wed, Dec 16, 2015 at 2:57 PM, Brian Smith wrote:
> Eric Rescorla wrote:
>>
>>
>> I believe Watson provided one a while back at:
>> https://www.ietf.org/mail-archive/web/tls/current/msg18240.html
>
>
> So, if [2] is correct, then we can take Watson's 2^36 and multiply it by
> 2^17 to get 2^53 b
Eric Rescorla wrote:
>
> I believe Watson provided one a while back at:
> https://www.ietf.org/mail-archive/web/tls/current/msg18240.html
>
So, if [2] is correct, then we can take Watson's 2^36 and multiply it by
2^17 to get 2^53 bytes as the limit? It seems so, since [2] claims that
they've imp
On Wed, Dec 16, 2015 at 1:14 PM, Blumenthal, Uri - 0553 - MITLL
wrote:
> On 12/16/15, 12:16 , "Watson Ladd" wrote:
>
>>On Wed, Dec 16, 2015 at 12:09 PM, Blumenthal, Uri - 0553 - MITLL
>> wrote:
>>> On 12/16/15, 10:50, "Watson Ladd" wrote:
>If there are practical consequences, like loss of co
On 12/16/15, 12:16 , "Watson Ladd" wrote:
>On Wed, Dec 16, 2015 at 12:09 PM, Blumenthal, Uri - 0553 - MITLL
> wrote:
>> On 12/16/15, 10:50, "Watson Ladd" wrote:
If there are practical consequences, like loss of confidentiality – I’m
dying to hear the outline of a practical attack.
>>>
>
unds, but a mode limitation.
Since you've agreed we can rekey more frequently
>
>
>>>From: TLS on behalf of "Dang, Quynh"
>>>
>>> Date: Wednesday, December 16, 2015 at 07:21
>>> To: Eric Rescorla , "tls@ietf.org"
>>>
>&g
attack.
>>From: TLS on behalf of "Dang, Quynh"
>>
>> Date: Wednesday, December 16, 2015 at 07:21
>> To: Eric Rescorla , "tls@ietf.org"
>>
>> Subject: Re: [TLS] Data volume limits
>>
>> Hi Eric,
>>
>>
>> I
like 128 GByte per connection?
> --
> Regards,
> Uri Blumenthal
>
> From: TLS on behalf of "Dang, Quynh"
>
> Date: Wednesday, December 16, 2015 at 07:21
> To: Eric Rescorla , "tls@ietf.org"
>
> Subject: Re: [TLS] Data volume limits
>
> Hi Eric,
>
>
gt; on behalf of
"Dang, Quynh" mailto:quynh.d...@nist.gov>>
Date: Wednesday, December 16, 2015 at 07:21
To: Eric Rescorla mailto:e...@rtfm.com>>,
"tls@ietf.org<mailto:tls@ietf.org>" mailto:tls@ietf.org>>
Subject: Re: [TLS] Data volume limits
Hi E
f.org
Subject: Re: [TLS] Data volume limits
On Wed, Dec 16, 2015 at 12:44 AM, Simon Josefsson
mailto:si...@josefsson.org>> wrote:
Eric Rescorla mailto:e...@rtfm.com>> writes:
> Watson kindly prepared some text that described the limits on what's safe
> for AES-GCM and restric
On Wed, Dec 16, 2015 at 7:07 AM, Henrick Hellström wrote:
> On 2015-12-16 12:17, Eric Rescorla wrote:
>>
>> Can we see a brief writeup explaining the 2^36 number?
>>
>>
>> I believe Watson provided one a while back at:
>> https://www.ietf.org/mail-archive/web/tls/current/msg18240.html
>
>
> On
On Wed, Dec 16, 2015 at 6:17 AM, Eric Rescorla wrote:
>
>
> On Wed, Dec 16, 2015 at 12:44 AM, Simon Josefsson
> wrote:
>>
>> Eric Rescorla writes:
>>
>> > Watson kindly prepared some text that described the limits on what's
>> > safe
>> > for AES-GCM and restricting all algorithms with TLS 1.3 t
On 2015-12-16 12:17, Eric Rescorla wrote:
Can we see a brief writeup explaining the 2^36 number?
I believe Watson provided one a while back at:
https://www.ietf.org/mail-archive/web/tls/current/msg18240.html
One rather obvious problem with trying to equate probability of loss of
confiden
On Wed, Dec 16, 2015 at 12:44 AM, Simon Josefsson
wrote:
> Eric Rescorla writes:
>
> > Watson kindly prepared some text that described the limits on what's safe
> > for AES-GCM and restricting all algorithms with TLS 1.3 to that lower
> > limit (2^{36} bytes), even though ChaCha doesn't have the
Eric Rescorla writes:
> Watson kindly prepared some text that described the limits on what's safe
> for AES-GCM and restricting all algorithms with TLS 1.3 to that lower
> limit (2^{36} bytes), even though ChaCha doesn't have the same
> restriction.
Can we see a brief writeup explaining the 2^36
RC4 does not rekey per application layer fragment in TLS. The same key is used
for the duration of a connection.
Other protocols using RC4 do rekey per packet, eg WEP and WPA/TKIP.
Cheers
Kenny
> On 16 Dec 2015, at 16:37, Ryan Carboni wrote:
>
> How often does TLS rekey anyway? I know RC4
How often does TLS rekey anyway? I know RC4 rekeys per packet, but I've
read and searched a fair amount of documentation, and haven't found
anything on the subject. Perhaps I'm looking for the wrong terms or through
the wrong documents.
___
TLS mailing li
t;]
> > Sent: Tuesday, December 15, 2015 5:38 PM
> > To: Scott Fluhrer (sfluhrer)
> > Cc: Eric Rescorla; tls@ietf.org <mailto:tls@ietf.org>
> > Subject: Re: [TLS] Data volume limits
> >
> > On Tue, Dec 15, 2015 at 5:01 PM, Scott Fluhrer (sfluhrer)
> >
On Tuesday, December 15, 2015 11:11:36 pm Martin Thomson wrote:
> On 16 December 2015 at 15:08, Dave Garrett wrote:
> > We could just make the threshold a configurable parameter, with
> > default/maximum at 2^32 bytes. Each endpoint could just provide its
> > threshold in a new extension. Both g
On 16 December 2015 at 15:08, Dave Garrett wrote:
> We could just make the threshold a configurable parameter, with
> default/maximum at 2^32 bytes. Each endpoint could just provide its threshold
> in a new extension. Both get to specify what they want and it could be
> lowered arbitrarily for
On Tuesday, December 15, 2015 10:59:35 pm Martin Thomson wrote:
> On 16 December 2015 at 14:57, Dave Garrett wrote:
> > In fact, if we're OK with setting this rather low threshold, then we could
> > even get rid of the rekey signal entirely and just have an automatic rekey
> > after every 4GiB f
On Tue, Dec 15, 2015 at 7:59 PM, Martin Thomson
wrote:
> On 16 December 2015 at 14:57, Dave Garrett wrote:
> > In fact, if we're OK with setting this rather low threshold, then we
> could even get rid of the rekey signal entirely and just have an automatic
> rekey after every 4GiB for all cipher
So we have to trade off the risks of too much data vs. the risks
of a complex rekey protocol vs. the risks having the big data
applications build new connections every 2**36 or so bytes.
If we don't have rekeying, then the big data applications are
the only ones at risk. If we do, it may be a
On 16 December 2015 at 14:57, Dave Garrett wrote:
> In fact, if we're OK with setting this rather low threshold, then we could
> even get rid of the rekey signal entirely and just have an automatic rekey
> after every 4GiB for all ciphers. That'd be one less complexity to deal with.
> Rekeys wo
On Tuesday, December 15, 2015 09:40:41 pm Martin Thomson wrote:
> In light of that, the actual limits don't matter that much to me. As
> David McGrew suggested, set a limit at 2^32 and avoid having to think
> too hard about how close to the failure point you might be.
+1
In fact, if we're OK wit
Hi Watson,
On 16/12/15 03:36, Watson Ladd wrote:
> The problem is that once you stack enough of those negligible
> probabilities together, you end up with something big. Push up to
> 2^{63} bytes, and the collision probability is 1/4 or 1/2 (I didn't
> recompute it just now).
The collision prob
On Tue, Dec 15, 2015 at 7:59 PM, Henrick Hellström wrote:
> On 2015-12-16 01:31, Watson Ladd wrote:
>>
>> You don't understand the issue. The issue is PRP not colliding, whereas
>> PRF can.
>
>
> Oh, but I concur. This means that if you observe two same valued cipher text
> blocks, you know that t
On Tue, Dec 15, 2015 at 4:59 PM, Henrick Hellström
wrote:
> On 2015-12-16 01:31, Watson Ladd wrote:
>
>> You don't understand the issue. The issue is PRP not colliding, whereas
>> PRF can.
>>
>
> Oh, but I concur. This means that if you observe two same valued cipher
> text blocks, you know that
On 16 December 2015 at 14:01, Brian Smith wrote:
> Martin Thomson wrote:
> Why?
If there were a stupidly high limit, then I would argue for no
rekeying facility.
But the numbers Watson ran suggested that GCM starts to look shaky at
2^36. That's too low for some applications.
For the rest of t
Martin Thomson wrote:
> Whatever the actual limits are, I think that implementatios should be
> encouraged to rekey more strongly.
>
Why?
> And suggesting a stupidly high limit (e.g., ChaCha being
> greater than 2^96) leaves people thinking that they can skip
> implementation and testing of th
On 16 December 2015 at 08:14, Eric Rescorla wrote:
>
> I wanted to get people's opinions on whether that's actually what we want
> or whether we should (as is my instinct) allow people to use ChaCha
> for longer periods.
Whatever the actual limits are, I think that implementatios should be
encou
On 2015-12-16 01:31, Watson Ladd wrote:
You don't understand the issue. The issue is PRP not colliding, whereas
PRF can.
Oh, but I concur. This means that if you observe two same valued cipher
text blocks, you know that the corresponding key stream blocks can't be
identical, and deduce that t
> -Original Message-
> From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Henrick Hellström
> Sent: Tuesday, December 15, 2015 7:09 PM
> To: tls@ietf.org
> Subject: Re: [TLS] Data volume limits
>
> On 2015-12-16 00:48, Eric Rescorla wrote:
> >
> >
&g
On 12/15/2015 04:08 PM, Henrick Hellström wrote:
> On 2015-12-16 00:48, Eric Rescorla wrote:
>>
>>
>> On Tue, Dec 15, 2015 at 3:08 PM, Scott Fluhrer (sfluhrer)
>> mailto:sfluh...@cisco.com>> wrote:
>> The quadratic behavior in the security proofs are there for just
>> about any block ciph
On Dec 15, 2015 7:09 PM, "Henrick Hellström" wrote:
>
> On 2015-12-16 00:48, Eric Rescorla wrote:
>>
>>
>>
>> On Tue, Dec 15, 2015 at 3:08 PM, Scott Fluhrer (sfluhrer)
>> mailto:sfluh...@cisco.com>> wrote:
>> The quadratic behavior in the security proofs are there for just
>> about any blo
On 2015-12-16 00:48, Eric Rescorla wrote:
On Tue, Dec 15, 2015 at 3:08 PM, Scott Fluhrer (sfluhrer)
mailto:sfluh...@cisco.com>> wrote:
The quadratic behavior in the security proofs are there for just
about any block cipher mode, and is the reason why you want to stay
well below the
Watson Ladd wrote:
> The issue is the bounds in Iwata-Ohashai-Minematsu's paper, which show
> a quadratic confidentiality loss after a total volume sent. This is an
> exploitable issue.
>
Please explain in more detail how you got "2^36 bytes" for a nonce size of
96 bits from the Iwata-Ohashai-Mi
> > Cc: Eric Rescorla; tls@ietf.org
> > Subject: Re: [TLS] Data volume limits
> >
> > On Tue, Dec 15, 2015 at 5:01 PM, Scott Fluhrer (sfluhrer)
> > wrote:
> > > Might I enquire about the cryptographical reason behind such a limit?
> > >
> > &g
On Dec 15, 2015 6:08 PM, "Scott Fluhrer (sfluhrer)"
wrote:
>
>
>
> > -Original Message-
> > From: Watson Ladd [mailto:watsonbl...@gmail.com]
> > Sent: Tuesday, December 15, 2015 5:38 PM
> > To: Scott Fluhrer (sfluhrer)
> > Cc: Eric Rescorla
> -Original Message-
> From: Watson Ladd [mailto:watsonbl...@gmail.com]
> Sent: Tuesday, December 15, 2015 5:38 PM
> To: Scott Fluhrer (sfluhrer)
> Cc: Eric Rescorla; tls@ietf.org
> Subject: Re: [TLS] Data volume limits
>
> On Tue, Dec 15, 2015 at 5:01 PM,
mailto:tls-boun...@ietf.org] On Behalf Of Eric Rescorla
> Sent: Tuesday, December 15, 2015 4:15 PM
> To: tls@ietf.org
> Subject: [TLS] Data volume limits
>
>
>
> Watson kindly prepared some text that described the limits on what's safe
>
> for AES-GCM and restricting all a
On Tue, 15 Dec 2015 13:14:30 -0800
Eric Rescorla wrote:
> Watson kindly prepared some text that described the limits on what's
> safe for AES-GCM and restricting all algorithms with TLS 1.3 to that
> lower limit (2^{36} bytes), even though ChaCha doesn't have the same
> restriction.
>
> I wanted
On Tue, Dec 15, 2015 at 5:18 PM, Russ Housley wrote:
>
> On Dec 15, 2015, at 4:14 PM, Eric Rescorla wrote:
>
>> Watson kindly prepared some text that described the limits on what's safe
>> for AES-GCM and restricting all algorithms with TLS 1.3 to that lower
>> limit (2^{36} bytes), even though Ch
On Dec 15, 2015, at 4:14 PM, Eric Rescorla wrote:
> Watson kindly prepared some text that described the limits on what's safe
> for AES-GCM and restricting all algorithms with TLS 1.3 to that lower
> limit (2^{36} bytes), even though ChaCha doesn't have the same
> restriction.
>
> I wanted to ge
On Behalf Of *Eric Rescorla
> *Sent:* Tuesday, December 15, 2015 4:15 PM
> *To:* tls@ietf.org
> *Subject:* [TLS] Data volume limits
>
>
>
> Watson kindly prepared some text that described the limits on what's safe
>
> for AES-GCM and restricting all algorithms with TLS
Eric Rescorla
Sent: Tuesday, December 15, 2015 4:15 PM
To: tls@ietf.org
Subject: [TLS] Data volume limits
Watson kindly prepared some text that described the limits on what's safe
for AES-GCM and restricting all algorithms with TLS 1.3 to that lower
limit (2^{36} bytes), even though ChaCha do
> On 15 Dec 2015, at 22:17, Watson Ladd wrote:
>
> I don't think that's what I intended: I think the limit should be
> ciphersuite specific. Unfortunately that requires more work.
>
> On Tue, Dec 15, 2015 at 4:15 PM, Eric Rescorla wrote:
>>
>>> I wanted to get people's opinions on whether tha
Personally, I think a hard requirement to rekey every 64GiB is reasonable
enough to just use it for every cipher. I don't think cipher-specific
requirements are worth the effort/complexity. Something like a MUST for AES-GCM
and a SHOULD for ChaCha seems fine, though, if really desired.
Dave
On Tue, Dec 15, 2015 at 1:17 PM, Watson Ladd wrote:
> I don't think that's what I intended: I think the limit should be
> ciphersuite specific. Unfortunately that requires more work.
>
That makes sense. Do you think you'll be able to provide that in the not
too distant future? I can just leave t
1 - 100 of 103 matches
Mail list logo
