[Cryptography] Adapting AES for arbitrarily large keys

[Natanael]

- Sent from my tablet
Den 18 aug 2014 05:24 skrev "Marc W. Abel" <marc at clique4.us>:
>
> Friends,
>
> Most here would be familiar with the AES key schedule, which expands
128-, 192-, and 256-bit keys into key schedules totalling 1408, 1664, and
1792 bits.
>
> Would AES be any weaker had it been designated, for instance, as
AES-1408, AES-1664, and AES-1792, with keys of this size being directly
generated and used, and no subkey expansion at all?  And if not weaker,
would the resulting cipher continue to strengthen as expected every time
another round and 128 key bits is tacked on? (AES-65536, AES-1048576, etc.?)

(Disclaimer: I'm not a cryptographer and this is from memory. Feel free to
correct me if I'm wrong.)

I'm trying to find the source but can't, but IIRC in one of the recent
discussions on AES or DES on one of these crypto mailing lists somebody
asked something similar, and the reply was that the individual rounds do
not contribute as much bit-strength security as the round key has bits, no
matter the key entropy. Because each transformation / permutation isn't
significantly complex by itself. The strength of the full algorithm depends
on the combination of all the rounds, and given a proper key schedule you
just need to feed the cipher with a key with enough entropy to make it
strong enough.

But it wouldn't be *weaker* if each round is supposed to have a fully
(pseudo)random key without any special properties. Although if the cipher
rounds WOULD be designed to require special properties which the key
schedule provides, fully random round keys could weaken it (doesn't seem
like this would be a common design goal).

Define "tacked on", do you mean several layers of encryption? It wouldn't
be more secure than regular AES in layers. Also note that you generally
don't multiply the strength when combining layers of ciphers, you usually
just add it up. 2xAES256 doesn't equal AES512. Look up meet-in-the-middle
attacks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20140818/469cc4aa/attachment.html>