[Cryptography] Kyber PQC Key Exchange

[Phillip Hallam-Baker]

On Thu, Aug 4, 2022 at 1:19 AM Stephan Mueller <smueller at chronox.de> wrote:

> Am Sonntag, 31. Juli 2022, 17:11:49 CEST schrieb Phillip Hallam-Baker:
>
> Hi Phillip,
>
> > I am trying to get some info on the mechanism underlying NIST's chosen
> key
> > exchange, Kyber. So far the most accessible explanation is the Python
> > implementation.
> >
> > If we are going to adopt a new approach to public key, some of us will
> want
> > to understand it. And academic papers that spend the entire time
> > referring to the differences with the previous papers are really no help
> at
> > all.
> >
> > So does anyone have a pointer to a YouTube with a good description of the
> > Lattice crypto approach? Just telling me something is a lattice is really
> > telling me nothing at all. It might as well be a Hausdorffian Manifold
> with
> > Lipschitz signature.
> >
> > At least some of the information I have received is inconsistent. I am
> told
> > that I can't use Kyber as a drop in for ECDH because it is an interactive
> > key exchange. The API seems to suggest otherwise. From a protocol design
> > point of view, there is really no difference between a Key Agreement and
> a
> > Key Encapsulation that can't be fixed with a bit of Key Wrap.
> >
> > The use case I have in mind is:
> >
> > 1) Alice exchanges public keys with Bob.
> > 2) Alice writes a Word document and encrypts to Bob's public key
> > 3) Alice puts enveloped Word document on thumb drive and mails it to Bob
> > 4) Bob gets the thumb drive and decrypts the document.
>
> I have integrated Kyber into my small little crypto library. During that
> process, unfortunately I have not fully understood yet what mathematical
> problem truly is the heart of the issue that is not solvable without the
> keys.
>
> But I have fully documented the Kex operation in [1] and [2] which should
> answer your 2nd part of your question.
> >
> > From what was said at the CFRG meeting, I was expecting I might have to
> do
> > an El Gamal like move and create an ephemeral key pair per document to
> > encrypt. But that doesn't seem to be the case looking at the API.
>
> It is creating an ephemeral key, see [1] and [2].
>


> [1] Unilateral:
> https://github.com/smuellerDD/leancrypto/blob/master/kem/api/
> lc_kyber.h#L171
> <https://github.com/smuellerDD/leancrypto/blob/master/kem/api/lc_kyber.h#L171>
>
> [2] Authenticated:
> https://github.com/smuellerDD/leancrypto/blob/master/kem/
> api/lc_kyber.h#L280
> <https://github.com/smuellerDD/leancrypto/blob/master/kem/api/lc_kyber.h#L280>


Looking back at the CFRG discussion, I am starting to think that the root
of this problem is that some people have 'Data in Motion' wrapped around
their axles as the only problem in data security. And further, the only way
they can imagine addressing the issue is in the TLS key exchange framework.

I never liked the TLS exchange. It was too complicated from the start and
the integration of forward secrecy was botched. Why throw away the shared
secret entirely rather than use that plus the ephemeral as inputs to the
KDF?

The problem I am focused on is Data at Rest (but not in Use). The
Kyber primitive looks fine.

Where we might well have issues down the line is that the NIST competition
specified a particular interface and that required a particular packaging
approach that may not be ideal for certain applications. When the SHA-3
competition finished we got the hash functions as promised but we also got
the SHAKE functions based on the same tech. It is possible something of the
sort may be possible here.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.metzdowd.com/pipermail/cryptography/attachments/20220804/934b118e/attachment.htm>