Information Security Stack Exchange is a question and answer site for information security professionals. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I get the following error if I give a key that is greater than 64 hex caracters (64*4=256 bits).

enter image description here

According to this official document, blowfish is able to support key from 32 to 448 bits.

Variable key length: 32 bits to 448 bits

Is it possible to bypass this limitation? What's wrong?

The actual key size is big enough, but I would like to have the most security as possible.


share|improve this question
While not an answer to your question, reading this might make you feel a bit better about 256-bit: – lynks Dec 13 '12 at 16:17
Any reason you're not using TwoFish? Same low footprint, no patents, but more secure and more commonly used. – Polynomial Dec 13 '12 at 16:21
If you want maximal security, why are you using Blowfish instead of a modern cipher, like AES or Threefish? – CodesInChaos Dec 13 '12 at 16:22
@CodesInChaos I actually trust Twofish more than Threefish, considering the difference in success that has been had in cryptanalysis of both algorithms. +1 on AES though. – Polynomial Dec 13 '12 at 16:33
up vote 2 down vote accepted

For OpenSSL's command-line program (openssl enc), the algorithm chosen also picks the key size (which is why they have separate options for aes-128, aes-192 and aes-256). They just don't have this option for Blowfish.

The enc program only supports a fixed number of algorithms with certain parameters. So if, for example, you want to use RC2 with a 76 bit key or RC4 with an 84 bit key you can't use this program.

openssl enc -bf always uses a 128 bit key:

Blowfish and RC5 algorithms use a 128 bit key.

The documentation for the Blowfish functions says you can use a variable-length key, so presumably if you wrote your own program compiled against OpenSSL, you could use whatever key size you want:

BF_set_key() sets up the BF_KEY key using the len bytes long key at data.

If you can choose your algorithm, and you want a longer key for whatever reason, OpenSSL will do AES with up to 256-bit keys: (openssl enc -aes-256).

Given the above, you'd expect OpenSSL to complain when you go over 32 character (32 * 4 = 128), but it seems to silently ignore any data after the first 32 characters:

blong@ubuntu:~$ openssl enc -bf -iv 0 -P -K 000000000000000000000000000000012345
iv =0000000000000000

I submitted a bug report, because it looks like they're trying to catch this case, but the error is for > 128 characters instead of > 128 bits.

share|improve this answer
Thanks for your answer, as you said, they should raise an error if the key is greater than 128 bits. I checked by giving a 32 or 33 cars key and the result is exactly the same. The key is then truncated at the 32th car. – Jonas Dec 14 '12 at 8:33

There is no better security than "cannot break it now, cannot break it in 40 years either". 128-bit keys already offer this level of security. You will not get "more security" by using larger keys. You will just get larger keys.

(Keys larger than 128 bits exist mostly to quiet inflexible administrative structures who feel insecure in their collective manhood.)

share|improve this answer

I understand the math behind key bit-lengths but recent reesearch is making me start looking at longer keys. Clusters using GPUs to speed computations are already hitting hundreds of billions of keys per second. 128-bit keys are still enough today (probably) but their time is growing short.

share|improve this answer
It will take several decades at minimum until a state level attacker can break 128 bit keys. But going beyond 256 bits is pretty meaningless. No classical computer will ever brute-force 256 bit keys. – CodesInChaos Dec 28 '12 at 21:27

Above 128 bits in unnecessary. With 128 bits there are 2^128 possible keys, divided by 100 billion tests per second (which would require a formidable GPU farm) and it would take someone 7.8*10^9 times the age of the universe to crack it (about 10^20 years).

But in all seriousness I do wonder why there is a limit on the size of the key.

share|improve this answer
Completely correct, thanks for the maths, I didn't think it will take so much time to enumerate all the possibilities. But we never know, maybe my program will still be used by some aliens in another world ;-) Cheers – Jonas Mar 19 '14 at 7:44

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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