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
Hi
My 2c below...
On 20/02/2016 18:53, "TLS on behalf of Cedric Fournet"
wrote:
>
>
>Besides, in our analysis of the handshake, we get precisely the same
>“fresh, never-used secret” property you are advocating, with or
> without the simplification, each time the handshake provides keys to the
>
On 20/02/2016 20:30, "Eric Rescorla" wrote:
>Kenny,
>
>
>Would you have a problem with doing as Karthik suggests and generating
>separate traffic and handshake keys but at the same time?
>
>
>-Ekr
>
>
>
>
>On Sat, Feb 20, 2016 at 11:58 AM, Paters
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Hi,
I've been analysing the record protocol spec for TLS 1.3 a bit, specifically
the new padding mechanism. I think there's a possible timing attack on a naïve
implementation of de-padding. Maybe this is already known to people who've been
paying more attention than me!
Recall that the padding
Hi Ekr.
Ah that's great, thanks - and I think the text in the Appendix already
addresses the issues very well.
Sorry for the bandwidth consumption.
Cheers,
Kenny
-Original Message-
From: Eric Rescorla
Date: Thursday, 1 March 2018 at 22:27
To: "Paterson, Kenny"
Cc
Hi,
> On 2 Mar 2018, at 08:32, Nikos Mavrogiannopoulos wrote:
>
>> On Thu, 2018-03-01 at 21:52 +0000, Paterson, Kenny wrote:
>> Hi,
>>
>> I've been analysing the record protocol spec for TLS 1.3 a bit,
>> specifically the new padding mechanism. I think
Hi Colm,
On 16/03/2016 14:52, "TLS on behalf of Colm MacCárthaigh"
wrote:
>
>This has been bugging me for a long time and I've talked to some here
>about it in person, but this report;
>
>https://www.teamupturn.com/static/reports/2016/what-isps-can-see/files/Upt
>urn%20-%20What%20ISPs%20Can%20See
Hi
On 16/03/2016 18:44, "Watson Ladd" wrote:
>On Wed, Mar 16, 2016 at 11:22 AM, Paterson, Kenny
> wrote:
>> Hi
>>
>> On 16/03/2016 15:02, "TLS on behalf of Watson Ladd"
>>> on behalf of watsonbl...@gmail.com> wrote:
>>
>>
&g
Hi
On 16/03/2016 15:02, "TLS on behalf of Watson Ladd" wrote:
>On Wed, Mar 16, 2016 at 5:36 AM, Peter Gutmann
> wrote:
>> After a number of, uh, gentle reminders from people who have been
>>waiting for
>> this, I've finally got around to posting the TLS-LTS draft I mentioned
>>a while
>> back.
Hi
I think Rich Salz already said exactly what CFRG would say:
> If someone wants to see SPECK adopted by IETF protocols, the first thing
>that will have to happen is papers analyzing it.
There's some analysis already, but not that much.
Regards,
Kenny
On 21/03/2016 14:27, "TLS on behalf
Hi Aaron,
If AES-GCM ever generates two ciphertexts using the same key and the same
96-bit nonce, then the underlying CTR-mode keystreams will be the same.
XORing the ciphertexts together then produces the XOR of the plaintexts,
from which the two individual plaintexts can be recovered (usually) w
Hi
On 16/05/2016 10:37, "Aaron Zauner" wrote:
>Hi Kenny,
>
>> On 16 May 2016, at 16:18, Paterson, Kenny
>>wrote:
>>
>> Hi Aaron,
>>
>> If AES-GCM ever generates two ciphertexts using the same key and the
>>same
>> 96-bit
Hi
On 16/05/2016 11:15, "Aaron Zauner" wrote:
>Hi Kenny,
>
>> On 16 May 2016, at 16:48, Paterson, Kenny
>>wrote:
>>
>> Maybe the confusion is this: in your authenticity attack, you do recover
>> the GHASH key, and the effect is catastrophic. In
Hi Ilari,
On 15/06/2016 17:23, "TLS on behalf of Ilari Liusvaara"
wrote:
>On Wed, Jun 15, 2016 at 09:44:18AM -0400, Daniel Kahn Gillmor wrote:
>> On Wed 2016-06-15 04:44:59 -0400, Yoav Nir wrote:
>>
>> To be clear, we're being asked to trade these things off against each
>> other here, but ther
Hi Ilari,
On 14/06/2016 20:01, "TLS on behalf of Ilari Liusvaara"
wrote:
>I too haven't seen an argument (or am I able to construct one
>myself) on why using the same key causes more issues than
>"more difficult for cryptographers" (without assumptions known
>to be false or cause severe problems
Hi Quynh,
This indistinguishability-based security notion is the confidentiality
notion that is by now generally accepted in the crypto community. Meeting
it is sufficient to guarantee security against many other forms of attack
on confidentiality, which is one of the main reasons we use it.
You
Of Dang, Quynh (Fed)
>> Sent: Tuesday, July 12, 2016 11:12 AM
>> To: Paterson, Kenny; Dang, Quynh (Fed); Eric Rescorla; tls@ietf.org
>> Subject: Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt
>>
>> Hi Kenny,
>>
>> The indistinguishability-based secu
to 2^38
provides a better description to users.
Are you worried they won't know what a decimal in the exponent means?
Or, more seriously, are you saying that 2^{-32} for single key attacks is
a big enough security margin? If so, can you say what that's based on?
Cheers,
Kenny
>
>
Hi
On 12/07/2016 18:04, "Dang, Quynh (Fed)" wrote:
>Hi Kenny,
>
>On 7/12/16, 12:33 PM, "Paterson, Kenny" wrote:
>
>>Finally, you write "to come to the 2^38 record limit, they assume that
>>each record is the maximum 2^14 bytes". For c
Hi
On 12/07/2016 18:12, "Dang, Quynh (Fed)" wrote:
>Hi Kenny,
>
>On 7/12/16, 1:05 PM, "Paterson, Kenny" wrote:
>
>>Hi
>>
>>On 12/07/2016 16:12, "Dang, Quynh (Fed)" wrote:
>>
>>>Hi Kenny,
>>>
>>>I s
Yup, that's crypto, folks.
These are the kinds of numbers we should be worrying about for a protocol that
will be deployed for decades to billions of people and devices.
> On 12 Jul 2016, at 19:06, Scott Fluhrer (sfluhrer) wrote:
>
>
>> -Original Message-----
>
Hi,
> On 12 Jul 2016, at 18:56, Dang, Quynh (Fed) wrote:
>
> Hi Kenny,
>
>> On 7/12/16, 1:39 PM, "Paterson, Kenny" wrote:
>>
>> Hi
>>
>>> On 12/07/2016 18:12, "Dang, Quynh (Fed)" wrote:
>>>
>>>
Hi
> On 12 Jul 2016, at 18:57, Dang, Quynh (Fed) wrote:
>
> Hi Kenny,
>
>> On 7/12/16, 12:33 PM, "Paterson, Kenny" wrote:
>>
>> Unfortunately, that's not quite the right interpretation. The bounds one
>> obtains depend on both the
Hi
On 13/07/2016 11:55, "Dang, Quynh (Fed)" wrote:
>Good morning Kenny,
>
>On 7/12/16, 3:03 PM, "Paterson, Kenny" wrote:
>
>>Hi,
>>Could you define "safe", please? Safe for what? For whom?
>>
>>Again, why are you choosing 2^
Sadly, you can't implement XGCM using an existing AES-GCM API, because of the
way the MAC (which is keyed) is computed over the ciphertext in the standard
GCM scheme.
This does not contradict what you wrote, but may be a barrier to adoption.
Cheers
Kenny
On 15 Aug 2016, at 16:40, Watson Ladd
Hi Andrew,
My view concerning your request: no.
Rationale: We're trying to build a more secure internet.
Meta-level comment:
You're a bit late to the party. We're metaphorically speaking at the stage of
emptying the ash trays and hunting for the not quite empty beer cans.
More exactly, we a
Hi,
My preference is to go with the existing text, option a).
>From the github discussion, I think option c) involves a less conservative
security bound (success probability for IND-CPA attacker bounded by
2^{-32} instead of 2^{-60}). I can live with that, but the WG should be
aware of the weaker
Dear Quynh,
On 10/02/2017 12:48, "Dang, Quynh (Fed)" wrote:
>Hi Kenny,
>
>>Hi,
>>
>>
>>My preference is to go with the existing text, option a).
>>
>>
>>From the github discussion, I think option c) involves a less
>>conservative
>>security bound (success probability for IND-CPA attacker bounde
Hi,
On 10/02/2017 18:56, "Dang, Quynh (Fed)" wrote:
>Dear Kenny,
>
>From: "Paterson, Kenny"
>Date: Friday, February 10, 2017 at 12:22 PM
>To: 'Quynh' , Sean Turner
>Cc: IRTF CFRG , ""
>Subject: Re: [TLS] [Cfrg] Closing out tls
Hi Quynh,
I'm meant to be on vacation, but I'm finding this on-going discussion
fascinating, so I'm chipping in again.
On 15 Feb 2017, at 21:12, Dang, Quynh (Fed)
mailto:quynh.d...@nist.gov>> wrote:
Hi Atul,
I hope you had a happy Valentine!
From: Atul Luykx
mailto:atul.lu...@esat.kuleuven.
Hi,
On 01/03/2017 14:31, "TLS on behalf of Dang, Quynh (Fed)"
wrote:
>From: Aaron Zauner
>Date: Wednesday, March 1, 2017 at 9:24 AM
>To: 'Quynh'
>Cc: Sean Turner , "" , IRTF
>CFRG
>Subject: Re: [Cfrg] Closing out tls1.3 "Limits on key usage" PRs
>(#765/#769).
>
>
>
>>
>>
>>>On 01 Mar 2017, at
32 matches
Mail list logo
