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
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Layer Security Working Group of the
IETF.
Title : ChaCha20-Poly1305 Cipher Suites for Transport Layer
Security (TLS)
Authors : Adam Langl
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 Wednesday, December 16, 2015 04:15:00 pm John Foley wrote:
> Thanks for answering my questions. Have you considered adding KAT
> values for the key derivation steps? This would be helpful to
> implementors. RFC5869 already has KAT values for HKDF-Extract and
> HKDF-Expand. But the TLS 1.3
On 12/16/2015 03:30 PM, Dave Garrett wrote:
On Wednesday, December 16, 2015 11:12:42 am John Foley wrote:
I apologize if this topic was previously discussed, I've only recently
joined the TLS mailer list. While reviewing the TLS 1.3 draft (revision
10), section 7 begins with the following word
On Wednesday, December 16, 2015 11:12:42 am John Foley wrote:
> I apologize if this topic was previously discussed, I've only recently
> joined the TLS mailer list. While reviewing the TLS 1.3 draft (revision
> 10), section 7 begins with the following wording:
>
> In order to begin connecti
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.
>>>
>
On Wed, Dec 16, 2015 at 12:09 PM, Blumenthal, Uri - 0553 - MITLL
wrote:
> On 12/16/15, 10:50, "Watson Ladd" wrote:
>
>>On Wed, Dec 16, 2015 at 10:44 AM, Blumenthal, Uri - 0553 - MITLL
>> wrote:
>>> OK, let me try an extremely naïve approach.
>>>
>>> Say, an adversary observes a ton of TLS traffic
On 12/16/15, 10:50, "Watson Ladd" wrote:
>On Wed, Dec 16, 2015 at 10:44 AM, Blumenthal, Uri - 0553 - MITLL
> wrote:
>> OK, let me try an extremely naïve approach.
>>
>> Say, an adversary observes a ton of TLS traffic between A and B. Using
>> approach that Watson and others outlined, he can now t
I apologize if this topic was previously discussed, I've only recently
joined the TLS mailer list. While reviewing the TLS 1.3 draft (revision
10), section 7 begins with the following wording:
In order to begin connection protection, the TLS Record Protocol
requires specification of a su
On Wed, Dec 16, 2015 at 10:44 AM, Blumenthal, Uri - 0553 - MITLL
wrote:
> OK, let me try an extremely naïve approach.
>
> Say, an adversary observes a ton of TLS traffic between A and B. Using
> approach that Watson and others outlined, he can now tell that this is not a
> truly random stream but
OK, let me try an extremely naïve approach.
Say, an adversary observes a ton of TLS traffic between A and B. Using approach
that Watson and others outlined, he can now tell that this is not a truly
random stream but a bunch of encrypted data. My question is, from practical
real-world point of v
Hi Eric,
I explained the issue before and some other people recently explained it again
on this thread. AES has 128-bit block. Therefore, when there are 2^64 or more
ciphertext blocks, there are likely collisions among the ciphertext blocks (the
collision probability increases rapidly when th
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
21 matches
Mail list logo
