Date: Tue, 19 Apr 2022 04:36:22 +0000 From: bugzilla-noreply@freebsd.org To: net@FreeBSD.org Subject: [Bug 263379] [regression] [ipsec] compatibility broken between stable/12 and stable/13 opencrypto in AEAD mode Message-ID: <bug-263379-7501-vMKAzCkBoX@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-263379-7501@https.bugs.freebsd.org/bugzilla/> References: <bug-263379-7501@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D263379 --- Comment #9 from Eugene Grosbein <eugen@freebsd.org> --- (In reply to John Baldwin from comment #8) > Static keys are not good for AES-GCM or AES-CTR as the sequence number ca= n rollover yes. Maybe it's worth mentioning in the setkey(8), too. > stable/13 should work fine with ETA combos such as AES-CBC with SHA1/256/= 512 HMACs. But it does not for me. > Note that the key for AES-CBC is shorter than for AES-CTR/GCM as it is "o= nly" the actual AES key (so 16, 24, or 32 bytes) and doesn't include the ex= tra 4 bytes for the implicit part of the IV. I am aware of this. > (And setkey just reports "EINVAL" for all manner of errors, so it's rathe= r hard to figure out why setkey fails in my experience, so my best guess is= you are reusing the GCM key but need to remove the last 4 bytes.) First, I did modify the key to shorter it. Second, setkey utility has its o= wn syntax checks that include checks for the length and it does not even try to sent ADD request to the kernel for wrong key length issuing a bit more read= able error with line number of /etc/ipsec.conf > The kyua tests test AES-CBC (both 128 and 256 bit keys) with SHA1-HMAC an= d SHA2-256-HMAC. Would you please point me to the corresponding kyua test? --=20 You are receiving this mail because: You are on the CC list for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-263379-7501-vMKAzCkBoX>