Erik Norgaard wrote:
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.
Oh, I see, you use CRT to designate the key with the added speedup data. Yes, the Chinese Remainder Theorem is the speedup. But I believe it IS used for keys with only two prime factors, which is the usual case? Am I misunderstanding your terminology? The standard def for RSA is ( cleartext ^ E ) ^ D == cleartext mod p*q where D x E is 1 mod phi(p*q) I see only two primefactors: p and q.
Over ten years ago I wrote an assembly language implementation of this (heavily cribbed from the RSAREF C) in which I used the CRT speedup. And I was getting a significant speedup from the CRT algorithm, and I only had two prime factors.
There is a paper
High-Speed RSA Implementation, TR 201 November 1994 (Acrobat .PDF, 497k)
at http://www.rsasecurity.com/rsalabs/node.asp?id=2002
(last paper at bottom of page).
In general the stuff at the RSA Labs site is pretty good quality.
====
I am interested in your opinion of my idea about securely implementing a "session" protocol (as you put it). It seems to me that one could use an arbitrary number of transactions to put the key and data into the device, as long as they are masked with a session key. Even if the device is removed prematurely, the adversary can gain no advantage from any information input up to the point of the last operation.
The last operation would be a "do it now" code with the session key. It seems to me this is just about as secure as your idempotent one-transaction model?
-- "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]
