[147493] in cryptography@c2.net mail archive

home help back first fref pref prev next nref lref last post

Re: [Cryptography] AES-256- More NIST-y? paranoia

daemon@ATHENA.MIT.EDU (Watson Ladd)
Fri Oct 4 09:54:05 2013

X-Original-To: cryptography@metzdowd.com
In-Reply-To: <45C1A5F9-CB34-42BD-A800-7B7349028E04@lrw.com>
Date: Thu, 3 Oct 2013 18:59:20 -0700
From: Watson Ladd <watsonbladd@gmail.com>
To: Jerry Leichter <leichter@lrw.com>
Cc: Cryptography <cryptography@metzdowd.com>, Ray Dillinger <bear@sonic.net>,
	Brian Gladman <brg@gladman.plus.com>
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com

--===============2909419330502053285==
Content-Type: multipart/alternative; boundary=089e013d19cc9ea94504e7e0a6f9

--089e013d19cc9ea94504e7e0a6f9
Content-Type: text/plain; charset=UTF-8

On Thu, Oct 3, 2013 at 3:25 PM, <leichter@lrw.com> wrote:

> On Oct 3, 2013, at 12:21 PM, Jerry Leichter <leichter@lrw.com> wrote:
> > 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.
> 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.
>
This is complete and utter bullshit if you can count, or make big enough
random numbers if you cannot. Read "Cryptography in NaCl" or
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.

>
> 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.
>
PRP security does not imply security in the related-key model. It also
doesn't imply sPRP security. But you don't need it.
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.

> 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
> http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=4568385&url=http%3A%2F%2Fieeexplore.ieee.org%2Fiel5%2F4568363%2F4568364%2F04568385.pdf%3Farnumber%3D4568385,
> the text for which appears to available only for a fee.


>                                                         -- Jerry
>
> _______________________________________________
> The cryptography mailing list
> cryptography@metzdowd.com
> http://www.metzdowd.com/mailman/listinfo/cryptography
>

Sincerely,
Watson Ladd

-- 
"Those who would give up Essential Liberty to purchase a little Temporary
Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin

--089e013d19cc9ea94504e7e0a6f9
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Thu, Oct 3, 2013 at 3:25 PM,  <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:leichter@lrw.com" target=3D"_blank">leichter@lrw.com</a>&gt;</span> w=
rote:<br>

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


&gt; As *practical attacks today*, these are of no interest - related key a=
ttacks 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 vers=
ion of AES-256.<br>


</div>Expanding a bit on what I said: =C2=A0Ideally, you&#39;d like a crypt=
ographic algorithm let you build a pair of black boxes. =C2=A0I put my data=
 and a key into my black box, send you the output; you put the received dat=
a and the same key (or a paired key) into your black box; and out comes the=
 data I sent you, fully secure and authenticated. =C2=A0Unfortunately, we h=
ave no clue how to build such black boxes. =C2=A0Even if the black boxes im=
plement just the secrecy transformation for a stream of blocks (i.e., they =
are symmetric block ciphers), if there&#39;s a related key attack, I&#39;m =
in danger if I haven&#39;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 &quot;Cryptography in Na=
Cl&quot; or</div><div>Rogaway&#39;s analysis of authenticated encryption mo=
des in standards if you don&#39;t believe this is a solved problem in theor=
y, or heck, even the GCM or CCM standards. Or Rogaways OCB paper.</div>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
<br>
No protocol anyone is likely to use is subject to a related key attack, but=
 it&#39;s one of those flaws that mean we haven&#39;t really gotten where w=
e should. =C2=A0Also, any flaw is a hint that there might be other, more da=
ngerous flaws elsewhere.<br>

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

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

--089e013d19cc9ea94504e7e0a6f9--

--===============2909419330502053285==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
--===============2909419330502053285==--

home help back first fref pref prev next nref lref last post