jonniram at gmail.com
Tue Jul 6 09:57:41 EDT 2010
Thank you very much for the help, I'll try this out when I get home and let
you know. I avoided SOAEP after reading that it was non-standard, but wasn't
sure about BitPadding. I thought about using Raw on botan's side, but the
API reference made it seem a bit dangerous. I'll probably try that first
before attempting to modify SOAEP to bring it in line with the standard.
Regarding keys, I actually avoid using any special encoding. The way I am
currently transferring them from C++ to JS is to just get each part of the
key using get_n(), get_d(), etc. Then I base64 them and send them to the JS
side, where I decode them into byte arrays. I construct the private key with
JCT like this:
rsa.privateKey(n, i2ba(65537), d, 1024);
//first three parameters are byte arrays and the last is an integer
When n and d come from Botan, it actually does let me create the object, and
it even lets me do public key encryption with it (though the output could
just be garbage), but when I try private key decryption it actually hangs in
an infinite loop. I'm pretty sure my own JS code is fine because both
operations perform perfectly when n and d are generated by JCT itself.
On Tue, Jul 6, 2010 at 8:16 AM, Jack Lloyd <lloyd at randombit.net> wrote:
> 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
> > uses this for padding:
> > http://ats.oka.nu/titaniumcore/js/crypto/BitPadding.js
> 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
> exponentation code.
> 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
> botan-devel mailing list
> botan-devel at randombit.net
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the botan-devel