Please belay that last query. With a little more playing today I have successfully implemented GWT TripleDES encrytion of data that is decrypted using dotnet TripleDES.

My findings for others were first that gwt-crypto internally must use a feedback block of the same size as the blocksize (8-byte), PKCS7 padding and an 8-byte & zeroed IV. All of these can be mirrored in dotnet land. Second is that using the encoding objects or inbuilt system frombase64X() methods can muddy the data when deriving key & value byte arrays. However, by checking out and following the same hex encoding and decoding algs as defined within gwt-crypto, the data will marry up nicely (not tested over large data sets yet).

So, cheers on a great gwt library =)
Jon

Following up on your release of gwt-crypto from the other day, I’ve had a play and run into an issue you may be able to help with. Its regarding interoperability with the dotnet TripleDES implementation.

Can you tell me about the feedback incorporated when performing the encryption/decryption? MS enforces a minimum feedback block size for its implementation (8-bits by default), so if I know what size you used in your implementation then I can hopefully align the two. The reason I ask about feedback is that I’ve looked at the exposed dotnet 3DES properties and the defaults as implemented in the source of gwt-crypto – and feedback is one I’m unsure about.

From what I can see, the IV is 64-bits of zeros by default; which I can emulate in dotnet land. I can ensure that the keys are (reported to be in Intelli-J and VS) identical. Both gwt-crypto and dotnet 3DES support the PKCS7 padding format, so the last property I can see that can be manipulated to align between the two seems to be the feedback block size.

Also, if you have any other notes on interop between gwt-crypt and dotnet world’s 3DES implementations, I’d be appreciative.

Thanks,
Jon

Yes, that makes a lot of sense. Thanks for the explanation!