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. _______________________________________________ Swan-dev mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan-dev
