Adding new public key KEM API

[NIIBE Yutaka]

Hello,

Simon Josefsson <simon at josefsson.org> wrote:
> Is there any known algorithm that will make use of CONTEXT?  If not, I
> suggest to drop the variable and when/if the need arise, add a separate
> API for that use-case later on.

When we consider ECDH KEM, Kyber, and NTRU Prime for Hybrid PQC, we
don't need CONTEXT.

My concern is for two cases.

(1) Specifying the size of SHARED_SECRET

Well, for this case, the size may be specified by encoding into ALGO,
like GCRY_KEM_X25519_128 and GCRY_KEM_X25519_256.


(2) KDF with domain seperation

KDF under the KEM may want domain seperation.  (For the case of Hybrid
PQC, this can be done in key combiner.)

If I today considered OpenPGP support with ECDH KEM (alternative of
RFC6637), I would need something like CONTEXT in the API to specify
domain seperation with KDF.

If I supported a composite KEM of Hybrid PQC by the API, I would need
CONTEXT, too.

Well, this could be also solved by encoding information into ALGO, like
GCRY_KEM_X25519_OPENPGP and GCRY_KEM_KEYBER768_PLUS_X25519_OPENPGP.

So... I could not insist that having CONTEXT is much useful.

> I believe it is better to have a separate API for that use-case,
> when/if that arise, instead of polluting the API for normal use-cases
> with extra parameters.

Good point.


In my not so humble opinion, it is not programmer's task to define this
kind of API, but it is better for standardization process or academic to
provide useful consensus for such an interface.

Today, I found this paper:

@misc{cryptoeprint:2023/272,
      author = {Bertram Poettering and Simon Rastikian},
      title = {A study of KEM generalizations},
      howpublished = {Cryptology ePrint Archive, Paper 2023/272},
      year = {2023},
      doi = {10.1007/978-3-031-30731-7_3},
      note = {\url{https://eprint.iacr.org/2023/272}},
      url = {https://eprint.iacr.org/2023/272}

And I wonder what SP800-227 (not yet vailable) will be.
--