Hello there. I'd like to make a feature request; that larger key sizes for the current implementation of the Blowfish cipher (asymmetric or otherwise) be made available to the user through a switch (e.g. "--blowfish-key-size"), naturally along with the mandatory warnings in regards to potential compatibility issues.
The rationale behind this is as follows: *IF* recent developments in quantum computing are anything to go by, the writing may very well be on the wall for 128bit key ciphers, so rather than leaving a tested and tried, competent-still legacy cipher with an excellent cryptanalytic record like Blowfish to die out by lack of use (save for backwards compatibility), maxing out the key size to the cipher's complete potential could easily redeem it from further obsolescence. Surely it's block size could prove detrimental under certain circumstances (and that's why we get Twofish), but if a person understands it's limitations and knows what he's doing, this is a non-issue, just like with any other cipher.
The other side to the story has got to do with performance. Without going into a lot of superfluous details, we're running GnuPG on military-grade Pentium III hardware from the late 90's and we've been doing so since roughly the same period (2001-2002), and that without issue, but a number of tests we ran years ago placed 448bit Blowfish encryption/decryption times only marginally above its 128bit counterpart, whereas Twofish's caused our networked, crypto ecosystem to almost come to halt under relatively heavy load, a thing not so unusual (At one point we also resolved to stick to ciphers for which specialized hardware is not widely available, but that's something best left undiscussed for the sake of both pertinence and brevity). Furthermore, we didn't test any other key sizes such as 576bit because our chief programmer had to leave (some of us have what I'd call "superficial knowledge" of C because of our backgrounds in IT, but when it comes to something as sensible as crypto, trying to come up with our own solution has "bad idea" written all over it, hence the request).
Finally, I think it's worth mentioning that the aforementioned capability is already part of libgcrypt (we're specifically shooting for 448bit, which would effectually amount to an "everlasting" utility for all intents and purposes) and that no suggestion is actually being made for the upgrading of the OpenPGP standard, but rather that we may be allowed to "tweak" this one particular aspect of the one cipher in GnuPG not currently operating in its full strength.
Thank you all for reading this and sorry if I've caused you to waste any of your time.
Best regards.