© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
73416ba
(Get the code!)
I blush to admit that it is wikipedia that shed light on why we see 72-byte implementations. Oh, the shame.
>>
Because the P-array is 576 bits long, and the key bytes are XORed through all these 576 bits during the initialization, many implementations support key sizes up to 576 bits. While this is certainly possible, the 448 bits limit is here to ensure that every bit of every subkey depends on every bit of the key[2], as the last four values of the P-array don't affect every bit of the ciphertext. This point should be taken in consideration for implementations with a different number of rounds, as even though it increases security against an exhaustive attack, it weakens the security guaranteed by the algorithm. And given the slow initialization of the cipher with each change of key, it is granted a natural protection against brute-force attacks, which doesn't really justify key sizes longer than 448 bits.
>>
And Mr. Schneier has this to say:
>>
Function F, the non-reversible function, gives Blowfish the best possible avalanche effect for a Feistel network: every text bit on the left half of the round affects every text bit on the right half. Additionally, since every subkey bit is affected by every key bit, the function also has a perfect avalanche effect between the key and the right half of the text after every round. Hence, the algorithm exhibits a perfect avalanche effect after three rounds and again every two rounds after that.
>>
and
>>
The number of rounds is set at 16 primarily out of desire to be conservative. However, this number affects the size of the P- array and therefore the subkey-generation process; 16 iterations permits key lengths up to 448 bits.
>>
and
>>
The subkey generation process is designed to preserve the entire entropy of the key and to distribute that entropy uniformly throughout the subkeys.
>>
and
>>
The 448 limit on the key size ensures that the every bit of every subkey depends on every bit of the key. (Note that every bit of P15, P16, P17, and P18 does not affect every bit of the ciphertext, and that any S-box entry only has a .06 probability of affecting any single ciphertext block.)
>>
Which means 72-byte keys had been rejected by the author of the algorithm. They also aren't "the end of the world, this will be cracked" - it makes the algorithm a little less secure, but it's still not something you could break. Brute-force is silly at 56 or 72 bytes, anyway, which means only algorithmic attacks would be possible. No true weaknesses have been found. Yet, maybe.
I'd say default to 56 bytes and allow 57-72 byte keys by a parameter to be passed - sorry, Eric, that means you'd have to change your backend code or keep changing pycrypto when you use it.
When the parameter to allow longer keys is passed, throw a RuntimeWarning. Would have to see whether that is suppressed by default - if not, maybe a FutureDeprecati