data recovery good, key recovery bad (Re: Are we all looking at the same PGP 5.5 ?)

[Adam Back <aba@dcs.ex.ac.uk>]

[I've moved this thread to cypherpunks, it was on cryptography, and
Perry (cryptography moderator) just killed the thread.  Some of the
participants may not be on cpunks, so keep them on the cc if you want
them to see your replies]

Marc Horowitz <marc@cygnus.com> writes:
> >> > What makes you think that all critical email is on disk in the clear?
> >> 
> >> Nothing: it could be on disk encrypted.  eg. Encrypted files encrypted
> >> with storage keys, or encrypted partition encrypted with storage key,
> >> or encrypted sent or received email encrypted with storage key.
> 
> Well, if it's encrypted on disk, then "you read the disk" doesn't get
> you very far.  You need to be able to decrypt the information on the disk.

Of course you do.  Lets say you are using Peter Gutmanns encrypted
filesystem setup.  So, if you figure the info on the disk is
important, you give a copy of the key to the company lawyer, put it in
the fire proof safe, secret split it, whatever tickles your fancy.

The advantage of this is that the email software it is no use to the
GAKkers, because it doesn't have mildly enforced extra crypto
recipients, and it doesn't get the business community used to the idea
of shipping email around with extra doors into it.  PGP Inc's pgp5.5
could be used by the government to weedle their way into mandatory key
escrow.  Say that they start requiring companies to use this software,
then when lots of companies start using it, they start asking
companies for a copy of the company master key.  Bingo key escrow,
courtesy of PGP Inc.  Next they "encourage" ISPs to use it also.

> >> The way to do it is as described above.  Archive the email, encrypt it
> >> to a starage key.  Build that functionality into the MUA if you fancy.
> >> But _don't_ give extra access to keys used for communications only.
> 
> There is no extra access to communication keys.

There is so!  His mail said that there was a policy flag in the public
key, and an additional public key for the corporate back door.  That
policy flag effectively said this key has attached to it a request
that you encrypt to this extra crypto recipient.  In some cases an
additional flag will be set which says "if you do not comply with the
request to encrypt to the extra crypto recipient, the recipient will
not see the mail".  PGP Inc's method of enforcing this is an SMTP
policy enforcer which bounces mail without the extra crypto recipient.

There, that is an extra access to the communication (via an extra
route to accessing the session key).

Uhhh, I think I just realised why we are talking at cross
purposes... you meant extra access to the recipients private key.  I
consider this an artificial straw man, erected by Jon.  Sure it's an
independently dumb idea to have lots of people sharing private keys.
But the system is still GAK friendly.  And it does allow extra parties
access to the message.  The worry is that government becomes that
second party.

Do you really care about the details of mandatory GAK, when and if it
comes in.  Do you care whether the government has a copy of your
private encryption key, or whether the system is setup with
un-bypassable second crypto recipient of the USG/NSA etc.  Can't see
that it makes much difference at that point.

Both methods can be bypassed theoretically anyway, by super encrypting
or any other subliminal channels kicking around in the protocols.  So
I can't see that arguments about how easy they are to bypass hold much
water.  Frisbeeing a disk out the window is far easier a way to bypass
anyway.  Or just blabbing.

> >> Hint: you will note that Freeh and friends aren't interested in
> >> storage keys.  You can see why the above systems is less GAK friendly
> >> right?
> 
> Freeh wants storage keys, too.  He wants *all* the keys.

Yeah he probably does.  But he wants your communications keys a lot
more.

You know why that is?

Because he has your communications because you're broadcasting them
across the Internet.  He'd like to read them.

However he doesn't have your disk, and he'd have to break into your
offices to get it, or issue you with a supeona or whatever.  I'm sure
he'd love to read your disk too, but your disk isn't sitting on an NFS
mount over the internet.  (Is it!?)  Fortunately, the internet
couldn't handle the strain, otherwise you might see calls for you to
rent your disk space of government disk farms, and the government
would then be very interested in demanding a copy of your storage keys.

So, if even if we use corporate key backup for storage keys, this is
still more along the lines of the status quo.  They want your
documents, they've gotta come and get them.

What we'all are getting worked up about here is that Freeh and friends
want to be able to key word search our damn communications on fishing
expeditions.

> Email is a funny thing.  It's sort of storage, and sort of
> communications.  I can understand wanting to recover it from a
> communications aspect.  They don't call SMTP "store-and-forward" for
> nothing.

There is no information in the body of the message which is required
for it to get to it's destination.  All you need is the SMTP headers.
You clearly can't end-to-end encrypt the communications routing
information.  (You could layer it though, like perhaps remailers, with
each hop only knowing what it needs to know to do it's job; however at
that point you can run into problems: you can't bounce back a delivery
failure part way along the route.)

> You'll notice that if I delete the messages after receiving it, it
> can't be recovered.  If I don't, it can.  Sound like storage to me.

So?

The point is that you shouldn't be mixing key purposes.
Communications private keys should be used to protect communication
and shouldn't be given to anyone else, even your company.  Storage
keys might be sensible things to backup within the company in case of
accidental death.

Actually I disagree with what you said: you said "if I delete the
message after receiving it, it can't be recovered", it might easily be
recovered in lots of ways:

1. feds have tap on your line, feds rubber hose your long term private
key out of you

2. your sender has kept a copy in the clear

3. your sender has kept a copy encrypted with a poor passphrase which
the feds guess/or rubber hose from him

4. your sender used encrypt-to-self, and has poor
passphrase/is passphrase rubber hosed

5. your sender kept a copy which still had you as a crypto recipient
(as well as himself with encrypt-to-self), and the feds arrive at your
door anyway.


Point is, as long as you've got the private keys, it is potentially
stored, courtesy of your favourite TLA.  This is why you should use
forward secrecy, or at least mimic it, by having a long term signature
key, and generating a new public key for encryption every week/month,
and revoking and destroying the old one.

> >> I figure it's not that major a deal.  But for those that want it, the
> >> most secure, simultaneously least GAK friendly way to do it is to
> >> archive and encrypt with separate storage keys.
> 
> This is *exactly* what PGP does: it encrypts with the recipient key,
> and the recovery key.  

Yes, it does, and that is GAK friendly.  But that is not what I
described above.

The difference between what I describe above (quoted a few lines up),
and what PGP is doing is that PGP's messages are sent across the
internet encrypted to the "recovery key".  This is GAK friendly
because it is easy to implement GAK with it, you just make that
"recovery key" the NSA's "recovery key" (or to avoid newspeak terms
perhaps that should be government backdoor master key).  Then they
coerce ISPs and corporates to include a PGP SMTP policy enforcer which
insists on all email having a second crypto recipient of the NSA's
backdoor master key.  The system is a beautiful GAK system, everything
you need for a fully working GAK system is right there on sale by PGP
Inc.

With what I described, GAK is not possible.

What I described is: the MUA archives sent email, and archives
received email (after decryption) with none of this process leaking
outside the corporate lan (that is it may involve communication inside
the LAN).  The archives can be encrypted, and you can have a corporate
master key with access to these archives.  But none of this goes over
the Internet.

> At this point, I'm not sure if we disagree or not. 

I'm not sure either, please let me know if I've explained myself this
time!

I'm worried that the hard time I'm having getting people to grok that
escrowing comms keys is a bad idea if you're opposed to mandatory GAK
is indicative of the success of the memes being spread by Freeh's
crowd.  PGP Inc are especially worrying, as they are in a position to
influence the balance of whether we get GAK or not, and they appear to
be helping GAK out somewhat.  Whether this is complicit or whether
they don't see that the fact they've implemented a fairly feasible GAK
system as that significant in the argument, I'm not sure.


However, I think the argument it is relatively straight-forward:
companies care about backup of their data.  They don't care about
backup of their communications.  So why backup communications keys?
And why include the backup packet in the communication itself?

For those companies who have been persuaded that they ought to read
email received and email sent, you can implement this without
weakening comms security as PGP have done with pgp5.5 for business
which is to have a second crypto recipient for backup/backdoor being
sent with the message over the internet.

All you do for backup or company backdoor is to build in whatever
storage, and encrypted archiving functions you wish into the MUA, or
internal mail system.

That is GAK unfriendly.  If PGP Inc is still GAK unfriendly, and
hasn't sold out to government, it should be doing something with
similar properties to those I described above: not having backdoor
second recipient access to traffic. What they have done is implemented
a fully functional GAK system.

(I get the feeling that sooner or later we're going to get a PRZ
penned company position statement.  I hope they get it right.  I
encourage them to re-think.)

Adam
-- 
Now officially an EAR violation...
Have *you* exported RSA today? --> http://www.dcs.ex.ac.uk/~aba/rsa/

print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<>
)]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`