Open Snap-A opened 2 months ago
Hi @Snap-A , thanks for the feedback and help. We' have some time issues lately, but those are done, and I'll get to this by the middle of next week, if not sooner.
Hi @jbrock24 , it looks like this didn't make it into today's release to Demo. Is there any eta for when this may be fixed?
Hi @GlennUL Unfortunately it didn't, the fix is in dev, but will go out with the next release, apologies.
Hi @Snap-A @GlennUL - After reviewing this, this is something that isn't required based on the sections 3.3 and 3.6. Within the code here we specifically ignore this when outputting for this PrimeGenMode to the prompt file.
// Ignore HashAlg for B.3.3, B.3.6
if (testGroup.PrimeGenMode == PrimeGenModes.RandomProbablePrimes ||
testGroup.PrimeGenMode == PrimeGenModes.RandomProbablePrimesWithAuxiliaryProvablePrimes)
{
if (jsonProperty.UnderlyingName.Equals(nameof(TestGroup.HashAlgName),
StringComparison.OrdinalIgnoreCase))
{
return false;
}
}
Sorry for all the confusion regarding this. I'll leave it open for further conversation.
Feel free to close when ready/done, but ask questions if needed, np!
Also check A.1.5 Generation of Probable Primes with Conditions Based on Auxiliary Provable Primes section of 185-6.
Hi @Snap-A @GlennUL - After reviewing this, this is something that isn't required based on the sections 3.3 and 3.6. Within the code here we specifically ignore this when outputting for this PrimeGenMode to the prompt file.
// Ignore HashAlg for B.3.3, B.3.6 if (testGroup.PrimeGenMode == PrimeGenModes.RandomProbablePrimes || testGroup.PrimeGenMode == PrimeGenModes.RandomProbablePrimesWithAuxiliaryProvablePrimes) { if (jsonProperty.UnderlyingName.Equals(nameof(TestGroup.HashAlgName), StringComparison.OrdinalIgnoreCase)) { return false; } }
Sorry for all the confusion regarding this. I'll leave it open for further conversation.
I believe this is in contradiction with the required registration parameters. The attempt to register without the hashAlg
value (array of hash names) fails.
This seems to point to an "interpretation" problem for this mode in the text you referenced. The mode under discussion creates "probable" primes, but also employs a "provable" auxiliary function. This auxiliary function uses a hash in its algorithm that needs to be set to successfully generate keys. Therefore, just using the the fact that "probable" primes are generated does not preclude the test vector from providing hash identifiers.
Can you find out whether the needs of the auxiliary function were fully considered by the quoted reference?
Hi @jbrock24 Do you have any update on the vendors additional comments above?
Hi @Snap-A @GlennUL - Thanks for this guys, sorry for the confusion, but we got it worked through. I'll have this fix out in the *.35 hotfix.
Thanks Joel!
Yes, thank you Joel!
The "hashAlgo" data is now included and the RSA test processing in my ITU is working. Thank you!
Great, thank you for your patience! I'll close this out now.
Test Request
Test Server: Demo Test Session: /acvp/v1/testSessions/512622 Test Group Id: 1
Description
The FIPS186-5 RSA key generation AFT test "probableWithProvableAux" is requiring the array fields
hashAlg
andprimeTest
to request test vectors on demo, as expected. (This matches the previous registration for FIPS186-4, test "B.3.5"). The IUT will then parse the group object for the two chosen entries, selected from each array in order to run the correct algorithm.The parsing step fails, since the group object does not contain the field
hashAlg
, just the fieldprimeTest
. This seems to be a probable bug in the server code, incorrectly omitting this entry.JSON Samples
Registration
Returned Test Vectors (First Group)