Re: [TLS] Possible timing attack on TLS 1.3 padding mechanism

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 >>

Re: [TLS] Possible timing attack on TLS 1.3 padding mechanism

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

Re: [TLS] Possible timing attack on TLS 1.3 padding mechanism

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

Re: [TLS] Possible timing attack on TLS 1.3 padding mechanism

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; > >

Re: [TLS] Possible timing attack on TLS 1.3 padding mechanism

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

Re: [TLS] Possible timing attack on TLS 1.3 padding mechanism

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

Re: [TLS] Possible timing attack on TLS 1.3 padding mechanism

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

Re: [TLS] Possible timing attack on TLS 1.3 padding mechanism

rson, Kenny" <kenny.pater...@rhul.ac.uk> Cc: "tls@ietf.org" <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://tls

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 I don't think we're likely to change the protocol, but if you have some proposed text that you think would be informative

Re: [TLS] Possible timing attack on TLS 1.3 padding mechanism

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