The latter, I'd assume our custom implementation is not FIPS compliant. In FIPS mode it is disabled (it just doesn't look like it is).
On 28 March 2018 at 05:26, Paul Wouters <[email protected]> wrote: > On Tue, 27 Mar 2018, Andrew Cagney wrote: > >> Up until now pluto hasn't had to deal with an algorithm that has both >> FIPS and non-FIPS implementations, and instead, code has been assuming >> that an algorithm marked as FIPS is so for both IKE and ESP/AH. >> Unfortunately AES_XCBC breaks that assumption - the kernel's AES_XCBC >> is assumed to be FIPS compliant, but Pluto's internal implementation >> is decidedly not. >> >> The consequence is that, in FIPS mode, AES_XCBC_96 gets listed as a >> valid IKE integrity algorithm vis: >> >> AES_XCBC_96 IKEv1: ESP AH IKEv2: IKE ESP AH FIPS >> (aes_xcbc aes128_xcbc aes128_xcbc_96) >> >> Fortunately, because the underlying PRF (AES_XCBC) isn't valid (and >> isn't listed), the parser will reject attempts to use it. > > > Are you saying it is not fips compliant because of the truncation > oddness? If so, we could ask the FIPS people about that. > > Or were you referring to the fact that we use a hash function to > implement a prf because nss has no native support for it? > > Paul _______________________________________________ Swan-dev mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan-dev
