On Tue, Feb 03, 2026 at 09:52:58PM -0500, Andrew Cagney wrote: > when I query the 7.8 kernel for supported ESP algorithms I get back: > > | sadb_supported @72 len=56(7*8) > exttype=15(EXT_SUPPORTED_ENCRYPT) reserved=00000000 > | sadb_alg @80 id=11(SADB_EALG_NULL) ivlen=0 minbits=0 > maxbits=0 reserved=0000 > | sadb_alg @88 id=3(SADB_EALG_3DESCBC) ivlen=64 > minbits=192 maxbits=192 reserved=0000 > | sadb_alg @96 id=7(SADB_X_EALG_BLF) ivlen=64 > minbits=40 maxbits=448 reserved=0000 > | sadb_alg @104 id=6(SADB_X_EALG_CAST) ivlen=64 > minbits=40 maxbits=128 reserved=0000 > | sadb_alg @112 id=12(SADB_X_EALG_AES) ivlen=128 > minbits=128 maxbits=256 reserved=0000 > | sadb_alg @120 id=13(SADB_X_EALG_AESCTR) ivlen=128 > minbits=160 maxbits=288 reserved=0000 > > While both CHACHA and AES_GCM are missing, I've found, with a bit of > poking, that AES_GCM, at least, does appear to work > > Should I be relying on queries like the above, or, as we're doing on > Linux, just hardwire the algorithms I suspect are present? > (poking around I suspect the table static const struct sadb_alg > ealgs[] could do with an update) > > ref https://github.com/libreswan/libreswan/issues/2607 >
Yes we should probably fix this. I am not sure if anyone uses queries. I'm pretty certain iked doesn't but isakmpd might. Not sure how useful it is to have queries in an implementation that already diverged quite a lot from all the others, but that is another discussion I guess. CHACHA should also work. It might be easier to check existing users of the API. In iked that would be: https://github.com/openbsd/src/blob/master/sbin/iked/pfkey.c#L75-L95
