Adding ECC KEM

[NIIBE Yutaka]

Werner Koch <wk at gnupg.org> wrote:
> I recently introduced the GCRY_PK_KEM algo which I marked as pseudo
> algorithms.  Right now we use a 3 Kyber variants and sntrup761 under
> this label.

I observed that.  My understanding is that it's needed to support
keygrip for those keys.

> This would we similar to GCRY_PK_ECC and hthe use of named
> curves to identify which algorithm is actually used.  Shall we take this
> path and if so, what shall we do with ECDH?  ECDH is a pure ECC
> algorithm and does not really fit as a KEM algorithm because we would
> need to list all supported curves also there.  Or should we add some
> common curves also under the KEM label and thus provide a second
> interface for tehse curves?

# For the term, I use "composite" KEM (instead of "hybrid"), because of
# avoiding confusion of terms in "hybrid" in DHKEM.

AFAIK, in other areas (than GnuPG), I don't see any changes of practice
for existing ECC computation yet (for example, migration of API).  It
seems for me that (except DHKEM) it's only in the context of composite
KEM where ECC KEM is used.

So, I think that GCRY_KEM_RAW_X25519 for composite KEM is actually
useful for now.

GCRY_KEM_DHKEM25519 is worth to have in libgcrypt, possibly, if there
will be use cases.

These are experimental, mainly for GnuPG experiment of mine:

    GCRY_KEM_OPENPGP_X25519
    GCRY_KEM_CMS_X25519_X963_SHA256
    GCRY_KEM_CMS_X25519_HKDF_SHA256

Current approach of mine (for T7014) is that: let us keep using existing
ECC (as long as it works well) with existing key format.  Here, keygrip
for the ECC key is computed by the existing public key API
(gcy_pk_get_keygrip with name of the curve in SEXP), not introducing new
ones.

In other words, an ECC key can be used for both of:

    gcry_pk_encrypt and gcry_pk_decrypt API (with _gcry_pubkey_spec_ecc)
    gcry_kem_* API

while keygrip is computed by gcy_pk_get_keygrip.

Firstly, let us extend the KEM API by adding GCRY_KEM_RAW_<CURVENAME>.
This is for API for pure ECDH, and it is intended for composite KEM.
KDF should be implemented by application code.
--