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

Nico Williams nico at cryptonector.com
Mon Oct 7 13:12:12 EDT 2013


On Mon, Oct 07, 2013 at 11:45:56AM -0400, Arnold Reinhold wrote:
> If we are going to always use a construction like AES(KDF(key)), as
> Nico suggests, why not go further and use a KDF with variable length
> output like Keccak to replace the AES key schedule? And instead of

Note, btw, that Keccak is very much like a KDF, and KDFs generally
produce variable length output.  In fact, the HKDF construction
[RFC5869] is rather similar to the sponge concept underlying Keccak.  It
was the use of SHA-256 as a KDF [but not in an HKDF-like construction]
that I was objecting to.

> making provisions to drop in a different cipher should a weakness be
> discovered in AES,  make the number of AES (and maybe KDF) rounds a
> negotiated parameter.  Given that x86 and ARM now have AES round
> instructions, other cipher algorithms are unlikely to catch up in
> performance in the foreseeable future, even with an higher AES round
> count. Increasing round count is effortless compared to deploying a
> new cipher algorithm, even if provision is made the protocol. Dropping
> such provisions (at least in new designs) simplifies everything and
> simplicity is good for security.

As Jerry Leichter said, that's a really nice idea.  My IANAC concern
would be that there might be greatly diminished returns past some number
of rounds relative to the sorts of future attacks that that might
drastically weaken AES.  There are also issues with cipher modes to
worry about, so that on the whole I would still like to have algorithm
agility (though I don't think you were arguing against it!); but the
addition of a cipher strength knob might well be useful.

You're quite right that with CPU support for AES it will be very
difficult to justify switching to any other cipher...  There's always
3AES (a form of round count, but a layer up, and with much bigger step
sizes).  I suspect it's not AES we'll have problems with, but everything
else (asymmetric crypto and cipher modes most likely).

Nico
-- 


More information about the cryptography mailing list