Re: [PATCH] mac80211: aes_ccm: move struct aead_req off the stack

2 messages, 2 authors, 2016-10-14 · open the first message on its own page

Re: [PATCH] mac80211: aes_ccm: move struct aead_req off the stack

From: Johannes Berg <johannes@sipsolutions.net>
Date: 2016-10-14 13:46:49

Is the aad[] actually reused? I would assume it only affects the mac
on encryption, and the verification on decryption but I don't think
we actually need it back from the crypto routines.
I don't think it's reused.
Exactly what you said above :-) My patch only touches CCM but as you
said,

"""
'Also there's B_0/J_0 for CCM/GCM, and the 'zero' thing that GMAC
has.
"""
Ah, but we can/should do the same for the others, no?

johannes

Re: [PATCH] mac80211: aes_ccm: move struct aead_req off the stack

From: Ard Biesheuvel <hidden>
Date: 2016-10-14 14:23:10

On 14 Oct 2016, at 14:46, Johannes Berg [off-list ref] wrote:

quoted
Is the aad[] actually reused? I would assume it only affects the mac
on encryption, and the verification on decryption but I don't think
we actually need it back from the crypto routines.
I don't think it's reused.
quoted
Exactly what you said above :-) My patch only touches CCM but as you
said,

"""
'Also there's B_0/J_0 for CCM/GCM, and the 'zero' thing that GMAC
has.
"""
Ah, but we can/should do the same for the others, no?
Yes, but then we end up kmalloc/kfreeing chunks of 16 bytes, which is actually another problem.

I still think we are not violating the api by putting aead_req on the stack (but herbert should confirm). The aad[] issue does violate the api, so it deserves a separate fix imo
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help