[CFRG] Kyber 'interactive key agreement'?

[Phillip Hallam-Baker <[e-mail]>]

I am trying to understand the precise set of constraints imposed by Kyber
after looking at the source code. In particular I note the existence of
functions with the following signatures:

int crypto_kem_keypair(unsigned char *pk, unsigned char *sk)

int crypto_kem_enc(unsigned char *ct,
                   unsigned char *ss,
                   const unsigned char *pk)

int crypto_kem_dec(unsigned char *ss,
                   const unsigned char *ct,
                   const unsigned char *sk)

Where:

sk is a sequence of bytes describing a private key
pk is a sequence of bytes describing a private key
ss is a sequence of bytes being the shared secret
ct is a sequence of bytes being the ciphertext

This might not look like it is a drop in replacement for ECDH, but it is
close enough to being a drop in for ElGamal Encryption using ECDH.

[These routines call indcpa_enc, indcpa_dec which have rather different
signatures. But the external interface is drop-in as far as I can see.]

I did a search on 'malleability' in the Kyber paper and found nothing. So
perhaps a clarification of the terms.


I have the following scheme for a PQC hardened version of the DARE format:
https://www.ietf.org/archive/id/draft-hallambaker-mesh-dare-15.html

In the standard DARE ECDH exchange, there are two/three inputs to the KDF
and two outputs

Input 1: A unique per message salt
Input 2: Result of the ECDH key agreement
Output 1: The initialization vector
Output 2: The encryption key
Output 3: The authentication key (if needed)

So it seems to me like all I have to add to get to PQC is to have three
inputs to my KDF:

Input 1: A unique per message salt
Input 2: Result of the ECDH key agreement
Input 3: Result of the Kyber key agreement

Am I missing something? If so, what am I missing?


An introduction to this stuff that does not assume familiarity with a
decade of work on applying lattice theory to crypto would be very much
appreciated. I have managed to avoid COVID so far but my ability to
concentrate is much reduced after the Guillain-Barré incident.


It also occurs to me that the NIST/NSA objection to 'hybrid' systems might
well be based on very different assumptions to those of us in the IETF
community. As a design goal, it seems to me that we absolutely have to get
to the point at which we can trust pure PQC systems without a backup
conventional crypt scheme. They think in terms of decades-long procurement
cycles.

I am looking to ship experimental code this year. IETF is looking to have
standards in a few years. Both are shorter than NIST/NSA timelines. There
is absolutely no way I am going to be convinced Kyber is safe enough to be
used on its own in the next five years and it does not provide the
threshold capabilities I need even if it does. At least not yet.