lloyd at randombit.net
Tue Jul 6 10:31:55 EDT 2010
On Tue, Jul 06, 2010 at 09:57:41AM -0400, jonny ram wrote:
> 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.
Raw is dangerous but it's precisely there for this kind of situation -
where you need an escape hatch out of the standard encodings to deal
with another system that is doing something weird.
> 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.
This was my assumption (since it doesn't looke like JCT and botan
share any common formats for transferring keys otherwise). But I'm
thinking perhaps d itself is not of a form that JCT can deal with.
Instead of get_d(), give it the result of (get_p()-1)*(get_q()-1)
as the private key.
More information about the botan-devel