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 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.

Arnold Reinhold


On Sat, 5 Oct 2013 19:37, Nico Williams <n...@cryptonector.com> wrote:
> On Fri, Oct 4, 2013 at 11:20 AM, Ray Dillinger <b...@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
_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

Reply via email to