Blowfish: sign extension bit issue (UTF encoding)

[rdunklau]

There is a bug regarding the sign extension bit in the blowfish implementation. The current implementation doesn't take care of this case.

You can reproduce it with the attached "showBug.js" file.

The blowFish.js file contains the correction.

Basically , you have to take the charcode % 256 before encrypting :

for(var i=0; i<count; i++){
			o.left=(plaintext.charCodeAt(pos) % 256)*POW24 
				|(plaintext.charCodeAt(pos+1) % 256)*POW16
				|(plaintext.charCodeAt(pos+2) % 256)*POW8
				|(plaintext.charCodeAt(pos+3) % 256);
			o.right=(plaintext.charCodeAt(pos+4) % 256)*POW24
				|(plaintext.charCodeAt(pos+5) % 256)*POW16
				|(plaintext.charCodeAt(pos+6) % 256)*POW8
				|(plaintext.charCodeAt(pos+7) % 256);

And correct the charcode after decrypting :

//convert to string
return dojo.map(pt, function(item){
   if(item > 127){
      item = 65536 - 256 + item;		
   }
   return String.fromCharCode(item);
}).join("");	//	string

[rdunklau]

"Patched" BlowFish?.js file

[rdunklau]

A simple test case

[Tom Trenka]

Does this change/patch pass the test vectors that are public domain? See the Bouncy Castle code base...

[rdunklau]

Sorry, but i did not found the test vectors. Could you tell me a bit more ? Thanks ! (And sorry again for being so late... )

[Tom Trenka]

Realizing that this fix assumes non-ASCII characters, and the original implementation (as with all of the other crypto/digest implementations) are only supporting ASCII at the moment.

Going to defer this to at least 1.4, or when we add full unicode support to all of the crypto/digest algorithms, for consistency.

[Tom Trenka]

Deferring to 1.5; have not had the chance to go through and implement UTF encoding for any of the digests or crypto algorithms yet.

[Tom Trenka]

...and again deferring this to 1.6, because of the accelerated release schedule for 1.5.

[bill]

(sadly) punting seemingly abandoned ticket and meta tickets to future

[Colin Snover]

1.8 has been tagged; moving all outstanding tickets to next major release milestone.

[Tom Trenka]

Given the age of these tickets and the small nature of them, I'm marking all as won't fix. #1395 was somewhat addressed with the implementation of SHA2 in DTK 1.8.