Message-ID: <A21F7772-D726-4A00-86D0-A6F1F3172ED0@pgp.com>
Date: Sat, 27 May 2006 17:04:09 -0700
From: Jon Callas <jon@....com>
To: John Pettitt <jpp@...udview.com>
Cc: bugtraq@...urityfocus.com, Jon Callas <jon@....com>
Subject: Re: On the Recent PGP and Truecrypt Posting

On 27 May 2006, at 12:01 PM, John Pettitt wrote:

>
> I think the underlying point is that many users, not understanding the
> difference between the bulk key used to encrypt the data and the
> passphrase used to protect that bulk key would assume, incorrectly  
> that
> changing 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 described
> restored backup situation in that the user is using a partial  
> restore to
> circumvent 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.   I
> think this is mostly a documentation issue and perhaps a user  
> interface
> design issue in that users should be strongly advised to re-encrypt  
> when
> they change the passphrase.
>
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.

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



Download attachment "PGP.sig" of type "application/pgp-signature" (225 bytes)

Powered by blists - more mailing lists