SafePrimes KeyVer is not in line with SP 800-56Arev3 Sections 5.6.2.1.2 and 5.6.2.1.3

[rruss-ldos]

As mentioned in Issue #849, the ACVTS does not conduct Key Verification of SafePrimes according to SP 800-56Arev3.

Currently, the ACVTS checks the following which is in line with FIPS 186-4's key pair requirements: Private key (x), 0 < x < q Public key (y), y = g^x mod p

This differs from SP 800-56Arev3's key pair requirements for SafePrimes.

SP 800-56Arev3, Section 5.6.2.1.2 mandates the following private key requirements for when Safe-Primes are used: 1 <= x <= M-1 where M = min(2^N, q) and N is the agreed upon maximum bit length satisfying: 2s <= N <= len(q) where s is the maximum security strength supported by the given safe prime group.

Section 5.6.2.1.3 mandates Full Public-Key Validation be performed as specified in Section 5.6.2.3.1. Section 5.6.2.3.1 mandates the following public key requirements: 2 <= y <= p-2 and 1 = y^q mod p

It seems strange to require SafePrime key pairs be verified according to FIPS 186-4 rather than against SP 800-56Arev3, and to not even provide Key Verification testing according to SP 800-56Arev3.

[livebe01]

Hi @rruss-ldos, I appreciate you mentioning this. I'm not sure why this is. From an initial conversation with Chris, I think he was saying that the testing wasn't implemented to target 56Ar3 and that 56Ar3 wasn't consulted at the time. But let me dig more into this and get you a better answer.

[rruss-ldos]

Thanks @livebe01, in the meantime it seems it would be appropriate to correct full KAS-FFC prerequisite requirement to remove the current SafePrimes prerequisite requirement.

SafePrimes	SafePrimes KeyGen/KeyVer validation REQUIRED when IUT makes use of the "FB" or "FB" (legacy) domain parameters for the generation/validation of keys within the module boundary.

SafePrimes do not correspond to the FB domain parameters, and (as noted above) ACVTS does not implement testing for key validation of SafePrime keys according to SP 800-56Arev3.

[livebe01]

I agree @rruss-ldos. We'll remove that from the spec. Appreciate you pointing that out.

[jbrock24]

@livebe01 Should we leave this open?

[jbrock24]

Leaving open for future consideration.