[Swan-dev] annoying AES_XCBC FIPS, er, quirk

Andrew Cagney andrew.cagney at gmail.com
Wed Mar 28 13:32:09 UTC 2018

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 <paul at nohats.ca> 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

More information about the Swan-dev mailing list