[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:
ike=aes-aes_cmac,3des-md5
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
first
- 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?
Andrew
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