<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Oct 3, 2013 at 3:25 PM,  <span dir="ltr"><<a href="mailto:leichter@lrw.com" target="_blank">leichter@lrw.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>On Oct 3, 2013, at 12:21 PM, Jerry Leichter <<a href="mailto:leichter@lrw.com" target="_blank">leichter@lrw.com</a>> wrote:<br>


> As *practical attacks today*, these are of no interest - related key attacks only apply in rather unrealistic scenarios, even a 2^119 strength is way beyond any realistic attack, and no one would use a reduced-round version of AES-256.<br>


</div>Expanding a bit on what I said:  Ideally, you'd like a cryptographic algorithm let you build a pair of black boxes.  I put my data and a key into my black box, send you the output; you put the received data and the same key (or a paired key) into your black box; and out comes the data I sent you, fully secure and authenticated.  Unfortunately, we have no clue how to build such black boxes.  Even if the black boxes implement just the secrecy transformation for a stream of blocks (i.e., they are symmetric block ciphers), if there's a related key attack, I'm in danger if I haven't chosen my keys carefully enough.<br>

</blockquote><div>This is complete and utter bullshit if you can count, or make big enough random numbers if you cannot. Read "Cryptography in NaCl" or</div><div>Rogaway's analysis of authenticated encryption modes in standards if you don't believe this is a solved problem in theory, or heck, even the GCM or CCM standards. Or Rogaways OCB paper.</div>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
No protocol anyone is likely to use is subject to a related key attack, but it's one of those flaws that mean we haven't really gotten where we should.  Also, any flaw is a hint that there might be other, more dangerous flaws elsewhere.<br>

</blockquote><div>PRP security does not imply security in the related-key model. It also doesn't imply sPRP security. But you don't need it.</div><div>Now, if you are making a claim about block cipher constructions, go show me why this matters by publishing an attack or some theoretical analysis about related keys leading to good attacks in a stronger setting.</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
If you think in these terms about asymmetric crypto, the situation is much, much worse.  It turns out that you have to be really careful about what you shove into those boxes, or you open yourself up to all kinds of attacks.  The classic paper on this subject is <a href="http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=4568385&url=http%3A%2F%2Fieeexplore.ieee.org%2Fiel5%2F4568363%2F4568364%2F04568385.pdf%3Farnumber%3D4568385" target="_blank">http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=4568385&url=http%3A%2F%2Fieeexplore.ieee.org%2Fiel5%2F4568363%2F4568364%2F04568385.pdf%3Farnumber%3D4568385</a>, the text for which appears to available only for a fee. </blockquote>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><div><br>
                                                        -- Jerry<br>
<br>
_______________________________________________<br>
The cryptography mailing list<br>
<a href="mailto:cryptography@metzdowd.com" target="_blank">cryptography@metzdowd.com</a><br>
<a href="http://www.metzdowd.com/mailman/listinfo/cryptography" target="_blank">http://www.metzdowd.com/mailman/listinfo/cryptography</a><br>
</div></div></blockquote></div><br>Sincerely,<br>Watson Ladd<br clear="all"><div><br></div>-- <br>"Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither  Liberty nor Safety."<br>
-- Benjamin Franklin 
</div></div>