On Mon, Jul 13, 2015 at 11:09:34AM +0200, Stephan Mueller wrote: > > 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? Yes of course. As RFC4106 specifies that the IV should not be part of the AD. > 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. Yes it is intended. I played with not requiring req->iv at all and just getting it from the AD but the code turned out to be more complicated because you have to jump through hoops to access the IV which you need to to construct the full 16-byte IV. Since the primary user IPsec easily provides us with both I think that is the better setup. Cheers, -- Email: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- 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
