Date: Mon, 18 Apr 2022 21:05:14 +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-neAbnl5z6B@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 #8 from John Baldwin <jhb@FreeBSD.org> --- (In reply to Eugene Grosbein from comment #6) Static keys are not good for AES-GCM or AES-CTR as the sequence number can rollover yes. Even for AES-CBC I would be hesitant to rely on static keys rather than using an IKE daemon to permit dynamic keys. stable/13 should w= ork fine with ETA combos such as AES-CBC with SHA1/256/512 HMACs. Note that the key for AES-CBC is shorter than for AES-CTR/GCM as it is "only" the actual = AES key (so 16, 24, or 32 bytes) and doesn't include the extra 4 bytes for the implicit part of the IV. (And setkey just reports "EINVAL" for all manner = of errors, so it's rather 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.) The kyua tests test AES-CBC (both 128 and 256 bit keys) with SHA1-HMAC and SHA2-256-HMAC. In regards to stable/12, yes, I think it is also late and a warning might n= ot be seen by many users (and almost said as much). stable/12 is still suppor= ted until 2024 so a 12.4 doesn't seem completely unlikely however. --=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-neAbnl5z6B>