Rotating encryption keys

[Lachlan Gunn]

>
> I don't understand, what are the session keys encrypted with? I thought
> they
> were encrypted to the original smartcard subkey, which is dead. With two
> smartcards, you might be able to get by if you get all your correspondents
> to
> use the new subkey before the second smartcard dies. It seems much less of
> a
> problem, though, because you could ask them explicitly to re-encrypt if
> they
> encrypt to the old key.
>

That's one way to do it, the other option is to use some other key that you
have the option to keep offline.


> That construction would have it merits, but it seems complex. Complex
> things in
> crypto are best treated carefully. Or dismissed. All functionality
> introduces
> new places to make mistakes and kill security.


I agree.  If I were implementing it then I'd save it with the same key by
default and, with the option to encrypt to an arbitrary other key.  Then
you can keep it offline if so inclined, or have one common to an
organisation or something.


> Ah! Okay. I'm still not sure what you mean by re-encrypting; it seems you
> could
> just add the OpenPGP Public-Key Encrypted Session Key packet (along with an
> identifier to find it again on use).


Yes, if you're using the recipient's subkey then this is the easiest way.


> That depends on the cipher mode; appending might be cheap. But this is
> academical; your construction seems better.
>

I wasn't as clear as I should have been---I mean the session key gets
decrypted, meaning that an attacker can get access to it in normal
operation.  If you use public-key encryption then the private key doesn't
need to be used except during key transition.


> Also, this means you can append to the log as soon as you see a message,
> rather
> then the first time the user decrypts it. That does, however, introduce the
> problem that you can't verify the correctness of the packet, meaning you
> just
> created a free append-only datastore for everyone to use since they can
> just
> send you data disguised as a packet encrypted to your key :). So I think
> that's
> not such a good idea after all.


That's true, though you can always deal with it in software.  If you try to
decrypt and it fails, then remove the key from the database.  That said, it
doesn't mesh well with hidden recipients and such so it's probably best to
wait until it's decrypted.

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