[Swan-dev] Algorithm parser filtering unsupported algorithms

Andrew Cagney andrew.cagney at gmail.com
Mon Aug 21 20:06:33 UTC 2017

The algorithm parser been changed to reject, up-front, algorithms that
aren't supported.  For instance, a configuration containing:


is rejected outright because AES_CMAC isn't implemented in NSS.
ESP/AH is similar (as determined by kernel_alg.c).  This is different
to the old code which tried to discard combinations it didn't like;
while still using the ones it did.   It isn't clear how well it
worked, I suspect the above could lead to:

- just 3des-md5 being proposed
- both aes-aes_cmac and 3des-md5 being proposed and then the
connection (or even pluto?) failing because the other end selected the
- an empty proposal (if fips was enabled say)

I think the new behaviour is correct.  It prevents garbage getting
into the proposal et.al. code.

This, however does lead to some quirky log output when the "wanted" vs
"found/loaded" algorithms are listed vis:

- for ike the only difference is that 'found' includes the default key size

IKE algorithms wanted: AES_CBC-HMAC_SHA1-MODP2048
IKE algorithms found:  AES_CBC_128-HMAC_SHA1-MODP2048

- for esp/ah the only difference is the addition of PFS in the first
line (if at all):

ESP algorithms wanted: AES(12)_128-SHA2_512(7); pfsgroup=MODP2048(14)
ESP algorithms loaded: AES(12)_128-SHA2_512(7)

I suspect, on both cases, the two lines can be merged into one?


PS: The alternative, would be to do this in two steps:

- just parse - wanted
- just filter - found/loaded

and display the result from both, but only feed the filtered list into
the proposal code.

More information about the Swan-dev mailing list