Closed GoogleCodeExporter closed 9 years ago
It turns out that the Python and Java implementations generates keys with an
additional msb set to 0, that is keys are padded on the left with \x00.
While the Python implementation tolerates keys without this additional byte,
Java implementation raises javax.crypto.BadPaddingException: Message is larger
than modulus
Below is attached a script which should help converting previously generated
C++ keysets to Java "compatible" keysets. Only RSA and DSA keysets need to be
converted.
Additionally the C++ implementation needs to be fixed to generate keys with the
same format than others implementations. Note that this modification will still
work with previously generated C++ keysets, but they won't be converted
automatically.
Original comment by sebastien.martini
on 19 Jun 2010 at 12:38
Attachments:
Original comment by sebastien.martini
on 19 Jun 2010 at 4:53
I ran the convert_keyset.py, and it fixes some issues. I can now use the
keyset to encrypt in java, however I cannot use it to decrypt in java. I
verified I can encrypt in java and use that output to decrypt in c++ and
python, but when attempting to decrypt in java I get:
Exception in thread "main" java.lang.ArithmeticException: BigInteger: modulus
not positive
at java.math.BigInteger.modPow(BigInteger.java:1548)
at sun.security.rsa.RSACore.crtCrypt(RSACore.java:137)
at sun.security.rsa.RSACore.rsa(RSACore.java:84)
at com.sun.crypto.provider.RSACipher.a(DashoA13*..)
at com.sun.crypto.provider.RSACipher.engineDoFinal(DashoA13*..)
at javax.crypto.CipherSpi.a(DashoA13*..)
at javax.crypto.CipherSpi.engineDoFinal(DashoA13*..)
at javax.crypto.Cipher.doFinal(DashoA13*..)
at org.keyczar.RsaPrivateKey$RsaPrivateStream.doFinalDecrypt(RsaPrivateKey.java:183)
at org.keyczar.Crypter.decrypt(Crypter.java:168)
at org.keyczar.Crypter.decrypt(Crypter.java:84)
at org.keyczar.Crypter.decrypt(Crypter.java:184)
Thanks
-Cory
Original comment by g.co...@gmail.com
on 19 Jun 2010 at 5:19
Ooops try this version instead this should be better.
Original comment by sebastien.martini
on 19 Jun 2010 at 6:43
Attachments:
The last convert_keyset.py works great. All my test cases passed with new
converted keysets. Thanks Sebastien!
-Cory
Original comment by g.co...@gmail.com
on 20 Jun 2010 at 5:35
Great, I've just committed these changes of format to the C++ implementation
itself, see http://code.google.com/p/keyczar/source/detail?r=466
Original comment by sebastien.martini
on 20 Jun 2010 at 7:29
Of course, report if you observe any remaining problem or regression
encountered with these changes.
Otherwise I'll close this issue.
Original comment by sebastien.martini
on 20 Jun 2010 at 7:54
This issue was the result of different binary representations of big integers
in Java and OpenSSL. Java uses one additional byte to represent value's sign (0
when positive), OpenSSL serializes absolute values thus doesn't need this byte.
Therefore C++ and Python implementation just prepend a null byte to their
binary keys.
Next is a quick summary about how developers could be affected by this issue
and what steps they should take to resolve it:
- C++ users have to convert [1] their RSA/DSA keysets generated from old
versions (<r466) of Keyczar C++ if they plan to use these keysets from the Java
implementation of Keyczar.
- C++ users should upgrade their version of Keyczar C++ (with a version whose
revision is >=466) in order to generate new keys with a format compatible with
C++/Java/Python versions of Keyczar. Moreover old keysets even if not
explicitly converted will still be working with this new C++ implementation.
- Old C++ keysets work with Python implementation.
[1]
http://code.google.com/p/keyczar/source/browse/trunk/cpp/src/keyczar/keyczar_too
l/convert_keyset.py
Original comment by sebastien.martini
on 21 Jun 2010 at 11:45
Original comment by sebastien.martini
on 24 Jun 2010 at 11:59
Original issue reported on code.google.com by
sebastien.martini
on 19 Jun 2010 at 12:18