Page MenuHome GnuPG

EdDSA support in FIPS mode
Closed, ResolvedPublic


FIPS 186-5 ( was released an now specifies support for EdDSA signatures using the Ed25519 and Ed448 signatures schemes in section 7 and the Ed25519ph and Ed448ph schemes in section 7.8.

Enabling them in FIPS Mode, should be just flipping the fips bit in ecc-curves.c, adjusting the tests, selftests and PCT tests, ...

But it looks like the new digest&sign API is not compatible with the EdDSA as it requires the direct value in the data argument, so this will likely need some love to be able to implement PCT tests and use the EdDSA from the "approved" API.

I have a draft MR with the part of simple changes to the tests and the curves definitions, but it is missing the PCT, Selftest and I did not go through the guidance to verify the implementation matches the NIST requirements


master, 1.10.x

Event Timeline

werner triaged this task as Normal priority.Jun 1 2023, 9:05 AM
werner added a subscriber: werner.

My understanding is that FIPS 186-x lists more algorithms than approved for FIPS 140-y; the approved algorithms for 140-y are in the latest revisions of SP800-140. I have not checked the latter document, though.

werner raised the priority of this task from Normal to High.Jun 1 2023, 9:26 AM

They re-used the same file name for the update from March and no history section. Anyway that looks promising and may solve the problem of having different algorithms allowed for restricted communication in the EU and the US.

I'm going to add selftest of EdDSA with test vectors from RFC 8032.

For Ed448, tests/t-ed448.inp is duplicate.

Before adding FIPS support flag and tests, we need to modify implementation:

  • Adding PCT check for EdDSA
  • Adding support of gcry_pk_hash_sign/verify API for EdDSA

For the latter, I created an experimental patch:

EdDSA has two modes (normal and hashed). Normal mode doesn't hash messages, so, we need to specify input data. To do so, I added CONTEXT_TYPE_INPUT_DATA. Another approach would be having "non-hash" algo for gcry_md_open.

Another approach would be having "non-hash" algo for gcry_md_open.

I think this option would be too easy to misuse in other contexts so I would prefer having the specific CONTEXT_TYPE_INPUT_DATA for EdDSA. The proposed patch looks reasonable to me and no obvious issues noticed on fast review.

I changed the lg-input-data.diff patch not to break the ABI, reusing the published symbol of gcry_pk_random_override_new.
With this approach, if/when needed, backporting may be easier.
Drawback is debugging internal of libgcrypt will be a bit confusing.

I found that for EdDSA other than pure Ed25519, it can supply context.
I changed the semantics and API for adding context and input data, as we need to support both simultaneously.

I think so. We did not submit a modules for recertification with these changes, but we do not plan this in close future so you can consider it completed.

werner moved this task from Backlog to For 1.10 on the libgcrypt board.