[147540] 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 (Phillip Hallam-Baker)
Mon Oct 7 09:54:05 2013

X-Original-To: cryptography@metzdowd.com
In-Reply-To: <B2468FD6-0363-494C-A7A3-99137F9B20E1@lrw.com>
Date: Sun, 6 Oct 2013 21:10:21 -0400
From: Phillip Hallam-Baker <hallam@gmail.com>
To: Jerry Leichter <leichter@lrw.com>
Cc: "cryptography@metzdowd.com" <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

--===============1677174060952328666==
Content-Type: multipart/alternative; boundary=089e0158b5e8f2a1f404e81c50d8

--089e0158b5e8f2a1f404e81c50d8
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Oct 3, 2013 at 12:21 PM, Jerry Leichter <leichter@lrw.com> wrote:

> On Oct 3, 2013, at 10:09 AM, Brian Gladman <brg@gladman.plus.com> wrote:
> >> Leaving aside the question of whether anyone "weakened" it, is it
> >> true that AES-256 provides comparable security to AES-128?
> >
> > I may be wrong about this, but if you are talking about the theoretical
> > strength of AES-256, then I am not aware of any attacks against it that
> > come even remotely close to reducing its effective key length to 128
> > bits.  So my answer would be 'no'.
> There are *related key* attacks against full AES-192 and AES-256 with
> complexity  2^119.  http://eprint.iacr.org/2009/374 reports on improved
> versions of these attacks against *reduced round variants" of AES-256; for
> a 10-round variant of AES-256 (the same number of rounds as AES-128), the
> attacks have complexity 2^45 (under a "strong related sub-key" attack).
>
> None of these attacks gain any advantage when applied to AES-128.
>
> 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.
>
> As a *theoretical checkpoint on the strength of AES* ... the abstract says
> the results "raise[s] serious concern about the remaining safety margin
> offered by the AES family of cryptosystems".
>
> The contact author on this paper, BTW, is Adi Shamir.


Shamir said that he would like to see AES detuned for speed and extra
rounds added during the RSA conf cryptographers panel a couple of years
back.

That is the main incentive for using AES 256 over 128. Nobody is going to
be breaking AES 128 by brute force so key size above that is irrelevant but
you do get the extra rounds.


Saving symmetric key bits does not really bother me as pretty much any
mechanism I use to derive them is going to give me plenty. I am even
starting to think that maybe we should start using the NSA checksum
approach.

Incidentally, that checksum could be explained simply by padding prepping
an EC encrypted session key. PKCS#1 has similar stuff to ensure that there
is no known plaintext in there. Using the encryption algorithm instead of
the OAEP hash function makes much better sense.


-- 
Website: http://hallambaker.com/

--089e0158b5e8f2a1f404e81c50d8
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Thu, Oct 3, 2013 at 12:21 PM, Jerry Leichter <span dir=
=3D"ltr">&lt;<a href=3D"mailto:leichter@lrw.com" target=3D"_blank">leichter=
@lrw.com</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"=
gmail_quote">
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im">On Oct 3, 2013, at 10:09 A=
M, Brian Gladman &lt;<a href=3D"mailto:brg@gladman.plus.com">brg@gladman.pl=
us.com</a>&gt; wrote:<br>

&gt;&gt; Leaving aside the question of whether anyone &quot;weakened&quot; =
it, is it<br>
&gt;&gt; true that AES-256 provides comparable security to AES-128?<br>
&gt;<br>
&gt; I may be wrong about this, but if you are talking about the theoretica=
l<br>
&gt; strength of AES-256, then I am not aware of any attacks against it tha=
t<br>
&gt; come even remotely close to reducing its effective key length to 128<b=
r>
&gt; bits. =A0So my answer would be &#39;no&#39;.<br>
</div>There are *related key* attacks against full AES-192 and AES-256 with=
 complexity =A02^119. =A0<a href=3D"http://eprint.iacr.org/2009/374" target=
=3D"_blank">http://eprint.iacr.org/2009/374</a> reports on improved version=
s of these attacks against *reduced round variants&quot; of AES-256; for a =
10-round variant of AES-256 (the same number of rounds as AES-128), the att=
acks have complexity 2^45 (under a &quot;strong related sub-key&quot; attac=
k).<br>

<br>
None of these attacks gain any advantage when applied to AES-128.<br>
<br>
As *practical attacks today*, these are of no interest - related key attack=
s 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 o=
f AES-256.<br>

<br>
As a *theoretical checkpoint on the strength of AES* ... the abstract says =
the results &quot;raise[s] serious concern about the remaining safety margi=
n offered by the AES family of cryptosystems&quot;.<br>
<br>
The contact author on this paper, BTW, is Adi Shamir.</blockquote><div><br>=
</div><div>Shamir said that he would like to see AES detuned for speed and =
extra rounds added during the RSA conf cryptographers panel a couple of yea=
rs back.</div>
<div><br></div><div>That is the main incentive for using AES 256 over 128. =
Nobody is going to be breaking AES 128 by brute force so key size above tha=
t is irrelevant but you do get the extra rounds.</div><div><br></div><div>
<br></div><div>Saving symmetric key bits does not really bother me as prett=
y much any mechanism I use to derive them is going to give me plenty. I am =
even starting to think that maybe we should start using the NSA checksum ap=
proach.</div>
<div><br></div><div>Incidentally, that checksum could be explained simply b=
y padding prepping an EC encrypted session key. PKCS#1 has similar stuff to=
 ensure that there is no known plaintext in there. Using the encryption alg=
orithm instead of the OAEP hash function makes much better sense.</div>
<div>=A0</div></div><div><br></div>-- <br>Website: <a href=3D"http://hallam=
baker.com/">http://hallambaker.com/</a><br>
</div></div>

--089e0158b5e8f2a1f404e81c50d8--

--===============1677174060952328666==
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
--===============1677174060952328666==--

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