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

[Nico Williams]

On Fri, Oct 4, 2013 at 11:20 AM, Ray Dillinger <bear at sonic.net> wrote:
> So, it seems that instead of AES256(key) the cipher in practice should be
> AES256(SHA256(key)).

More like: use a KDF and separate keys (obtained by applying a KDF to
a root key) for separate but related purposes.

For example, if you have a full-duplex pipe with a single pre-shared
secret key then: a) you should want separate keys for each direction
(so you don't need a direction flag in the messages to deal with
reflection attacks), b) you should derive a new set of keys for each
"connection" if there are multiple connections between the same two
peers.  And if you're using an AEAD-by-generic-composition cipher mode
then you'll want separate keys for data authentication vs. data
encryption.

The KDF might well be SHA256, but doesn't have to be.  Depending on
characteristics of the original key you might need a more complex KDF
(e.g., a PBKDF if the original is a human-memorable password).  This
(and various other details about accepted KDF technology that I'm
eliding) is the reason that you should want to think of a KDF rather
than a hash function.

Suppose some day you want to switch to a cipher with a different key
size.  If all you have to do is tell the KDF how large the key is,
then it's easy, but if you have to change the KDF along with the
cipher then you have more work to do, work that might or might not be
easy.  Being able to treat the protocol elements as modular has
significant advantages -and some pitfalls- over more monolythic
constructions.

Nico
--