Erik Norgaard wrote:
Charles B Cranston wrote:
Doing it the hard way requires roughly 1.5 times key length number of modular multiplies (assuming about half the bits are ones and half zeroes) so if the shortcutted public key operation takes 17 units of time the non-shortcutted private key operation takes about 1500 (assuming a 1000 bit key).
Does this also apply to the old style keys or only in case of CRT type keys? Because, then, in any case I will have that problem when using the public key.
Not sure what you mean by old style and/or CRT type keys. If you have a public key with an exponent other than 65537 the public key operation may take longer, but I don't think that is within PKIX standards (other than 3 which does not take longer).
Also consider: what happens in the future when you want to move to a 2048 or 4096 bit key? Do you have to wait for a more capable Java card to be marketed?
The JavaCard supports RSA 2048 bits, and as of version 2.2 there is support of ECC up to 192 bits, but only for signature.
Yes, but I was considering your original problem of getting both the key and the data to be encrypted into the 245 byte buffer. As the key gets longer this problem becomes more stringent.
I have a 2.1 card, but it is my intention not to predefine specific key types or lengths, these are chosen when the key is generated, such that newer card will support the new algorithms.
The main problem as I see it is that for things to work, the input buffer must grow as longer keys are used or I must support sessions.
Watch out for elliptic curve because a "message" usually takes sending TWO group elements, instead of just one as for RSA. This makes the message length twice as long as you otherwise might imagine. If you're just coding a session key for the real data this increase is minimal, but for the kind of embedded computation you're thinking of this can be a real gotcha.
I have only been introduced to ECC, twice as long encrypted output is ok, the problem seems to be with decryption, then I might run out of space. Thanks for the info!
Actually this is more El Gamal vs RSA than the elliptic group vs the integer group, but it turns out that RSA on the elliptic group is not very much harder than on the integer group, so you DON'T get the same protection with a much shorter key. But if you use El Gamal you need to send two group elements, so the message size doubles compared to RSA in which only one group element needs to be sent.
Hope all this helps!
-- "An Internet-connected Windows machine is tantamount to a toddler carrying a baggie of $100 bills down a city street..."
Charles B (Ben) Cranston mailto: [EMAIL PROTECTED] http://www.wam.umd.edu/~zben
______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
