>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).
ok, maybe I misunderstood you. According to PKCS#1 the public key is a pair (n,e) and the private key can be respresented either as a pair (n,d) or in its Chinese Remainder Theorem form (CRT). The latter should be faster, but only applies for keys with more than two primefactors.
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?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.
Well, a 2048 bit RSA key won't fit, so even now I hit the limit, but I read that 1024bit should be considerd safe till 2037 or something? so I decided to stick with 1024bit. The buffer size is defined in an ISO-standard, so changing this may not be so straight forward as launching a new card.
However, the new version also supports Remote Method Invocation that is an abstraction layer, this may take care of all the transient data stuff :-)
At this point I am developing a proof of concept, not even a prototype. So cutting some corners is ok if I have good reasons, I know where they are and what must be done to uncut them.
I could have been straight naïve and simply assumed that the v2.1 was all I had to consider.
>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!
Absolutely, this is super! Thanks!
Erik
-- Ph: +34.666334818 web: http://www.locolomo.org S/MIME Certificate: http://www.locolomo.org/crt/2004071206.crt Subject ID: A9:76:7A:ED:06:95:2B:8D:48:97:CE:F2:3F:42:C8:F2:22:DE:4C:B9 Fingerprint: 4A:E8:63:38:46:F6:9A:5D:B4:DC:29:41:3F:62:D3:0A:73:25:67:C2 ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
