Blowfish

#1

Hi Jules et al,

I’ve been looking at Juce’s BlowFish implementation, and have a little question :slight_smile: 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:

uint32 hi=0x123123; uint32 lo=0x321321; BlowFish bf((uint8*)"ABCDE", 5); bf.encrypt(hi, lo); sprintf(resultstring, "%X%X", hi, lo);

vs. (Paul Kochers):

uint32 hi=0x123123; uint32 lo=0x321321; BLOWFISH_CTX ctx; Blowfish_Init (&ctx, (unsigned char*)"ABCDE", 5); Blowfish_Encrypt(&ctx, (unsigned long*)&hi, (unsigned long*)&lo); sprintf(resultstring, "%X%X", hi, lo);

Am I missing something, or should these yield identical results??!

Thanks!
graf.

#2

Hmm - interesting!

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.

#3

Hi,

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…

Cheers :slight_smile:

#4

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…?

#5

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.

#6