<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 Fri, Aug 5, 2022 at 1:04 PM Viktor Dukhovni <<a href="mailto:cryptography@dukhovni.org">cryptography@dukhovni.org</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">On Fri, Aug 05, 2022 at 02:31:39AM -0400, Phillip Hallam-Baker wrote:<br>
<br>
> > Do you really want to open the black box, or are you looking for a<br>
> > better description of the knobs on the front panel?  My guess is mostly<br>
> > the latter...<br>
> ><br>
> <br>
> Actually, I am trying to understand what I now believe was misunderstanding<br>
> on the part of the cryptographers supposedly providing an explanation.<br>
> <br>
> The NIST competition has a very specific interface which is indeed a<br>
> black box that can slot into the same hole that is already in my code.<br>
<br>
Right, we have a *layered* black box, and some of the knobs are hidden<br>
on the inside.  It may be too early to speculate about which operating<br>
modes will be available when the standards are finalised.  So some<br>
confusion is perhaps to be expected at this time?<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">I think part of the problem here is that the cryptographers don't actually understand how we build protocols.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Take the SHA-2 compressor function used in the Merkel-Damgard construction. That is indisputably a solid cryptographic module which if I was a cryptographer, I might well make use of in a design in the same fashion as SHAKE-256 is used. I understand the cryptographic properties and would have absolutely no problem applying them in an algorithm proposal. But there is absolutely no way that I would propose a protocol specification that attempted to make use of that module as a standards based component because it isn't.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">So what we have right now is a NIST competition that has selected KYBER but has not yet specified what the operations modes will be. And they are looking at the inner modules and building protocols from those which is perfectly acceptable in the academic cryptography world but is utterly verboten in the standards based protocol design world.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">And in the process they are creating a mass of confusion with a series of categorical statements about the limitations of Kyber which are simply not true and they really need to stop.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">As far as I am concerned, the only algorithm NIST has actually endorsed at this point is the algorithm that was actually tested, an 'encryption' function which is given a public key and returns a shared secret and an encrypted blob that returns the shared secret when decrypted with the private key.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">If we trust the NIST competition, we should trust that construction, but that is all we can trust.</div><div class="gmail_default" style="font-size:small"> </div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
0-RTT unilateral key wrap may not yet have been in scope.  We'll have to<br>
wait and see what other operating modes are standardised (perhaps I<br>
missed publication of Kyber-based proposed standard constructions of<br>
this type).<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">I don't think 0-RTT is really a thing. No really. The way that we achieve 0-RTT is to push parts of the interaction into a different infrastructure so we don't count them in the protocol we are selling at the time.</div><br></div><div><div class="gmail_default" style="font-size:small">The PQC interface selected by NIST allows me to implement OpenPGP and S/MIME without any difficulty. Thats 0-RTT as far as I am concerned. It is also the only non-interactive pattern that interests me.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">The TLS folk have problems. But they don't require major modification to their protocol approach. A much bigger problem for them is likely to be the fact that they use signature in their key exchange which is and always was stupid for a start. Even worse when they don't have a signature algorithm choice.</div></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> So yes I do actually need to understand more than just the black box<br>
> because there are actually two boxes at issue here. There is an outer<br>
> box which is the one that NIST selected and there is an inner box.<br>
<br>
Indeed, and yes the published expository material is still often<br>
confusingly incomplete.<br></blockquote><div><br></div><div class="gmail_default" style="font-size:small">And I rather suspect that a lot of other people were as confused as I was but were unwilling to say so.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">My college tutor was Tony Hoare and one of his famous computing parables was the emperor's old clothes. I have always been wary of the emperor's new clothes effect where people are afraid to ask questions for fear of looking stupid and the result is we end up doing stupid things.</div></div></div>