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

[Phillip Hallam-Baker]

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

> On Oct 3, 2013, at 10:09 AM, Brian Gladman <brg at 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/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20131006/abafe1ce/attachment.html>