search

wokier / gwt-crypto

Automatically exported from code.google.com/p/gwt-crypto
8 stars 1 forks source link

RSA not compatible with standard Java 1.6 crypto #14

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
1. Encode string using gwt-crypto.
2. Attempt to decode using Java 1.6 crypto (Cipher.getInstance("RSA"))

What is the expected output? What do you see instead?
Expect to see string encoded using gwt-crypto. Instead, get garbage.

What version of the product are you using? On what operating system?

gwt-crypto-2.3.0-20110518.123759-2, on Windows.

Please provide any additional information below.

See attached pure Java sample.

Note: we are wanting to encode data in the browser using a public key, and send 
this to the server. At the moment, it is necessary to use gwt-crypto to decode 
on the server instead of standard Java.

Original issue reported on code.google.com by gmcdor...@skura.com on 14 Nov 2011 at 10:38

Attachments:

GoogleCodeExporter commented 9 years ago 
Hi, gwt-crypto is relying on Bouncy Castle (http://www.bouncycastle.org) 
cryptographic libraries, did you try to use these to encrypt your data and then 
decrypt it using Java crypto library? Maybe you could find some information on 
their web pages/support forums/mailing lists. If their implementation works for 
you then there is a bug in gwt-crypto and I'll look into this. On the other 
hand, if there isn't a problem with our implementation and you'll find a way to 
make this work, we would really appreciate if you share your solution with us 
;-)

I have two things (from the top of my head) that could help you:
1. You should use some padding algorithm (eg. PKCS) or make sure you pass the 
same amount of bytes to encryption as length of your key
2. Thats a thing I figured on windows while working with asymmetric encryption. 
Sometimes different crypto providers use different endianess (windows use 
little endian while OpenSSL uses big endian for example) for keys/data so try 
to experiment with that.

But if you look at the sources of RSACipher, you'll see that the implementation 
uses java's BigInteger and the formulas are the very basic ones (as defined by 
the RSA which you can look-up in wikipedia ;-) ) so if there are any 
differences it must be in the way java crypto API is handling the data (which 
probably is much more optimized than just use BigInteger) but there is not much 
to do for us if this is the case. GWT is providing reasonable support for 
modulo-calculus which we won't be rewriting to fit java crypto library needs 
;-).

Original comment by rame...@gmail.com on 21 Nov 2011 at 8:51

GoogleCodeExporter commented 9 years ago 
Thanks. I did look some more at this after posting the bug; it appears that the 
vanilla 1.6 JRE only supports RSA/ECB/PKCS1Padding; trying to get anything else 
results in an exception. Conversely, according to 
http://www.bouncycastle.org/specifications.html all BC providers use an 
encoding style of None (e.g. RSA/NONE/PKCS1Padding).

Bottom line seems to be that it is not possible to get them to interoperate, as 
the providers do not have a compatible encoding mode.

Original comment by gmcdor...@skura.com on 21 Nov 2011 at 9:00

GoogleCodeExporter commented 9 years ago 
Actually you can specify whatever padding/encoding you want to use in Bouncy 
Castle, you just have to create the object graph right (though we do not 
support all that BC supports).

From what I can tell mode NONE and ECB seems fairly similar (no IV, blocks 
processed apart from each other). The PKCS1 encoding is what actually does the 
job of "obfuscating" each transmission with some form of IV but it should be 
compatible. How many blocks are you encrypting? Maybe NONE means you can only 
encrypt one block while ECB menas you can encrypt as many blocks as you want 
but I really don't fully understand what mode means for RSA here...

Original comment by rame...@gmail.com on 22 Nov 2011 at 7:48

GoogleCodeExporter commented 9 years ago 
I also did a little bit of digging in your sample code and found a bug in it, 
you were passing decoded hex data to the GWT crypto decrypt which failed 
because the length of the ciphertext didn't contain enough data. I corrected 
the sample and it works. I suggest that you write a GWT junit test that 
encrypts the data using gwt-crypto (in production mode) then sends it using RPC 
to the server where you try to decrypt it using Java crypto.

Original comment by rame...@gmail.com on 22 Nov 2011 at 8:35

GoogleCodeExporter commented 9 years ago 
And here is the file ;-)

Original comment by rame...@gmail.com on 22 Nov 2011 at 8:36

Attachments: