0

is it common , we increase key size to 512 Bit in AES Algorithm?

maryam
  • 19
  • 1

1 Answers1

2

No. It's not even possible, never mind uncommon. If you did, it would have to be a whole new internal construction and no longer able to be called AES. Have a look at the key schedule, especially the diagram on the right hand side. 512 bits won't fit.

Paul Uszak
  • 15,390
  • 2
  • 28
  • 77
  • Hi , Thanks For your response.I'm studying about symmetric Encryption algorithm and I am student in Master degree.and I want to optimization one Symmetric Encryption algorithm DES or AES , please help me and sen your Idea. Best Regards. – maryam Nov 30 '18 at 18:55
  • @maryam You may have to rethink your proposal after this and the 256 bit DES question. As demonstrated, it's not possible to increase a key size beyond the specification of the common primitives. You would have to re-architect the whole thing and there are few on Earth qualified to do that securely. It would not even be optimisation, but rather ground up design. Tricky. – Paul Uszak Dec 01 '18 at 00:55
  • However, you could look at the optimisation of the hard/soft implementation of standard DES or standard AES. Just consider that DES is no longer secure and too much effort on DES might be counter productive wrt your supervisor! – Paul Uszak Dec 01 '18 at 00:58
  • 1
    For a 512 bit cipher, consider working sha512 into a feistel structure. 512 bit key and 1024 bit block size. But why do this? Such a cipher would be no more secure in a practical sense, and possibly much less secure, than 128 bit AES. – WDS Dec 01 '18 at 19:05
  • 1
    You wouldn't need to change the internal construction, just run the key schedule for longer and use more rounds (for more round keys). But you're right that it would no longer be defined as AES. – forest Dec 02 '18 at 03:29
  • @forest Well that's a good point that I don't know how to argue against. But how many rounds - 18? The development of $rc_i$ isn't linear. And what would that mean? By the same principle, it would seem that you could go to 2560 bits. And more, but that feels wrong... – Paul Uszak Dec 02 '18 at 04:13
  • @PaulUszak Well more rounds isn't strictly necessary, but it's a good idea. They're often chosen by gut feeling, but 18 would certainly make sense. And you're right, it feels wrong because it is wrong. There's no need to expand it to 512 bits (and you can use XTS to boost the keyspace effectively for free anyway, albeit only to the equivalent of 384 bits). 256 is more than enough. :P – forest Dec 02 '18 at 04:20
  • @PaulUszak What do you mean by "the development of $rc_i$ isn't linear"? You can use any value of $i$. An implementation would be something like this. Each time you increment, you get another 128-bit subkey. BTW, an awesome resource for the Rijndael key schedule is https://samiam.org/key-schedule.html. – forest Dec 02 '18 at 07:12
  • @forest Well, you're now embarrassing me into admitting that I don't understand it any further than the $rc_i$ development on Wiki. After all, my expertise is compression & entropy :-) Aren't we rolling our own though? The main gut feeling is that if it was this easy, everyone would use 2560 bit AES keys with just minor tweaking. There'd be AES forks all over Git. That cannot be right, but I can't mathematically point out why. (NSA wouldn't allow it anyway). – Paul Uszak Dec 02 '18 at 11:57
  • 1
    @PaulUszak Why wouldn't the NSA allow it? The truth is that there's simply no reason to increase the keysize. 256 bits is more than enough. It is absolutely trivial to build a cipher with an arbitrary key size from a cipher like AES. The reason people don't fork it often is because the people who understand enough about crypto to do so know that it's pointless. – forest Dec 02 '18 at 12:06
  • And what is rolling our own? I didn't invent AES... – forest Dec 02 '18 at 12:13