Page MenuHome GnuPG

New set of API for public key cryptography
Open, WishlistPublic

Description

Adding a set of API for public key cryptography is needed for signature operation with internal hashing.

A set of new API would be good, perhaps, if it can support easier use.

How about:
we can supply binary data to a routine and it returns binary data; That is, no need of composing/parsing S-expressions, but directly put/get binary data. When/if needed, users can parse S-expression to supply data to new API routine, and can compose data with S-expression after getting binary data from new API routine.

This approach may offer better separation of handling data in S-expression and pk cipher.

Conceptually, it will be like:

  • open
  • close
  • set: part # and data (multiple times, or use of variable number args?)
  • ctl: specifying mode of operation, hash algo, setting one-time thing, etc.
  • op: generate signature, encryption/decryption, generate key, etc.
  • get

Event Timeline

gniibe created this task.

I created an experimental branch:
https://dev.gnupg.org/source/libgcrypt/history/gniibe%252Fnew-pk-api/

  • gcry_pkey_open
  • gcry_pkey_op
    • GCRY_PKEY_OP_SIGN
    • GCRY_PKEY_OP_VERIFY
    • ... for ECDH
  • gcry_pkey_close

and

  • gcry_pkey_ctl

And tried using the API with Ed25519, Ed25519ph (which needs internal hashing), and Ed25519ctx (which needs context).

I added couple of minor comments. I hope they went into somewhere.

As mentioned on the meeting earlier today, it looks good from here, but I would like to see a bit more examples tied to the actual FIPS work:

  • probably RSA operations. It is not that complicated to the number of modes/prehashing, but is the most flexible to the accepted digests, which is the primary issue we try to solve now
  • the ctl for the digest operation. The Ed25519 has implicit SHA512 only
  • the way to disable non-approved operations/modes/digests in FIPS mode, as we will implement implicit FIPS indicators (RSA with SHA1, Ed25519 will not work now either ...). Probably not complicated, but good too count with

Today, I pushed an example for RSA-PSS.

In this branch: https://dev.gnupg.org/source/libgcrypt/history/gniibe%252Fnew-pk-api/

Not yet final. I'll add RSA with PKCS v1.5.
Feature not yet well considered: gcry_pkey_ctl, probably, it can be used to pass md_handle to signing operation. But semantics would be: the md_handle may be one time use in signing, and second call of gcry_pkey_op to sign again would be failed. <-- need more consideration.
Not yet implemented: RSA with X931, DSA, Elgamal, ECDH, and ECC other curves.

BTW, the reason of the name "pkey" is that because gcry_pk_ctl is already occupied.
It will be changed, if needed.

2021-09-13 Update:

  • Signature operation tested: RSA-PSS, RSA-PKCS#1-v1.5, RSA-X9.31, ECDSA by NIST Curves, DSA (against CAVS test vectors in FIPS 186-4)
    • Newly added features (also useful for standard API of sexp):
      • Support of X9.31 signature scheme with RSA
      • Support of supplying random "k" for DSA/ECDSA
      • Digest mode ASN for SHA512-224 and SHA512-256 (required for RSA PKCS#1-v1.5)

This new API is not for FIPS directly (any more), as we introduced pk_hash_sign/verify for FIPS.

gniibe lowered the priority of this task from High to Wishlist.Dec 8 2021, 2:51 AM

Just let me note that we used to have such an API : the former gcry_ac_ functions. However, it turned out that they were more complicated to use.

Anticipating that we will eventually have the need to provide state for the gcry_pk functions and to allow for providing larger parameters, I once came up wit the context system. That is now used by pk_hash_sign et al. and offers a lot of other options to extend the API.