lloyd at randombit.net
Tue Jul 6 08:16:41 EDT 2010
On Sun, Jul 04, 2010 at 07:54:53PM -0400, jonny ram wrote:
> -JCT cannot decrypt anything encrypted by Botan.
> -Botan cannot decrypt anything encrypted by JCT.
> -JCT cannot use private keys generated by Botan.
> -Botan *can* use private keys generated by JCT.
> So clearly it's not enough that both JCT and Botan support 1024-bit
> RSA, since they may be using different formats for their keys and their
> encrypted messages. On the Botan side, I am creating a PK_Encryptor and
> PK_Decryptor using "EME1(SHA-1)" for padding. On the JCT side, I believe it
> uses this for padding:
The padding is definitely an issue. BitPadding is seemingly
non-standard; I've never seen in before, and the RFC it references
doesn't mention anything about RSA (oh, but thinking about it more,
MD5 uses a 1 followed by trailing zeros padding - I guess the idea is
applying the same thing to RSA...). And the other padding scheme,
SOAEP, is explicitly new/incompatible.
One approach would be to use 'Raw' padding on the botan side, and
explicitly hand encode/decode with the trailing 1/0 bytes. Definitely
using EME1 (==OAEP) will not produce a format BitPadding expects nor
will BitPadding produce something OAEP will accept. Another solution
would be to add standard OAEP to the JS side. Using the BitPadding
scheme for encryption is definitely not ideal - it doesn't randomize
the input, has little redundancy, and a very simple mathematical form
which is especially dangerous with RSA. Unfortunately it does not
appear that JCT offers any sort of escape hatch which would let you
implement your own padding. So perhaps the best solution is to use Raw
on botan's side, and pack your message with a bunch of random bits
that you discard on the decrypting side, using just a trailing 0x10,
0x00 so BitPadding will accept it. (Though it would be much better to
use OAEP, if it's possible for you to modify JCT).
The only obvious thing I can think of why JCT couldn't use botan's RSA
keys is that it looks like JCT uses an older style of generating the
private key. In RSA the decryption key d is e^-1 mod phi(n). Older
definitions used phi(n) = (p-1)*(q-1), but recent standards like PKCS
#1 require instead phi(n) = LCM(p-1, q-1). Since both p and q are
normally prime, p-1 and q-1 are both even, so botan's version of the
key will differ from JCT's by at least a factor of 2, and may make the
key into a form that JCT doesn't expect/understand. I don't actually
see anything that is doing any checking of this, but perhaps somehow
an assumption on what the exponent looks like is made in the modular
You can convert a PKCS #1 style RSA key into something JCT expects.
I've attached an example showing how (function to_jct) plus some tests
showing that the keys are equivalent. (I haven't actually checked that
JCT accepts this key, but it matches the form of the keys it
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 1344 bytes
Desc: not available
More information about the botan-devel