Why is Blowfish's key size limited to 128 bits in RFC 4880?

Johan Wevers johanw at vulcan.xs4all.nl
Tue Oct 13 17:59:00 CEST 2020


On 13-10-2020 16:46, Dieter Frye wrote:

> Now if any of this remains true today, I cannot tell (I did the research a
> number of years ago so it's possible something changed along the way), but
> even if not, it would still make sense to me to allow for greater (or
> better yet, full) key size to be utilized specially for situations when
> performance is extremely critical and something like Twofish just won't
> do.

Be careful though, there are ciphers known where extra keybits don't
increase security. If there are situations where they actually reduce
security I don't know, but the cipher would have to be re-investigated
after such a change.

Having said that, 128 bits is really enough, 256 is overkill "just
because we can".

> As for AES, while there doesn't seem to be anything fundamentally wrong
> with it, the fact that it was pushed so extensively by the powers that be
> and the fact that it's considerably easier on the hardware (as compared to
> say, Twofish), makes it a candidate for large-scale, targeted
> cryptanalysis, so I wouldn't put it past me that the NSA's onto something
> already.

Brute-forcing a 128 bits keyspace and certainly a 256 bit one is still
limited by the laws of physics, like in:

- It takes more time than the age of the universe,
- It requires more energy than the stars in the milky way emit during
their life,
- If you try to seriously paralellize it, there is not enough matter in
the known universe to build all those computers.

As long as the above are the limits I feel secure enough with the keysize.

Quantum computers with enough qubits reduce the workload to brute force
symmetric ciphers typical by a factor of a square root, so for those 256
bits is sufficient. But then the public keys become the weak point, the
short-keyed elliptic curve algorithms long before RSA and Elgamal (but
when elliptic curve gets into trouble you know it's only a matter of
time before the others will be too so they do need replacement then).

-- 
ir. J.C.A. Wevers
PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html




More information about the Gnupg-users mailing list