<div>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.</div>

<div> </div>
<div>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:</div>

<div> </div>
<div>rsa.privateKey(n, i2ba(65537), d, 1024);</div>
<div>//first three parameters are byte arrays and the last is an integer</div>
<div> </div>
<div>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.</div>

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