Can someone verify ECDSA conformance with FIPS 86-4, Change 02-28-2012, Item 5?

13 views
Skip to first unread message

Jeffrey Walton

unread,
Oct 30, 2015, 5:56:02 PM10/30/15
to Crypto++ Users
Hi Everyone,

I don't have time at the moment to check this...

FIPS 186-4 updates DSS. Confer, http://csrc.nist.gov/groups/ST/toolkit/documents/FIPS186-3_ChangeNotice041012.pdf.

 I want to know about "5. Processing Step Error in the Secret Number Generation for ECDSA" because Crypto++ can operate on curves with a non-0 cofactor:

    In Appendices B.5.1 and B.5.2, processing step 1 (i.e., N = len(q)) is
    incorrect. This change notice specifies the following change to
    step 1: “N = len(n),” ; i.e., “q” is changed to “n”.
 
   This change may be significant if the cofactor is greater than one; for
    the NIST-recommended curves, the cofactor is one, so in this case,
    both values produce the same value for N.

A cofactor of 2 and 4 are common. Crypto++ operates on ANSI X9.62 and WTLS curves, and some of them have a cofactor that is quite large.

We are tracking this at "Verify conformance with FIPS 186-4, Item 5 change", https://github.com/weidai11/cryptopp/issues/51.

Can someone step the code and ensure the FIPS 186-4 constraint is being satisfied?

Jeff

Jean-Pierre Münch

unread,
Oct 31, 2015, 9:45:28 AM10/31/15
to cryptop...@googlegroups.com
Am 30.10.2015 um 22:56 schrieb Jeffrey Walton:
Hi Everyone,

I don't have time at the moment to check this...

FIPS 186-4 updates DSS. Confer, http://csrc.nist.gov/groups/ST/toolkit/documents/FIPS186-3_ChangeNotice041012.pdf.

 I want to know about "5. Processing Step Error in the Secret Number Generation for ECDSA" because Crypto++ can operate on curves with a non-0 cofactor:
The cofactor can't be 0, it must be at least 1. But I guess this was a typo anyways :P

I don't think we implemented this particular procedure, although their B.5.1 is similar to what we do, although we hide this stuff behind Integer(RNG,Min,Max).
The change meant to protect implementations from using too large "k" values by requesting too many bits from the PRNG.

The details:

FYI: ECDSA (eccrypto.h) is derived from DL_SS<...,DL_Algorithm_ECDSA<EC>,...>
DL_Algorithm_ECDSA (eccrypto.h) implements the formatting of ECDSA and is itself derived from DL_Algorithm_GDSA (gfpcrypto.h) which implements the logic.
DL_Algorithm_GDSA::Sign() implements the signature logic, but gets the "k" in question supplied externally.
The calling classes is only DL_SignerBase (pubkey.h) within RawSign() and SignAndRestart(). RawSign() is only ever used as a test in validat2.cpp. SignAndRestart() is our common method to sign stuff and is actually the class generating the k. It generates it as "Integer k(rng,1,param.GetSubgroupOrder()-1)" where param.GetSubgroupOrder() returns the "n" that is in the corrected version.


    In Appendices B.5.1 and B.5.2, processing step 1 (i.e., N = len(q)) is
    incorrect. This change notice specifies the following change to
    step 1: “N = len(n),” ; i.e., “q” is changed to “n”.
"q" is not defined in the scope of ECDSA so it was a notational error on their side. "q" is only defined for DSA (the subgroup prime) and for RSA (one of the modulus' prime factors).

 
   This change may be significant if the cofactor is greater than one; for
    the NIST-recommended curves, the cofactor is one, so in this case,
    both values produce the same value for N.

A cofactor of 2 and 4 are common. Crypto++ operates on ANSI X9.62 and WTLS curves, and some of them have a cofactor that is quite large.

We are tracking this at "Verify conformance with FIPS 186-4, Item 5 change", https://github.com/weidai11/cryptopp/issues/51.

Can someone step the code and ensure the FIPS 186-4 constraint is being satisfied?
TL;DR: We're not affected / have already mitigated.

BR

JPM

Jeff
--
--
You received this message because you are subscribed to the "Crypto++ Users" Google Group.
To unsubscribe, send an email to cryptopp-user...@googlegroups.com.
More information about Crypto++ and this group is available at http://www.cryptopp.com.
---
You received this message because you are subscribed to the Google Groups "Crypto++ Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cryptopp-user...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply all
Reply to author
Forward
0 new messages