netdev - Re: [PATCH v2 1/2] mac80211: fils_aead: Use crypto api CMAC shash rather than bare cipher

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAKv+Gu9KdJCzkWtGYDaK_6_WgW4aZ4Wtm-O581STyDKj7RzyrA@mail.gmail.com>
Date:   Mon, 6 Feb 2017 09:08:39 +0000
From:   Ard Biesheuvel <ard.biesheuvel@...aro.org>
To:     Johannes Berg <johannes@...solutions.net>
Cc:     Jouni Malinen <jouni@....qualcomm.com>,
        "<linux-wireless@...r.kernel.org>" <linux-wireless@...r.kernel.org>,
        "<netdev@...r.kernel.org>" <netdev@...r.kernel.org>,
        "David S. Miller" <davem@...emloft.net>
Subject: Re: [PATCH v2 1/2] mac80211: fils_aead: Use crypto api CMAC shash
 rather than bare cipher

On 6 February 2017 at 08:47, Johannes Berg <johannes@...solutions.net> wrote:
>
>>  {
>>       u8 d[AES_BLOCK_SIZE], tmp[AES_BLOCK_SIZE];
>> +     struct shash_desc *desc;
>> +     u8 buf[sizeof(*desc) + crypto_shash_descsize(tfm)]
>> CRYPTO_MINALIGN_ATTR;

I realised we have a more idiomatic SHASH_DESC_ON_STACK for this.

>>       size_t i;
>> -     const u8 *data[2];
>> -     size_t data_len[2], data_elems;
>> +
>> +     desc = (struct shash_desc *)buf;
>> +     desc->tfm = tfm;
>>
>> +     crypto_shash_digest(desc, (u8[AES_BLOCK_SIZE]){},
>> AES_BLOCK_SIZE, d);
>
> That's an interesting expression in there. Can we name it into a real
> variable? :)
>

Sure, if you prefer.

> I'm also slightly worried about stack usage now - do we know none of
> this goes into an sg list eventually?
>

Shashes do not usually use scatterlists: the shash API does not use
them, but uses u8[] arrays and lengths everywhere, and shashes are
explicitly synchronous, which means they are unsuitable for being
exposed on top of a high latency peripheral that uses DMA.