<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:small"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Aug 4, 2022 at 1:19 AM Stephan Mueller <<a href="mailto:smueller@chronox.de">smueller@chronox.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Am Sonntag, 31. Juli 2022, 17:11:49 CEST schrieb Phillip Hallam-Baker:<br>
<br>
Hi Phillip,<br>
<br>
> I am trying to get some info on the mechanism underlying NIST's chosen key<br>
> exchange, Kyber. So far the most accessible explanation is the Python<br>
> implementation.<br>
> <br>
> If we are going to adopt a new approach to public key, some of us will want<br>
> to understand it. And academic papers that spend the entire time<br>
> referring to the differences with the previous papers are really no help at<br>
> all.<br>
> <br>
> So does anyone have a pointer to a YouTube with a good description of the<br>
> Lattice crypto approach? Just telling me something is a lattice is really<br>
> telling me nothing at all. It might as well be a Hausdorffian Manifold with<br>
> Lipschitz signature.<br>
> <br>
> At least some of the information I have received is inconsistent. I am told<br>
> that I can't use Kyber as a drop in for ECDH because it is an interactive<br>
> key exchange. The API seems to suggest otherwise. From a protocol design<br>
> point of view, there is really no difference between a Key Agreement and a<br>
> Key Encapsulation that can't be fixed with a bit of Key Wrap.<br>
> <br>
> The use case I have in mind is:<br>
> <br>
> 1) Alice exchanges public keys with Bob.<br>
> 2) Alice writes a Word document and encrypts to Bob's public key<br>
> 3) Alice puts enveloped Word document on thumb drive and mails it to Bob<br>
> 4) Bob gets the thumb drive and decrypts the document.<br>
<br>
I have integrated Kyber into my small little crypto library. During that <br>
process, unfortunately I have not fully understood yet what mathematical <br>
problem truly is the heart of the issue that is not solvable without the keys.<br>
<br>
But I have fully documented the Kex operation in [1] and [2] which should <br>
answer your 2nd part of your question.<br>
> <br>
> From what was said at the CFRG meeting, I was expecting I might have to do<br>
> an El Gamal like move and create an ephemeral key pair per document to<br>
> encrypt. But that doesn't seem to be the case looking at the API.<br>
<br>
It is creating an ephemeral key, see [1] and [2].<br></blockquote><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
[1] Unilateral: <a href="https://github.com/smuellerDD/leancrypto/blob/master/kem/api/lc_kyber.h#L171" rel="noreferrer" target="_blank">https://github.com/smuellerDD/leancrypto/blob/master/kem/api/<br>
lc_kyber.h#L171</a><br>
<br>
[2] Authenticated: <a href="https://github.com/smuellerDD/leancrypto/blob/master/kem/api/lc_kyber.h#L280" rel="noreferrer" target="_blank">https://github.com/smuellerDD/leancrypto/blob/master/kem/<br>
api/lc_kyber.h#L280</a></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">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.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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?</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">The problem I am focused on is Data at Rest (but not in Use). The Kyber primitive looks fine.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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.</div><br></div><div><br></div><div><br></div><div> </div></div></div>