Rotating encryption keys

[Lachlan Gunn]

>
> I'd say that's a bad idea anyway. What if the smartcard breaks?
>

Then you rotate to the new key with little or no data loss because all of
the session keys are logged.  You can generate the key on-chip so that it
is unable to ever leave the smartcard, which is obviously desirable from a
security point of view.


> 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?
>

I was suggesting that rather than having one big encrypted file with all
the session keys, you public-key reencrypt each one as you decrypt it and
then add it to the log.  Putting the entire log under the same symmetric
key is problematic because then you need to decrypt it every time you
receive a message.

As far as performance, yes, it's marginal, as I said originally.  But if
you have thousands of messages to decrypt using only a slow smartcard,
maybe it will make a difference.

The reason for separately doing each using public-key crypto is that you
can add keys to the log without having the log's decryption key available.

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.
>

Yes, you're right, actually, I failed to account for the extra entropy
involved over the passphrase-encrypted version.

Thanks,
Lachlan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20160121/9cf80268/attachment.html>