netdev - Re: [PATCH] mac80211: port CCMP to cryptoapi's CCM driver

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] [day] [month] [year] [list]

Date:	Tue, 8 Oct 2013 22:00:41 +0200
From:	Ard Biesheuvel <ard.biesheuvel@...aro.org>
To:	Johannes Berg <johannes@...solutions.net>
Cc:	linux-wireless@...r.kernel.org, netdev@...r.kernel.org,
	Patch Tracking <patches@...aro.org>, linville@...driver.com
Subject: Re: [PATCH] mac80211: port CCMP to cryptoapi's CCM driver

On 8 October 2013 21:08, Johannes Berg <johannes@...solutions.net> wrote:
> I'm not too familiar with the aead API, so here's another question:
>
>> +     sg_init_one(&pt, data, data_len);
>> +     sg_init_one(&assoc, &aad[2], be16_to_cpup((__be16 *)aad));
>> +     sg_init_table(ct, 2);
>> +     sg_set_buf(&ct[0], cdata, data_len);
>> +     sg_set_buf(&ct[1], mic, IEEE80211_CCMP_MIC_LEN);
>
> Is it guaranteed to be allowed that the input and output are the same
> buffer? It seems we rely on that for encrypt_one(), but is it true here
> as well?
>

Yes, the crypto layer handles all of that without issue.

> (Btw - why pass in data/cdata as separate pointers into the function?)
>

That is just a leftover of the old implementation. I will remove that
in v2, that will cut down the number of function args as well.

>> @@ -343,7 +337,7 @@ static void ccmp_special_blocks(struct sk_buff *skb, u8 *pn, u8 *scratch,
>>               data_len -= IEEE80211_CCMP_MIC_LEN;
>>
>>       /* First block, b_0 */
>> -     b_0[0] = 0x59; /* flags: Adata: 1, M: 011, L: 001 */
>> +     b_0[0] = 0x1; /* set L := 1, M and Adata flags are implied */
>
> Hmm. I don't think I understand, can you explain this to me?
>

Well M is implied by the setauthsize() in init() [M := (MIC_LEN-2)/2
== 3], and the set_assoc() call in en/decrypt() indicates the presence
of assoc (A) data. Instead of setting the flags here, and clearing
them by anding with ~0x7 (as in the old implementation), this lets the
CCM layer handle that.

-- 
Ard.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html