On Sat, May 7, 2011 at 6:12 PM, Kenneth Jorgensen <[email protected]>wrote:
> I've been writing a cryptographic library for GWT (available at > https://bitbucket.org/kennethjor/tovikov) and I ran into a few strange > problems when dealing with integers. I will not be able to post code > to reproduce the errors, simply because I wasn't able to do it with > stand-alone code, yet the errors still happened. > > The first error I was getting had to do with integer rotation. I > managed to fix it by implementing my own rotation functions, which can > be found at > https://bitbucket.org/kennethjor/tovikov/src/f49670bd090a/src/main/com/tovikov/util/IntegerUtil.java > . > As mentioned, I wasn't able to reproduce the errors outside of the > library code, but if you want to verify the error, you can check out > the library above, and in the com.tovikov.security.hash, replace all > calls to IntegerUtil.rotateLeft and IntegerUtil.rotateRight with calls > to Integer.rotateLeft and Integer.rotateRight respectively. Then run > "ant webtest" and open up the compiled code in a browser, you will see > that it fails on everything except MD2. > > The second error I wasn't able to reproduce neither, but I was able to > implement a work-around. The error happened when implementing SHA-224 > and SHA-256. On SHA-256 I took the test vectors from FIPS 180-2, and > after applying the fix above, I was able to succeed on a single-block > message, but still failed on the multi-block message given in that > document. I tracked down the error to a failure in iteration 52 when > processing the second block. When calculating t1 (https:// > bitbucket.org/kennethjor/tovikov/src/f49670bd090a/src/main/com/tovikov/ > security/hash/Sha256Hash.java#cl-175) the result is supposed to be > 0xe167f8cb, but came out as 0xe167f8cc. When I took the numbers used > to calculate t1 and tried to calculate it on its own (0x68f25260 + > 0xd6ae79cb + 0x27a50536 + 0x391c0cb3 + 0x41061ab7) I got the right > result, but in the loop for the hash the result wasn't correct. On a > whim I implemented IntegerUtil.forceInt(), which converts the integer > to bytes and then back again, and it all worked. > > I apologise if this is all a bit cryptic, but I have been comparing > hexadecimals for the last 5 hours, and I brain hurts :) > > Hope this is still somewhat useful to the GWT developers. > > Oh, and my GWT version is 2.2.0, not trunk. > I haven't looked at your code in detail, but GWT does not emulate integer overflow, as it would be too expensive since JS only has a single Number type which is an IEEE double. For hash functions and the like which depend on 2s-complement 32-bit math, you need to manually force it to be coerced to a 32-bit value. You can do this with either (x | 0) or ~~x -- see GWT's String.hashCode() emulation for an example. See http://code.google.com/webtoolkit/doc/2.2/DevGuideCodingBasicsCompatibility.html for details. I would be surprised if Integer.rotate* had a problem, but if you can produce a reproduction case for just that we can certainly fix it. BTW, GWT has MD5 built-in already. -- John A. Tamplin Software Engineer (GWT), Google -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
