From: Bill Stewart <stewarts@ix.netcom.com>
Date: Sat, 18 Oct 1997 16:58:04 +0800
To: Adam Back <aba@dcs.ex.ac.uk>
Subject: Re: anti-GAK design principles: worked example #1
In-Reply-To: <3.0.3.32.19971017015110.006afc90@popd.ix.netcom.com>
Message-ID: <3.0.3.32.19971018014919.006c9538@popd.ix.netcom.com>
MIME-Version: 1.0
Content-Type: text/plain



At 06:27 PM 10/17/1997 +0100, Adam Back wrote:
>Bill Stewart <stewarts@ix.netcom.com> writes:
>> I'll duck the 5.5 argument for now, but you're 
>> incorrect on 5.0.  The PGP 5.0 key format includes
>> separate keys for signature and privacy, which is a mostly good thing,
>A very good thing.

It's very good, but it does have its own risks.
If you use the same keys for signature and encrypting to you,
and the government wants to GAK your encryption keys,
they have to steal your signature keys also, 
which just about everybody agrees is Bad, and it's
simply unacceptable in a business environment.
On the other hand, if the keys are separate, Louis Freeh
can tell the Congress that it's not a big problem,
he'd NEVER dream of GAKing your signature keys,
he only wants emergency access to your privacy keys --
this may give the GAK folks a better chance of getting it.
Similarly, your corporate security bureaucrats can understand
the concept that if they CAK your privacy keys,
they're risking having official company signatures get forged,
and they'll often do the right thing and desist,
but with separate keys that won't stop them.


> The PGP 5.0 key format [....]
>> and includes the ability to associate a group of
>> keyIDs and flag bits with each privacy key.
>So can you use pgp5.0 to construct a CMR key which would
>interoperate with pgp5.5 for business?

No.  As far as I know (without reading 7000 pages of code :-),
pgp5.0 won't construct CMR key fields, and won't use them,
it just isn't supposed to die if it receives a key containing them.

>Clearly pgp5.0 does nothing with these flags on reciept, 
>but does it understand them when sending?

If it receives a key containing CMRKs, it doesn't choke on the CMRKs,
and when you encrypt a message to the key, it ignores the CMRKs.
If it receives a message encrypted to both real people and CMRKers,
there's no way to tell which are which (though if you don't have
CMRKs in your key, they're obviously not your CMRKs.)

>Does pgp5.0 reply encrypting to just me as individual, or two crypto
>recipients me, and Mega Corp recovery key?
Just you.

>> >- store a copy of the private half of the users PGP encryption key
>> >  encrypted to the company data recovery key on the users disk.
>> No.  This is evil.  Don't go there.  Even with secret sharing,
>> and especially without.
>
>It is evil.  But it is not _as_ evil.
>
>The reason for this is that government access to storage keys is not
>as evil as government access to communications keys, because the
>government has to come and capture the ciphertext (take your disk),
>whereas with communications they can grab them via an arrangement with
>your ISP.

First of all, the only reason for having a CMRK attached to your key
is that either your mail service will reject mail to you that doesn't
contain it, or your employer insists on it.  In either case,
it can be done without a special CMRK field on your key --
PGP multiple recipients are enough to do that, and the sender
just has to remember to include the (no longer automagically attached) CMRK.
So leaving out the CMRK doesn't protect you.

Second, if the government is coming to get your disk anyway,
they can get themselves a court order to have you reveal the key,
and you can argue with the judge about whether you should be
compelled to reveal it, and at least in the US there's a 
Fifth Amendment backing up your arguments (though like the
other amendments, it's weakened by the "except for drugs" clause...)
GAK asserts that the government has the right to your keys
before you get to court.  Corporate access to storage keys,
on the other hand, is concerned with protecting the company's
information on the company's computers, and you can reasonably
negotiate how much of that you want to live with and comply with.
Some companies want to protect their information in case you
get hit by a bus, or a lawsuit; other companies don't even
have the sense to provide decent automated network-based backup
to protect their information from head crashes.

On yet another hand, while it may be obvious when the
government steals your disk and uses Storage-GAK,
companies using Storage-CAK or Storage-CMR can use it 
just as well on the backup tapes without your notice
as on your disk drive.  Furthermore, you can think of
the data backup process as communications from you
to the backupmeister, so Storage-CAK _is_ Message-CAK,
and Storage-CMR is Message-CMR.

But CAKing the disk doesn't protect the company's information,
and there's therefore no excuse for using it.  Superencryption
is always possible, in messages as well as files, but with
message encryption the eavesdropping-prone corporation can
detect superencrypted messages going by (though not stego'd),
while PGP-encrypted files on your disk only show up _after_
you've been hit by the bus on your way to the headhunter's.

BTW, PGP5.5 CMR _is_ CMR'd storage encryption.  
It's not as convenient as encrypted file systems 
like PGPdisk and Secdev, 
but people are using it to encrypt stored data,
including email and non-email files.

On a technical note, GAK for storage can be made less dangerous,
though not less offensive, by adding a layer of indirection -
use your public key to encrypt a symmetric key, store the encrypted
symmetric key on your disk, and then use the symmetric key for
encrypting the storage (or as a master key for encrypting the
per-file or per-block storage keys, if you're doing that, 
which you probably should.)  This means that a search warrant
which is required to itemize the things it's looking for can be
more effectively restricted to specific files rather than
cracking the whole disk and every other disk that uses the
same encryption keys.

>This is not avoidable for storage ... if you are encrypting data on
>disk, and if you want recovery information, you have no choice but to
>allow company access.    The recovery information should be 
as decentralised as much as possible.  

>The point though is that storage recovery is a completely separable
>issue from communications "recovery" which is a euphamism for allowing
>companies to read, or snoop, employees email, unless it is being used
>soley for data recovery of mail stored in mail folders (which seems to
>be what PGP Inc means by CMR term), in which case it is not necessary
>functionality, and can be better acheived by encrypting the mail
>archive with a user symmetric key with company storage recovery on
>that key.

Trust me - you _really_ don't want mailboxes encrypted,
recovery key or no recovery key, unless it's implemented very very well.
Microsoft Mail, and as near as I can tell Microsoft Exchange,
puts the user's entire mailbox, stored message folders and all,
in one big ugly cheaply-encrypted file.  The encryption isn't
strong enough to keep the NSA out, but it's strong enough to keep
you from repairing the file if part of it gets damaged,
and enough to keep you from extracting the undamaged parts,
or accessing it with sorting tools not built into MSMail.
Combined with the Microslush Mail Mindset of never sending text
when a Microsoft Word file could do, and never sending Word
when an even-more-bloated PowerPoint Presentation can fit,
your mailbox easily expands to over 100MB, too big to fit
on a ZIP drive.  Eventually, something always gets corrupted,
and you end up with Corporate Message Non-Recoverability.


				Thanks!
					Bill
Bill Stewart, stewarts@ix.netcom.com
Regular Key PGP Fingerprint D454 E202 CBC8 40BF  3C85 B884 0ABE 4639