Rabbit cipher implementation incompatible with eSTREAM test vectors

[GoogleCodeExporter]

The endian-ness (in 32-bit chunks) of either the IV or the key is wrong (I 
cannot be sure which, because I am not sure exactly how you intended 
CryptoJS.enc.Hex.parse() to work).

See the attached HTML file with included script generated from the published 
test vectors available at URL 
http://www.ecrypt.eu.org/stream/svn/viewcvs.cgi/ecrypt/trunk/submissions/rabbit/

What version of the product are you using? On what operating system?
CryptoJS v3.0.2 (running in Firefox under Linux)

I don't know exactly what you should do about it, since fixing it could break 
existing projects using your code. But you should at least document this, 
somewhere (and possibly provide a second, compatible, version of Rabbit).

Original issue reported on code.google.com by ronkamin...@gmail.com on 29 Nov 2012 at 11:44

Attachments:

• testCJS.manual.html

[GoogleCodeExporter]

Looks like you're right. A detail I missed in the test vector documents is that 
the keys, IVs, and outputs are all little-endian. The endianness shouldn't 
affect the security of the cipher, but of course it does affect the 
compatibility. I'll definitely implement the fix, and I'll likely rename the 
current implementation to "rabbit-legacy", or something along the lines, for 
people who still need the existing behavior.

Original comment by Jeff.Mott.OR on 3 Dec 2012 at 8:41

• Changed state: Accepted

[GoogleCodeExporter]

> A detail I missed in the test vector documents is that the keys, IVs, and 
outputs are all little-endian.

What is much more important to fix, is that you seem to have used the key and 
the IV with *different* endian-nesses. (Sorry to repeat, but your comment 
didn't make it obvious that you noticed this part of my report).

Original comment by ronkamin...@gmail.com on 3 Dec 2012 at 11:25

[GoogleCodeExporter]

Fixed in r556.

Original comment by Jeff.Mott.OR on 9 Dec 2012 at 2:55

• Changed state: Fixed