I’ve been looking at Juce’s BlowFish implementation, and have a little question Should all blowfish implementations yield the same results with the same input? I tried comparing the Juce BlowFish class with Paul Kocher’s implementation (from counterpane.com), and also libtomcrypt, but all three seemed to yield different results with the simple test of:
I suppose they should all be the same, but maybe there are subtle differences in the arithmetic - maybe signed/unsigned stuff happening.
One idea - are you sure that the hi and lo values are being used the same way round by each version? I think mine treats them as ‘left’ and ‘right’, so maybe they’re reversed.
I tried swapping the hi and lo, but still different results -
I’ll dig a bit deeper and see if I can get to the bottom of it. Interestingly, the libtomcrypt implemention wont allow keys <8 bytes, so maybe the kochers implementation has some similar restriction and is padding the key…
After further investigation I’m getting matching results from libssl and the reference implementation (and libtomcrypt with keys > 8 bytes), but I can’t see where the Juce blowfish is differing. I suspect it’s something simple in the generation of the inital state, or the loading of the key - all implementations use 16 rounds to init the state, but as juce uses a 2d array to hold the state I couldn’t really compare the init functions of one vs. another. Sorry I can’t be of more help - actually the Juce imp may be fine with larger keys, I noticed it was padding the key with zeros whilst loading the key, so maybe with larger/unpadded keys it would be ok… maybe the other imps use pkcs5 or something to pad the keys…?
Yeah - the key-padding sounds like a likely culprit, because I did test it against the reference implementation when I wrote it, and was almost certainly using big keys. I’ll have to take a look at how the others do their key generation.