Rabbit cipher implementation incompatible with eSTREAM test vectors
GoogleCodeExporter opened this issue · 3 comments
GoogleCodeExporter commented
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:
GoogleCodeExporter commented
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 commented
> 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 commented
Fixed in r556.
Original comment by Jeff.Mott.OR
on 9 Dec 2012 at 2:55
- Changed state: Fixed