Hi,
> On 2 Mar 2018, at 08:32, Nikos Mavrogiannopoulos wrote:
>
>> On Thu, 2018-03-01 at 21:52 +, 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 there's a possible
>> timing attack on a n
On Thu, 2018-03-01 at 21:52 +, 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 there's a possible
> timing attack on a naïve implementation of de-padding. Maybe this is
> already known to people
On Fri, Mar 2, 2018 at 12:17 PM, Eric Rescorla wrote:
> This is fun, but I want to note that many (most) APIs are not zero-copy but
> rather involve
> SSL_Read() copying data from some internal buffer into a caller supplied
> buffer. So
> that operation also needs to be made constant time (e.g., b
On Thu, Mar 1, 2018 at 5:12 PM, Martin Thomson
wrote:
> On Fri, Mar 2, 2018 at 10:23 AM, Daniel Kahn Gillmor
> wrote:
> > You could of course check from the front of the plaintext, keeping every
> > non-zero value:
> >
> > char ptype = 0;
> > for (i = 0; i < plaintext_len; i++)
> > if pl
On Fri, Mar 2, 2018 at 10:23 AM, Daniel Kahn Gillmor
wrote:
> You could of course check from the front of the plaintext, keeping every
> non-zero value:
>
> char ptype = 0;
> for (i = 0; i < plaintext_len; i++)
> if plaintext[i]
> ptype = plaintext[i];
What about ?
size_t l[2];
siz
On Thu 2018-03-01 21:52:51 +, Paterson, Kenny wrote:
> I think there's a possible timing attack on a naïve implementation of
> de-padding.
Thanks for observing this, Kenny! I think this came up when we were
designing the padding originally, and iirc, the general consensus was:
(a) this sche
The data ultimately needs to be returned to the calling application,
presumably some HTTP parser, which in turn passes data up to more calling
code and so on. Conversely, the data must have been produced by some also
application-level process on the sender, some HTTP serializer, before it
was hande
There's another, more cache-friendly approach too, which is to record the
position of the highest non-zero byte as the decryption occurs (while that
cache-line of plaintext is still in-cache) in-order. I found that a bit
easier to implement in constant time too because it's easy to generate an
all-
: "tls@ietf.org"
Subject: Re: [TLS] Possible timing attack on TLS 1.3 padding mechanism
Hi Kenny,
Yes, this is something we are aware of. Here's the relevant text from the
document:
https://tlswg.github.io/tls13-spec/draft-ietf-tls-tls13.html#rfc.appendix.E.3
Hi Kenny,
Yes, this is something we are aware of. Here's the relevant text from the
document:
https://tlswg.github.io/tls13-spec/draft-ietf-tls-tls13.html#rfc.appendix.E.3
I don't think we're likely to change the protocol, but if you have some
proposed text
that you think would be informative abo
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
11 matches
Mail list logo
