Re: On the Recent PGP and Truecrypt Posting
Jon Callas <jon@xxxxxxx> wrote:
> We could make a documentation change. I don't like documentation
> changes like this because it's a cover-your-ass solution. Let's face
> it, no one reads the documentation.
Right. Many people don't read it, and those are in many cases the same
people that would be surprised by the effect of password changes that
were described in the original posting.
> Now then, we could make a code change. But what code change?
This is indeed a very hard problem, if you want to avoid the "easy"
solution:
> We could put a dialog box up warning the user. This is a reasonable
> thing to do. The Truecrypt folks do that. One can argue on the other
> side that is is just one step forward from a documentation change,
> that it is a CYA move that doesn't really solve the problem, it just
> allows you to wash your hands of the situation.
Well - I tend to go with another view:
Popping a warning dialog that is hard to ignore/click away without
reading allows for a simple solution that can employ the power of
human judgement to decide whether reencryption is required.
Unfortunately, it depends on the _reason_ for making a password change,
if it requires a change of the disk key to reach the goal of the
password change.
So if you get informed (right when you need it!) that just changing
passwords might not do what you expect it to do, you are enabled to
make an intelligent decision if the password change you are about to
commit should also trigger a reencryption.
An example I already gave for a situation where reencryption is not
necessary, is when you change the password without any reason to believe
it has been or will be compromised. E.g. to sync it up with a new
password scheme you just started using.
> My main PGP disk is not passphase-based, it is public-key-based. If I
> change the passphrase on my key, does that mean that the PGP program
> should grovel over my disk looking for virtual disk volumes that are
> encrypted to that public key? If not, why not?
It should not.
Why? Because the act of changing the password on your secret key is very
much the same as changing the password on a disk container.
At the point where you change your password, you have to decide whether
you do it, because you suspect the passphrase to be compromised, and
whether there exists a chance that an adversary might get at a version
of the file/key that has been protected with it.
If you judge, that this is not the case, all is well. You change the
passphrase and are done with it.
However, if you judge, that the above scenario might come up, you should
try to limit the damage that could be done.
For the case of the disk, it would mean that you need to reencrypt the
disk to limit the use of the maybe compromised password to past
versions of the disk container.
For the case of the public key, it means that you need to _revoke_ the
key to limit the use of the maybe compromised password of the secret
key to messages already encrypted to that key. Just changing passwords
for it won't help. It's the same situation as with disk containers.
It basically boils down to:
- if you consider a key to be compromised, you have to revoke and
replace it and take action to also revoke/replace all keys that
depend on it.
- if you just change some passphrase or other system that is designed
to protect a key for other reasons, you can very probably live
without the above hassle.
> Extend this to virtual volumes that are managed by a smart card or
> security token, and you can see it gets very hard very quickly.
Well - yes and no.
"Yes", because in this case I would probably decide differently in the
case of a compromise of the passphrase or PIN but "no" because actually
the basic question is the same. All that changes is probabilities in the
above reasoning.
If e.g. the PIN of a smartcard gets compromised because someone looked
over your shoulder - and you notice right away - this is much less critical,
because as long as we can assume that smartcards cannot be cloned easily,
you will most of the time _know_ if the adversary has access to the
smartcard protected with the compromised passphrase.
So, if you change the PIN right away, ensuring that the adversary had no
chance to use the smartcard with the old PIN in the meantime, you can be
reasonably sure, that the probability that "there exists a chance that
an adversary might get at a version of the file/key that has been
protected with it" is very low.
> Automatically re-encrypting the disk has much peril to it.
Yes. This needs to be really bulletproof.
> Right now, we not only do virtual disks, but also whole disk
> encryption.
Right. The latter makes it very hard to use the (ressource wasting, but
rather safe) approach of just copying the volume to a new container and
switching when it is ready.
> The re-encryption problem is something we take very seriously, and
> we have seriously discussed whether we should have a re-encryption
> daemon that runs in the background and works like a garbage collector,
> re-encrypting objects that need re-encrypting, based on some security
> policy describing when things will need to be re-encrypted.
This is a very nice idea, but I would rather avoid it, if it can be
helped, because of the inherent complexity.
There isn't much to it, if you are just talking about relatively small
objects that can be reencrypted in a very short timeframe. But it gets
quite a bit complicated when reencrypting large disks or similar.
> It is a garbage collector, but one that is tied to a two-phase-commit,
> zero loss database update system. Is that cool, or is it frightening?
> Or both?
Both of course. I tend to be frightened by cool things.
To sum it up:
I think the problem boils down to determining, if you just want to
change the protection scheme of a key, or if you actually want to
revoke it. (I use the term "revoke" a little loosely here. Maybe
one should rather talk about "marking the key as tainted" or similar.)
This is something the user has to decide, as he has at least a bit of
information, that can be used to guess, if revoking is necessary.
Of course, the safe option is to always revoke. However, unless the
amount of data protected by the key is low, this can cause lengthy
and ressource consuming operations.
I think it is a good thing, to make revocation as painless as possible,
to avoid the bias that it might induce in users, when deciding if they
should revoke the key.
However, unless/util there is a way to absolutely painlessly revoke
a key, I am afraid we will have to leave the decision to human judgement.
Kind regards,
Andreas Beck
--
Andreas Beck
http://www.bedatec.de/