Am Samstag, 11. Juli 2015, 10:39:18 schrieb Herbert Xu:
Hi Herbert,
>Weird. The C version does the very same check:
>
>static int crypto_rfc4106_decrypt(struct aead_request *req)
>{
> if (req->assoclen != 16 && req->assoclen != 20)
> return -EINVAL;
I rechecked my test code: I accidentally only used gcm(aes) instead of
rfc4106(gcm(aes)) for validating the C code. Using rfc4106(gcm(aes-asm)), I
get the same error. Sorry for the inconsistent description.
Based on the patch to the testmgr.h test vectors for RFC4106, I include the IV
inbetween the AD and the plaintext.
That code now works with rfc4106(gcm(aes)). But using that code now fails with
the "regular" GCM implementation as well as CCM. The regular GCM
implementation works when not providing the IV as part of the SGL/set_ad. Is
that difference between "regular" AEAD and RFC4106 AEAD intended?
Apart from the GCM vs RFC4106 invocation, the code seemingly requires to
provide the IV twice -- once with the buffer/set_ad and once with the
set_crypt call. Is that intended? Providing the IV twice is visible in the
testmgr.h patch where .assoc now includes the previous .assoc plus the IV data
which is also set in .iv.
Thanks
Stephan
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
