On 21/01/16 12:32, Lachlan Gunn wrote: > The first reason is that you can't do it if the key only exists on a > smart card.
I'd say that's a bad idea anyway. What if the smartcard breaks? > The second is that you now have to do one decryption per > message, so if the key is on a smartcard then it becomes more > time-consuming to compromise the whole database, but this is kind of > marginal, I admit. I don't understand. The log with session keys requires one smartcard decryption to decrypt the whole log. The old private subkey requires one smartcard decryption to decrypt the material, and then one "computer" decryption per item encrypted to it, so it takes more time. Also, we're talking about compromise, but instead of measuring the amount of time it takes to crack something, we're talking about the amount of time it takes to do regular crypto? That seems silly, is the only attacker in your threat model using a Commodore 64 or other homecomputer from the 80's to access your encrypted material? > You can safely put the database on Dropbox or something because it > contains the same information as in the encrypted messages, just with a > different recipient effectively. Effectively, the same goes for the encrypted old subkey, AFAICS. Both hold a session key encrypted to the new subkey, and a symmetrically encrypted payload that serves to decrypt all your old data. This symmetric encryption is the same as used on the encrypted messages, so if it's not trustworthy, you're in trouble anyway. HTH, Peter. PS: One way to broadly approximate the "there is no other copy of this key" behaviour of a smartcard is: Buy two smartcards, use both regularly so you quickly notice one dying. Put the key on both, and also encrypt a copy of the key to itself, store the encrypted copy somewhere. When one smartcard breaks, buy a new one immediately. Take a secure system, use the other smartcard to decrypt the key and install it on the new smartcard. For a secure system, you can install a fresh copy of an operating system and thoroughly scrub it with itself afterwards. I think it's fun to watch an OS overwrite itself! Firmware-based exploits remain a problem, though. But I'm rapidly going into a wholly different topic. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at <http://digitalbrains.com/2012/openpgp-key-peter> _______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
