lkml.org 
[lkml]   [2014]   [Aug]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [PATCH 1/2] crypto: add support for TLS 1.0 record encryption
On Fri, Aug 1, 2014 at 2:06 AM, Cristian Stoica
<cristian.stoica@freescale.com> wrote:
> Hi Andy
>
> On 31.07.2014 23:01, Andy Lutomirski wrote:
>> On 07/29/2014 02:32 AM, Cristian Stoica wrote:
> ...

>>> +static int crypto_tls_decrypt(struct aead_request *req)
>>> +{

>>> + /*
>>> + * Step 2 - Verify padding
>>> + * Retrieve the last byte of the payload; this is the padding size
>>> + */
>>> + cryptlen -= 1;
>>> + scatterwalk_map_and_copy(&pad_size, req->dst, cryptlen, 1, 0);
>>> +
>>> + /* RFC recommendation to defend against timing attacks is to continue
>>> + * with hash calculation even if the padding is incorrect */
>>> + if (cryptlen < pad_size + hash_size) {
>>> + pad_size = 0;
>>> + paderr = -EBADMSG;

If this happens, then pad_size == 0.

>>> + }

else pad_size is likely to be nonzero.

>>> + cryptlen -= pad_size;

So now cryptlen depends on the result of the decryption, which means
that this part is not constant time:

>>> +
>>> + /* Now compute and compare our ICV with the one from the packet */
>>> + err = crypto_tls_genicv(hash, req->dst, cryptlen, req);
>>> + if (!err)
>>> + err = crypto_memneq(hash, ihash, hash_size) ? -EBADMSG : 0;
>>
>> This looks like it's vulnerable to the Lucky 13 attack.
>
> Digest is always calculated and in this particular case memneq should
> help with some of the timing leaks. ICV calculation is expected to pass
> and any failures should be only for internal reasons. There are maybe
> some other problems that I've never thought of. Did you have something
> else in mind when you mentioned this attack?
>
> Cristian S.

If I understand it correctly, the issue is that cryptlen depends on
the padding. I added some notes inline above. See here, too:

https://www.imperialviolet.org/2013/02/04/luckythirteen.html

--Andy


\
 
 \ /
  Last update: 2014-08-01 18:01    [W:0.454 / U:0.192 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site