[Bug 263379] [regression] [ipsec] compatibility broken between stable/12 and stable/13 opencrypto in AEAD mode
Date: Mon, 18 Apr 2022 16:51:58 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=263379 --- Comment #1 from John Baldwin <jhb@FreeBSD.org> --- To be clear, what do you think using AES-GCM with a separate SHA-512 HMAC should do? From the RFCs I have read, there is no defined standard for using a separate MAC with an AEAD cipher. For example, in the combinations listed in section 4 of RFC 8221, there is no defined method for combining a distinct MAC with an AEAD cipher. About the best I could imagine is that perhaps you intend to use AES-GCM with an ESP header and then a separate SHA-512 HMAC with an AH header? I can find no mention anywhere of such a construct for IPsec, and the closest thing I can find (using a non-AEAD cipher with ESP and a separate MAC with AH) is deprecated in RFC 8221 (the recommended approach is to use the non-AEAD cipher and MAC together as a combined ETA cipher with ESP, e.g. AES-CBC+SHA-512-HMAC). I suspect the fact that stable/12 does not fail this is probably a weird bug due to lack of argument validation in stable/12, and it is probably putting packets on the wire that no other OS can handle (perhaps it is basically using the AES-CTR side of AES-GCM but with the IV for AES-CTR constructed using AES-GCM rules and then generating the SHA-512 HMAC using ETA rules). That is, I suspect what you kind of have is a broken, non-standard version of AES-CTR + SHA-512 HMAC (which is a defined combined algorithm you can use). But really you are better of just using stock AES-GCM anyway and using GMAC rather than SHA512-HMAC. Your changes to OCF are all incorrect. If you want to combine AES-GCM with a separate HMAC, you would need to construct separate crypto sessions and crypto requests for a given buffer, the first to do AES-GCM and the second to deal with the HMAC. -- You are receiving this mail because: You are on the CC list for the bug.