2
$\begingroup$

I have limited math's knowledge so sorry if this question sounds stupid.

I saw many people complaining about AES, Twofish and Serpent that these ciphers all could be crackable in the near future and even today with big datacenters. But all these ciphers use max. 256 bit keys . And because there is no better way of finding the key then brute force the ciphers are equally strong.

Would it be possible to take these algorithms e.g AES and just change the key size from 256 to 512 or 1024? I mean the algorithm is well tested, you would just have to modify the key and block size.

$\endgroup$
  • 2
    $\begingroup$ related $\endgroup$ – SEJPM Jul 30 '17 at 22:08
  • $\begingroup$ Also note that block ciphers are not general purpose ciphers in themselves. A block cipher is a keyed permutation; it isn't CPA secure by itself. $\endgroup$ – Maarten - reinstate Monica Jul 30 '17 at 23:04
  • $\begingroup$ you would not have to modify the block size $\endgroup$ – Richie Frame Jul 31 '17 at 3:43
12
$\begingroup$

I saw many people complainig about AES , twofish and serpent that these ciphers all could be crackable in the near future and even today with big datacenters .

This is a good example of why we should always ask for citations and explanations, rather then just accepting what people say at face value with no scrutiny. These claims are about as far from reality as possible.

But all these ciphers use max. 256 bit keys . And because there is no better way of finding the key then bruteforce the ciphers are equally strong .

These 3 ciphers all have similar if not identical parameter configurations because they were all designed for the AES competition. It is true enough for practical purposes (but not exactly so) that all three are equally strong and that the only way you'll break them without side channel attacks is via brute force.

Which is to say that you won't break them, at all.

Would it be possibel to take these algos e.g AES and just change the key size from 256 to 512 or 1024 ?

It is not possible to just increase the key size for an algorithm like AES; There are other aspects that are derived from the size of the key that you would have to take into account and modify as well. For instance, the AES key schedule (which is part of the AES block cipher) of AES-128 and AES-256 differs.

I mean the algo is well tested , you would just have to modify the key and blocksize .

Ok, let's concede and say we construct such a thing, and also assume we don't somehow introduce additional points of failure while doing so: What problem have we solved by increasing the key/blocksize? It was already impossible to search. Perhaps this is a good question to ask those people that were complaining about how easy it is to break AES, twofish, and serpent...

Why can't we give block ciphers bigger keys

We can, we do not need to. You can always construct make an algorithm use more space and time. The goal is to use the least amount of resources possible to get the job done. Once you understand this, it will be clear why we do not use massive keys or hundreds of cipher rounds.

$\endgroup$
  • $\begingroup$ but doesn't rc6 which was ( from what i heared ) also designed for the AES competition have up to 2048 bit key ? $\endgroup$ – Richard R. Matthews Jul 31 '17 at 11:18
  • $\begingroup$ Well , because I am not a professional I have to get my informations from somewhere . And sometimes you see some tinfoil hat stuff . crypto.stackexchange.com/questions/2251/how-secure-is-aes-256 $\endgroup$ – Richard R. Matthews Jul 31 '17 at 11:48
  • 1
    $\begingroup$ @RichardR.Matthews yes the RC6 algorithm supports longer key lengths; "AES" is more of a title then a name, and had RC6 been selected it only would have seen standardization of the 128, 192, and 256-bit variants. I understand that you need to get your information somewhere - I was not scolding you for asking your Q at all, just trying to make sure you learn accurate information so that if one day you ever apply it you can be sure that you are doing the correct, safe thing. I don't see any reasonable paranoia in the post that you link; A few downvoted answers is not cause for concern. $\endgroup$ – Ella Rose Jul 31 '17 at 16:14
  • $\begingroup$ the post I linked is maybe not the best example . Just the first I found . Anyway thank you . $\endgroup$ – Richard R. Matthews Jul 31 '17 at 19:51
10
$\begingroup$

I saw many people complainig about AES , twofish and serpent that these ciphers all could be crackable in the near future and even today with big datacenters

Let me go through some of the lesser known details about the NSA's capabilities, and how fast they are able to break AES-256:

  • Their annual budget has been drastically underreported; it is actually $100 trillion dollars per year (that is, the world-wide GDP), and has been at that level for the past 100 years.

  • They spend all that money on AES-cracking equipment (and so, yes, the spooks are working for free)

  • They purchase AES-breaking chips for $0.01 (that is, one cent) each (hey, volume discount); each chip has a billion AES engines on it, and each engine can test one trillion AES keys per second.

Hence, given their investment, they can test $100 \text{ trillion} \times 100 / 0.01 \times 1 \text{ billion} \times 1 \text{ trillion} = 10^{39}$ keys per second.

They are now trying to break their first AES-256 key; they expect success in around $2^{255} / 10^{39} = 5.7E+37$ seconds, or in approximately $10^{20}$ times the current age of the universe. I'm not sure what that key is, or how relevant it will be after the heat death of the universe, but I'm sure it's pretty critical...

$\endgroup$
  • $\begingroup$ You forgot in your calculation, that the NSA has been buying that amount of AES chips every year for the last 100 years. So its actually $10^{41}$ keys per second and thus just $10^{35}$ seconds to go. ;-) $\endgroup$ – mat Jul 31 '17 at 9:38
  • $\begingroup$ It would definitely be bad luck if that key is in the top 20% of the key space they're searching right now :P $\endgroup$ – Maarten - reinstate Monica Jul 31 '17 at 12:18
  • $\begingroup$ @mat:actually, I didn't forgot the 100 years; that's the factor of 100 that's right after 100 trillion. Of course, looking back at my answer, I would have made it even more absurd assumptions ("the NSA has existed for the past 10,000 years, going chips at that rate...") $\endgroup$ – poncho Jul 31 '17 at 13:25
  • 1
    $\begingroup$ Damn, and I thought that I had finally an opportunity to correct @poncho. ;-) I really love your story, btw. It is not just funny but a really good explanation of the point you want to make. $\endgroup$ – mat Jul 31 '17 at 14:14
  • $\begingroup$ @mat: if you're looking for opportunities to correct me, well, don't worry, there are plenty of them in my answers... :-) $\endgroup$ – poncho Jul 31 '17 at 14:21
8
$\begingroup$

Cryptographers can and we do create block ciphers with bigger keys, take for instance the Threefish cipher which has key/block sizes of 256, 512 and 1024 bits.

However, since strong block ciphers with a key of 256 bits cannot be cracked even when quantum computers come of age, there is no need to use them for a cipher. Instead they are used for special purposes such as the use in a hash algorithm. That would of course be Skein - a SHA-3 finalist- for the Threefish algorithm.


The statement that "these ciphers all could be crackable in the near future and even today with big data centers" is completely wrong. People that complain about the key size for that reason don't know what they are talking about.


It is often not all that easy to change the key size. The algorithm may well depend on the key size for the key schedule, for instance. But mainly we don't because there isn't a need to when it comes to implementing ciphers. And for hash algorithms other parameters need to be changed as well, such as the block size and tweak for Skein.

$\endgroup$
  • 1
    $\begingroup$ Actually, there's some hypothetical use for "high-security" ciphers like Threefish-1024 :p $\endgroup$ – SEJPM Jul 30 '17 at 23:02
6
$\begingroup$

Respondents have well addressed the futility of trying to brute force a 256 bit AES key. It's hard. But I want to focus on your last paragraph.

Would it be possible to take these algorithms e.g AES and just change the key size from 256 to 512 or 1024? I mean the algorithm is well tested, you would just have to modify the key and block size.

Actually, no you can't. AES is well tested and a number of people have studied it. It works as a fait accompli by virtue of having been designed as a cohesive unit, with all sub operations working perfectly together. This is AES:-

AES

The rounds and the key expansion are the clever bits. A key of predetermined length is expanded so that derivatives of it can be introduced at each round in the algorithm. The key expansion is carefully designed to maximise entropy, avoid weak states and collisions. And they don't repeat so all round keys will be different. The algorithm is proven to work for 10 /128, 12 /192 and 14 /256 round /key permutations. And they also all produce fixed width (128 bit) round keys which contributes to having a 128 bit block width. That's invariant.

If you decide to upgrade AES to a 768 bit block width for uber security, you can't realistically. How would you expand a key of some length to produce repeated but different round keys of 768 bit width? The key scheduling is one of the most important parts of a cipher. It would mean a complete rewrite of the key scheduler.

And the individual round algorithm would have to be expanded to 768 bits. The following isn't from AES, but it has beautiful symmetry and illustrates to difficulty of arbitrary block width expansion:-

Keccard

Imagine this table containing all the bits in a round. It's 5 x 5 bits, and you can see the careful way the bits cycle round symmetrically. This adds to diffusion and the avalanche effect. Now imagine adding another row to create a 5 x 6 table. For a start, there's no middle bit in an even number of bits. You'd need to completely redesign the bit permutation sequence.

All the words above are a long winded way of saying that if you tried upgrading AES or any other cryptographic primitive, you'd have to completely rewrite it from scratch. So it's no longer well tested and you're back at square one.

$\endgroup$
  • $\begingroup$ Just about every word in this answer is wrong.. where do I begin? The Rijndael key schedule is in fact, a very weak and poorly designed key expansion function; with most of the round keys generated, the result of a simple XOR of two previous keys.. it is not magical; has poor diffusion qualities, and there is absolutely no mathematical correlation between the rounds function and how the key is expanded. Also round keys are 32 bits in length, unless you have written out some implementation of AES that uses 128bit integers? $\endgroup$ – JGU Feb 3 '18 at 0:59
  • $\begingroup$ The block size can be changed via modification of the rounds function, as demonstrated by existing 512 bit block size implementations of Rijndael, but that does not necessarily increase the security of the cipher (however, a larger random iv or nonce used by a cipher mode could increase security). Lastly, you can not 'maximize entropy', the entropy contained in the input cipher key is constant, only the thoroughness of the mix (diffusion) is variable. $\endgroup$ – JGU Feb 3 '18 at 0:59
  • $\begingroup$ @John Are you really really sure that AES round keys are only 32 bits? And how would you increase the block size of the question's Twofish or Serpent? $\endgroup$ – Paul Uszak Feb 3 '18 at 13:39
  • $\begingroup$ A round key block is 128 bits, most implementations of AES use 32bit integers, (there are 128bit round keys however, used by AES-NI, but I won't muddy the issue with that). The number of round keys is determined by the number of rounds (NR+1) *4, that is the number of rounds plus a whitening stage times the number of 32bit integers in a block. So with AES256 you generate 60 round keys. Twofish and serpent could be expanded to use a wider block, it would involve re-writing the rounds functions, but as I said, this doesn't necessarily make them stronger, it only processes a larger block. $\endgroup$ – JGU Feb 3 '18 at 15:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.