Mailing List Archive

Why is Blowfish's key size limited to 128 bits in RFC 4880?
What's the rationale behind not going full 448 or at least 256 like AES
and Twofish?

Best regards.


_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Why is Blowfish's key size limited to 128 bits in RFC 4880? [ In reply to ]
> What's the rationale behind not going full 448 or at least 256 like
> AES and Twofish?

Age. At the time Blowfish was adopted there were literally no 256-bit
ciphers in the RFC2440 suite. Symmetric ciphers were all 128-bit
(except arguably for 3DES, where the size is wonky[*]). The first
256-bit cipher to be added was Twofish in mid-2000 in PGP 7, followed
soon by AES in PGP 7.1.


[*] 3DES can credibly be claimed to have a 192-bit key, a 168-bit key,
or a 112-bit key, depending on how the speaker defines "key".

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Why is Blowfish's key size limited to 128 bits in RFC 4880? [ In reply to ]
>> What's the rationale behind not going full 448 or at least 256 like
>> AES and Twofish?
>
> Age. At the time Blowfish was adopted there were literally no 256-bit
> ciphers in the RFC2440 suite. Symmetric ciphers were all 128-bit
> (except arguably for 3DES, where the size is wonky[*]). The first
> 256-bit cipher to be added was Twofish in mid-2000 in PGP 7, followed
> soon by AES in PGP 7.1.
>
>
> [*] 3DES can credibly be claimed to have a 192-bit key, a 168-bit key,
> or a 112-bit key, depending on how the speaker defines "key".
>
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users@gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users
>
Thanks, I appreciate the quick response.

I've been using Blowfish on older machines for years now without issue and
I always wondered if this is one of those things that could possibly
benefit from an update.

Best regards.


_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Why is Blowfish's key size limited to 128 bits in RFC 4880? [ In reply to ]
On Sat, 10 Oct 2020 03:00, Dieter Frye said:

> I've been using Blowfish on older machines for years now without issue and
> I always wondered if this is one of those things that could possibly
> benefit from an update.

Nope. I used Blowfish back then because it was the only free and modern
algorithm. PGP didn't support it. Later, in 1998 we added Twofish and
had to do a clean room implementation (kudos to Matthew Skala) because
it was not clear whether the implementaion was in the PD or compatible
with the GPL. I asked Bruce Schneier during this period several times
on whether he would suggest to use Twofish for OpenPGP and his answer
depended a bit on his current mood.

Anyway, all these cipher algorithm competition is mood since everyone
has agreed to use AES; formerly known Rijndael which may have even been
preferred over Twofish because of its non-US origin.


Salam-Shalom,

Werner

--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
Re: Why is Blowfish's key size limited to 128 bits in RFC 4880? [ In reply to ]
> On Sat, 10 Oct 2020 03:00, Dieter Frye said:
>
>> I've been using Blowfish on older machines for years now without issue
>> and
>> I always wondered if this is one of those things that could possibly
>> benefit from an update.
>
> Nope. I used Blowfish back then because it was the only free and modern
> algorithm. PGP didn't support it. Later, in 1998 we added Twofish and
> had to do a clean room implementation (kudos to Matthew Skala) because
> it was not clear whether the implementaion was in the PD or compatible
> with the GPL. I asked Bruce Schneier during this period several times
> on whether he would suggest to use Twofish for OpenPGP and his answer
> depended a bit on his current mood.
>
> Anyway, all these cipher algorithm competition is mood since everyone
> has agreed to use AES; formerly known Rijndael which may have even been
> preferred over Twofish because of its non-US origin.
>
>
> Salam-Shalom,
>
> Werner
>
> --
> Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
>
Interesting.

My current understanding of the situation is that there are no known
effective attacks against Blowfish so long as it's adequately implemented
according to the suggested specifications and it's relatively limited
block size accounted for, and I naturally tend to gravitate towards
tested-and-tried, reliable things with a more or less impeccable record.

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.

Personally I use Twofish on my P4 and Blowfish on all of my P3's.

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.

Best regards.



_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Why is Blowfish's key size limited to 128 bits in RFC 4880? [ In reply to ]
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


_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Why is Blowfish's key size limited to 128 bits in RFC 4880? [ In reply to ]
> My current understanding of the situation is that there are no known
> effective attacks against Blowfish so long as it's adequately
> implemented according to the suggested specifications and it's
> relatively limited block size accounted for, and I naturally tend to
> gravitate towards tested-and-tried, reliable things with a more or
> less impeccable record.

Then you really ought be using 3DES, which is the most heavily
scrutinized symmetric algorithm in OpenPGP. AES is a close second.

> 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.

Which situations are those?

> 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.

In a word, 'no'. In three, 'oh *hell* no'.

The best attack on 3DES, after more than 40 years of academic research,
requires ~10^17 bytes of RAM and ~10^34 encryptions. That's 100
petabytes of RAM, which is silly enough already. 10^34 encryptions,
each of which requires a minimum of erasing ~10^3 bits of data during
its evolution through S- and P-boxes, and the laws of physics flat
*require* losing about 10**-22 joules per erasure... you're talking
about liberating 10**15 joules as heat. That's about what a nuclear
bomb puts out.

And that's for 3DES, which is generally believed to be by far the
*worst* cipher in OpenPGP.

Why would anybody break ciphers the hard way with cryptanalysis, when
real-world systems are so easily exploitable and the human beings behind
them even moreso?

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Why is Blowfish's key size limited to 128 bits in RFC 4880? [ In reply to ]
> 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
>
>
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users@gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users
>
Ultimately it comes down to what the goal of the OpenPGP standard is
supposed to be. It's pretty obvious they don't rush into new things just
because, and are generally conservative when it comes to considering
allegedly stronger ciphers such as Serpent simply because preserving
interoperability with less powerful hardware is non-negotiable to a
degree. But Blowfish is a different animal: It's already in and stands
remarkably efficient irrespective of key size.

To me, allowing for Blowfish to be implemented at full strength would
simply extend it's utility (particularly when it comes to legacy systems)
throughout the steadily approaching quantum era.


_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Why is Blowfish's key size limited to 128 bits in RFC 4880? [ In reply to ]
>> My current understanding of the situation is that there are no known
>> effective attacks against Blowfish so long as it's adequately
>> implemented according to the suggested specifications and it's
>> relatively limited block size accounted for, and I naturally tend to
>> gravitate towards tested-and-tried, reliable things with a more or
>> less impeccable record.
>
> Then you really ought be using 3DES, which is the most heavily
> scrutinized symmetric algorithm in OpenPGP. AES is a close second.
>
Unfortunately 3DES did not survive said scrutiny in the end, thus it's
being phased out as we speak, and while far from broken, it could
theoretically be weakened to such an extent it would not longer be safe in
the foreseeable future.

>> 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.
>
> Which situations are those?
>
My P3 class-powered servers performing a variety of cryptographic
operations on relatively large files (we get anything from 30 to 60 MiB
pdf's on a regular basis and if I were to use Twofish for any of it... not
practical)

>> 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.
>
> In a word, 'no'. In three, 'oh *hell* no'.
>
> The best attack on 3DES, after more than 40 years of academic research,
> requires ~10^17 bytes of RAM and ~10^34 encryptions. That's 100
> petabytes of RAM, which is silly enough already. 10^34 encryptions,
> each of which requires a minimum of erasing ~10^3 bits of data during
> its evolution through S- and P-boxes, and the laws of physics flat
> *require* losing about 10**-22 joules per erasure... you're talking
> about liberating 10**15 joules as heat. That's about what a nuclear
> bomb puts out.
>
> And that's for 3DES, which is generally believed to be by far the
> *worst* cipher in OpenPGP.
>
Sooner or later something's bound to happen that could render current
technology obsolete, so it's better to err on the safer side.

> Why would anybody break ciphers the hard way with cryptanalysis, when
> real-world systems are so easily exploitable and the human beings behind
> them even moreso?
>
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users@gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users
>
Convenience. If you break one, you've broken them all.


_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Why is Blowfish's key size limited to 128 bits in RFC 4880? [ In reply to ]
> Unfortunately 3DES did not survive said scrutiny in the end...

It absolutely *has* survived scrutiny. I don't know where you're
getting your information. 3DES is being phased out because its 64-bit
block size makes it dicey for modern bulk encryption, and because its
spectacular overdesign makes it very slow.

That's it. Nobody has come up with any kind of meaningful cryptanalytic
attack against it. It simply doesn't exist.

> My P3 class-powered servers performing a variety of cryptographic
> operations on relatively large files (we get anything from 30 to 60 MiB
> pdf's on a regular basis and if I were to use Twofish for any of it... not
> practical)

Very practical. You could practically use 3DES on these files. 60MB is
nothing: you're going to experience more slowdown writing to disk.

> Sooner or later something's bound to happen that could render current
> technology obsolete, so it's better to err on the safer side.

In that case, why not also work on defending against time travel,
psychic phenomena, or aliens from Zarbnulax?

The moment you say "it doesn't matter what the science says," you open
the door to some very reasonable questions about why you're defending
against one not-rooted-in-science attack and not others.

>> Why would anybody break ciphers the hard way with cryptanalysis, when
>> real-world systems are so easily exploitable and the human beings behind
>> them even moreso?
>
> Convenience. If you break one, you've broken them all.

No, that's not how cryptanalysis works, either. Cryptanalysis works by
reducing the amount of work to be done: only in rare cases will it
totally erase the work factor. A massively profound cryptanalytic
attack on AES128 would reduce the work factor to, oh, call it 2**80;
that result would be *seismic*.

But 2**80 ain't easy, either. You still have to do an awful lot of hard
work and pay a really huge utility bill.

Why do it this way? Why not go after the data in a non-cryptanalytic
way, where the work factor is so much less?


_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users