Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

>...all target exactly the two deliberately chosen weaknesses from when it was designed 50 years ago...

I would quibble the deliberate part for the block length (and perhaps strengthen your point). DES came out in the 70's and people were still designing 64 bit ciphers in the 90's. Examples: IDEA, CAST5, Blowfish. I think that it is most likely that the the 56 bit key length was really the only factor intended to make DES deliberately weak. Gigabyte scale files/sessions were just not a thing back then.



The ancestor of DES at IBM, Lucifer, had both an 128-bit block length and 128-bit keys.

Therefore there is no doubt that both the reduction of the key length and of the block length have been deliberate.

The only thing that can be argued is that perhaps the motivation for the reduction in the block length could have been less for weakening the cipher, but more for reducing the cost of the hardware, based on the assumption that the cipher will be used only for the encryption of amounts of data that are very small for today, but which could have seemed big during the mid seventies.


To make a 64 bit block size be helpful for signals intelligence in the '70s the following things would have to be true:

1. Someone would have an encrypted session or file that ran into the 10s of GB.

2. The signals intelligence entity would have to somehow have gotten access that much data. Did they tap a telephone line and intercept a 300 bps modem connection for 30 years straight? Did they get access to half a billion encrypted punch cards?

3. The signals intelligence entity would have enough processing power and memory to actually find the collisions.

4. The signals intelligence entity would be able to extract some useful information out of 1 or 2 colliding 8 byte blocks randomly chosen out of billions in the same file/session. The extreme unlikeliness of that is why such collisions are still of little practical use today.


When using a block cipher function solely for encryption, it is difficult to exploit a small block size.

On the other hand, a short block size complicates a lot the use of a block cipher function in other useful algorithms, e.g. key derivation algorithms, RNG algorithms, MAC algorithms etc.

The necessity of using a block cipher function also for such purposes has become very obvious almost immediately after the standardization of DES, but then it was too late.

Such applications have been seriously hindered for a couple of decades, until the mid nineties, by the lack of any other publicly known strong block cipher functions. Many workarounds have been published with the purpose of using DES even where its short block length was unacceptable, but all such workarounds were more inefficient than using a block cipher with a greater block size. They were designed only because it was expected that using the already existing hardware integrated circuits that computed DES would be more efficient than implementing a block cipher function in software, on the slower computers of that time.




Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: