<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 Tue, Feb 7, 2023 at 2:56 PM Nico Williams <<a href="mailto:nico@cryptonector.com">nico@cryptonector.com</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 Mon, Feb 06, 2023 at 11:48:40PM -0500, Phillip Hallam-Baker wrote:<br>
> On Mon, Feb 6, 2023 at 5:32 PM Nico Williams <<a href="mailto:nico@cryptonector.com" target="_blank">nico@cryptonector.com</a>> wrote:<br>
> > RFC 7253, section 5.1, Nonce Requirements:<br>
> ><br>
> > [...]<br>
> <br>
> I certainly would not. What Rogaway is saying there is that he can't prove<br>
> the correctness of the construction with nonce reuse. And I am not in the<br>
> least bit surprised that he can't. But not being able to formulate a formal<br>
> proof is not the same as 'collapses'. GCM definitely collapses, no question.<br>
<br>
That's fair.  Kinda like confounder reuse in Kerberos' confounded CTS<br>
HMAC construction: there is insufficient cryptanalysis to know how bad<br>
it is, but it seems secure enough in the face of reuse that one<br>
needn't move mountains to avoid it.<span class="gmail_default" style="font-size:small"></span></blockquote><div><br></div><div class="gmail_default" style="font-size:small">I had email exchanges with Phil on OCB after he wrote that paper and he didn't say not to use it. He renounced the remaining patent rights shortly after.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">What Phil is trying to do is to come up with ultra precise understanding of the security a construction delivers. But my understanding is that we still don't have a construction that can be considered ideal in every respect and we might not have finished enumerating the requirements.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Similarly, I have moved on from my approach in the 1990s when I was satisfied with foiling the attacker with a single layer of defense. These days, I am looking at multi-layer systems and attempting to use different principles of construction at each. I don't rely on transport/presentation security for more than preventing traffic analysis but I do require that it protect confidentiality and integrity of the payload even though those are also protected end-to-end.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><br></div></div></div>