Page MenuHome GnuPG

FIPS: RSA/DSA/ECDSA are missing hashing operation
Open, HighPublic

Description

RSA/DSA/ECDSA do not seem to implement the hashing as part of the signature operation. Please, consider the patch authored by Stephan Mueller trying to implement this.

Not sure how to implement the SEXP in function cipher/pubkey.c:calculate_hash() in an efficient manner.

Details

Version
master

Event Timeline

werner triaged this task as Normal priority.Mar 27 2020, 7:12 PM
werner added a project: FIPS.
werner added a subscriber: werner.

I recall that I talked with Stephan about it but things got lost.

Does the patch really work, or is it a sketch to describe the intended use?

For me, the API looks not yet perfect. Specifically, in calculate_hash, s_hash is used to build an S-expression, but it's gone after exit of the function.

Please give us an example program which uses the new API.

Our public key functions are stateless. For several reasons it would be good to have an option to keep some state (think pre-computations). Our gcry_ctx_t would be a perfect fit for this and it will allow us to join a pubkey function with for example a hash function.

I think that {D1476} is still a sketch (not real code which works). I would guess an intended use, but it's good to have concrete example program which uses the feature being added.

OK. I think that the patch at SUSE is updated one which works.
As I understand correctly, this is a kind of very old patch, which intended to work around old libgcrypt limitation of RSA PSS.

For libgcrypt 1.7 or later, RSA PSS implementation got improved to support use cases in FIPS 186-4, namely different saltlen.

In an email from @werner couple days back, I got a suggestion that we could use hashing tied to the context, rather than this one-shot call tied only to digests. I circled back this suggestion to Stephan and he confirmed that it should be fine from the FIPS point of view so I am posting the suggested API here too:

ctx = gcry_pk_new (someflags)
md = gcry_md_open (...)
gcry_ctx_set_md (md);
gcry_pk_sign_ext (ctx, result, data, skey)
[...]
gcry_ctx_release (ctx);

Some ideas:

  • the someflags thing will probably just be a reserved parameter
  • If DATA is not NULL but an MD is set the sign function should fail
  • Should ownership of MD be moved to the CTX?
werner raised the priority of this task from Normal to High.

I am considering API enhancement, for this task.

Along with an API enhancement, I think that discussion of use case(s) makes sense. So, here we go...

I reviewd patches here: https://build.opensuse.org/package/show/devel:libraries:c_c++/libgcrypt?expand=1

libgcrypt-PCT-DSA.patch
libgcrypt-PCT-ECC.patch
libgcrypt-PCT-RSA.patch
libgcrypt-FIPS-RSA-DSA-ECDSA-hashing-operation.patch

are the patches for this discussion. (I was wrong, it is not intended to support RSA-PSS.)

PCT: pairwise consistency test

I think that the interpretation of FIPS 140 (-2, for this case) was that PCT requires hashing in testing computation of signatures.

I am reading "Implementation Guidance for FIPS 140-3" and OpenSSL from git (for FIPS 140-2). Reading those as references, in my understanding, PCT would not actually require hashing in computation of signatures.

How do you thing about "2.4.B Tracking the Component Validation List" (page 17) of "Implementation Guidance for FIPS 140-3"?
https://csrc.nist.gov/CSRC/media/Projects/cryptographic-module-validation-program/documents/fips%20140-3/FIPS%20140-3%20IG.pdf

And... as long as I read the PCT patches, it is not needed to export those API to users.
It is only needed internally for PCT tests (at most).

Even with the interpretation of those signature+hash requirement, it can be done with no ABI changes (not exposing sign_md and verify_md routines).

So, my approach is... for now: considering an internal API enhancement, which can be possibly used for sign_md and verify_md.