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
