On 27 May 2006, at 12:01 PM, John Pettitt wrote:
You bring up an excellent point. As I said in my previous post, we are considering a change to the way we're doing things. Unfortunately, there's no one thing that's clear the the right thing to do. Let me examine some of them.I think the underlying point is that many users, not understanding the difference between the bulk key used to encrypt the data and thepassphrase used to protect that bulk key would assume, incorrectly thatchanging the passphrase would lock out prior users. Clearly a users with a backup copy of an encrypted disk for which they know the passphrase can use the technique described to decode a more recent image of the same encrypted disk even though the owner of the disk may think it safe because the passphrase was changed. In this situation the old user gain access to newer data that they were not supposed to be able to access. This is different from the describedrestored backup situation in that the user is using a partial restore tocircumvent a security mechanism. The re-encyrpt button obviously defeats this attack however it's not clear that real world users actually understand the need to re-encrypt to make pass phrase changes meaningful when backup copies exist. Ithink this is mostly a documentation issue and perhaps a user interface design issue in that users should be strongly advised to re-encrypt whenthey change the passphrase.
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. If we put in something there, we can answer any further objection with saying "this is a documented situation," but it doesn't *solve* anything. It is in my opinion, a cop out. We're better off doing nothing or making a code change.
Now then, we could make a code change. But what code change?Security is a strange business, because you quickly go from things that a absolute dos and don'ts into things upon which gentlepersons can disagree. Part of this is because doing the right thing for the user is a good design principle, but so is less is more. Simplicity makes for better security, and that means doing less.
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. I have to think about it for a while. I can see both sides of it. I lean towards less is more, particularly because there are lots of moving parts here. 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? 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.
Automatically re-encrypting the disk has much peril to it. Any time you re-encrypt the disk, you expose the user to the chance of the complete loss of their data. If you want to make it safer, you make it slower. If you want to make it faster, you chew up more resources on the user's computer It's a relatively easy task when it's a megabyte. What happens when it's a hundred gigabytes?
Right now, we not only do virtual disks, but also whole disk encryption. The core of what we do is the same across the board (if not exactly the same code). We have to make tradeoffs. You will also also see the architecture extend to some *very* cool storage encryption very soon. 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. 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? The CYA answer of putting a note in the manual can start looking attractive when you seriously start designing one of these.
I'm open to discussion about the larger issues. But let us not forget that this started out with a bug report that itself says to first get a brain. It was high-handed and insulting. You're right, there is in the core of this, there is a very complex issue. We're discussing if we should do something in response to the real issue here. But the base issue, that there is some flaw in PGP and Truecrypt and other software that only an idiot could have let out is flat out false.
Jon
--
Jon Callas
CTO, CSO
PGP Corporation Tel: +1 (650) 319-9016
3460 West Bayshore Fax: +1 (650) 319-9001
Palo Alto, CA 94303 PGP: ed15 5bdf cd41 adfc 00f3
USA 28b6 52bf 5a46 bc98 e63d
Attachment:
PGP.sig
Description: PGP signature