George Gleason says "I believe that carrying out the entire crypto operation in the dongle is preferable to having it only do the secret key RSA processing" and argues for this position mainly on the basis of host compatibility issues. I still disagree. Even if all the crypto operations were done in the dongle, it wouldn't be a "turnkey" device that could operate totally automatically. You'd still need a way for your host computer to turn it off and on, to select a public key for encryption or signature verification, to load new public keys, etc. I.e., you'd have to run special driver software on the host anyway. So why not limit the dongle to the specific purpose for which it was designed (protecting your RSA secret key) and do the less sensitive operations where memory and cycles are far more plentiful, i.e., on the host? Limiting the dongle's function to RSA secret key operations also minimizes the dongle's communication requirements. The only data you'd have to send to it in normal operation would be short blocks to be run through your RSA secret key operation, a heavily compute-bound process. If I want to decrypt a file, I'd send the dongle the IDEA (or DES) key that had been encrypted with my public key. Once the dongle responds with the decrypted IDEA key, I can perform the actual IDEA decryption on my host computer with no further dongle interaction. Regardless of the file size, this would go at host CPU and/or disk speed, not the speed of the port that's talking to the dongle. Similarly for signing -- the MD-5 hashing of the file would proceed at near disk speed (since MD-5 is so fast) and only the resulting hash code would have to be passed to the dongle for the RSA secret key step. A palmtop DOS machine like the HP-95 or Atari Portfolio would make a good platform for a prototype dongle. Most have serial ports (standard or optional), and you could just plug them into a spare serial port on a PC (again, speed is not critical). The palmtop's keypad would be used to control the dongle, e.g., by accepting a pass phrase to decrypt the stored copy of your RSA secret key, so you wouldn't have to type it into a possibly compromised PC. And they're small enough to carry around with you, thus making it harder for somebody to hack. The only drawback I can see to all of this is that palmtops are not exactly speed demons, and RSA secret key operations are pretty slow to being with (much slower than the public key operations, which are less sensitive). But secret key operations are the heart of RSA, so you don't have much choice if you want real security. Since it is a sensitive step, RSA key generation could also be done on the palmtop (although it would probably take hours) or it could be done on an external, trusted PC and loaded into the palmtop. If your main reason for using the dongle is to limit the trust you have to place in a borrowed PC (as opposed to protecting against your own home PC being hacked), this may be a reasonable thing to do. Another idea just occurred to me. If you have a trusted machine (e.g. your home PC) available to you over the net, you could use it as a "remote dongle". You'd send it data to be run through the RSA secret key operation and it would return it. Obviously, to be secure the network exchanges would have to be encrypted in both directions, otherwise anybody could either pick up the "remote dongle's" responses or worse, send it data of his own choosing. A simple symmetric cipher (IDEA, DES) would be adequate here since you control both ends of the link. The main drawback of this approach (other than the need for network connectivity) is the physical vulnerability of your unattended home PC. Phil