Re: Is PGP still private?

Kent Crispin wrote:

> On Sat, Oct 18, 1997 at 08:48:56AM +0100, Adam Back wrote:
> > My reasoning is this: as PGP Inc can not justify expense on such
> > developments, my CDR proposal would be much safer for them to
> > implement because it requires no steganography support, or other
> > privacy patches to provide protection against abuse of the software
> > for uses other than PGP Inc's designers intentions.
 
> You keep talking as if your CDR proposal is other than vaporware.  So
> far as I have seen you don't have a proposal, you have a wish.

  Given Adam's many accomplishments in the arena of CypherPunks issues,
I find it hard to make a case for his discussion in this area to be
mere mental masturbation.
  'Democracy in America' is also vaporware--always has been, always 
will be--but I see no reason we should not go on discussing it and 
hoping that we will not having to keep pushing the release date of the
finished product back, time and time again.
 
> [...]
> 
> > > You are in error. The only time that you are forced to use CMR is when (1)
> > > you share the CMRK with the other party AND (2) the strict flag is set. In
> > > all other cases, you can opt-out, on a message-by-message basis.

> Adam, it is a complete and utter waste of time to debate this.

  I agree. I think that we should just wait until someone comes out
with an actual product, and then castigate them for their ideas being
"ill-thought out." 

> What would *not* be a waste of time would be more concrete proposals.
> Whether PGP implements something is a separate question -- I would
> like to get back to the question of designing a better email
> encryption system.
> 
> Your reencryption scheme fails because of the management of the short
> term encryption keys, among other things.  Here's another approach I
> will toss out, without thinking through:
> 
> How about formalizing superencryption, or tunneling? That is, treat
> CMR traffic as a transport medium for messages that are themselves
> already encrypted.  The "key" idea here is to allow layering of non
> CMR traffic over CMR traffic.  All the code for both is obviously
> already in PGP, with a little glue and perhaps some minor protocol
> mods...

  In return for your positive suggestions, the CDR Board of Dirctors
has voted to allow you two posts containg cheap shots at the list
member of your choice, without including any points of redeeming,
on-topic, list value.

Toto
~~~~
"The Xenix Chainsaw Massacre"
http://bureau42.base.org/public/xenix
"WebWorld & the Mythical Circle of Eunuchs"
http://bureau42.base.org/public/webworld
"InfoWar"
http://bureau42.base.org/public/infowar3
"The Final Frontier"
http://www3.sk.sympatico.ca/carljohn

On Sun, Oct 19, 1997 at 10:25:08AM +0100, Adam Back wrote:
> 
> Toto <toto@sk.sympatico.ca> writes:
> > Kent Crispin wrote:
> > > You keep talking as if your CDR proposal is other than vaporware.  So
> > > far as I have seen you don't have a proposal, you have a wish.
> > 
> >   Given Adam's many accomplishments in the arena of CypherPunks issues,
> > I find it hard to make a case for his discussion in this area to be
> > mere mental masturbation.
> 
> Thanks for the vote of confidence Toto.
> 
> Also I must raise the point that it is not a lone stand.  Other people
> are arguing against PGP Inc's CMR proposal, and are arguing for more
> GAK resistant variants, and alternatives.  

Apparently for some internal reason you must raise the point, but it
is irrelevant.  I said your *proposals* were vaporware, not your
motivations.  It is, as I have said, a waste of time (and yes, mental
masturbation) to argue about motivations. 

[. citations of famous cryptographers and Kent Crispin snipped .]

> However the biggest point of all is that: communications keys are more
> valuable to any attacker (government, unscrupulous little brother, or
> industrial spy) than storage keys.
> 
> I would be interested to see any one willing to burn their
> reputational capital refuting that simple point.

*Long term* communication keys.  Nobody is going to burn reputation
capital on that point because it's obvious, and really doesn't need to
be argued.  Furthermore the point applies just as well to current PGP
keys.  The *only* additional vulnerabilities of CMR come from 1) the 
volume of data makes it a more interesting target and 2) the 
management of the CMR key(s) may be problematic.  

However, in a large organization the management of *user* keys is
problematic, as well, and management of the CMR key(s), on balance,
will probably be better.  So the additional vulnerability of CMR comes
from the fact that it makes a lot of data accessible from one key. 
This vulnerability could be reduced by having multiple CMR keys -- the
accounting dept has one, the CEO has one, and it is the same as his
private key that is not escrowed anywhere, etc etc etc.

[Is it true that the private key associated with a CMR public key 
could simply be discarded, rather than escrowed, and everything would 
still work? -- except that you couldn't recover anything, of course...]

A more interesting argument is as follows: what is the real level of
security needed for the business communications that will be covered
by CMR? It seems obvious that the level of security required, on
average, is really quite low.  Note that businesses send all kinds of
important documents through regular mail, only protected *gasp* by
PAPER ENVELOPES. 

Anyway, Adam, I anxiously await the paper you are working on that 
gives the real details of your proposals.  I'm sure it's readability 
will be vastly improved if you religiously avoid the use of the word 
GAK :-)

-- 
Kent Crispin				"No reason to get excited",
kent@songbird.com			the thief he kindly spoke...
PGP fingerprint:   B1 8B 72 ED 55 21 5E 44  61 F4 58 0F 72 10 65 55
http://songbird.com/kent/pgp_key.html

Kent Crispin <kent@bywater.songbird.com> writes:
> On Sun, Oct 19, 1997 at 10:25:08AM +0100, Adam Back wrote:
> > Also I must raise the point that it is not a lone stand.  Other people
> > are arguing against PGP Inc's CMR proposal, and are arguing for more
> > GAK resistant variants, and alternatives.  
> 
> Apparently for some internal reason you must raise the point, but it
> is irrelevant.  I said your *proposals* were vaporware, not your
> motivations.  It is, as I have said, a waste of time (and yes, mental
> masturbation) to argue about motivations. 

Motivation is irrelevant.  The road to hell is paved with good
intentions.  All the sides in the argument (except for Freeh and the
USG/NSA) have good intentions (and perhaps even Freeh from his
perspective).  Fooh on good intentions.  Let's keep this discussion
focussed on:

  The design of systems which are hard for governments to abuse in
  introducing GACK

You made one contribution in this area in your last post.  Keep up the
technical contributions, and scenario likelihood evaluations.

> > However the biggest point of all is that: communications keys are more
> > valuable to any attacker (government, unscrupulous little brother, or
> > industrial spy) than storage keys.
> > 
> > I would be interested to see any one willing to burn their
> > reputational capital refuting that simple point.
> 
> *Long term* communication keys.  Nobody is going to burn reputation
> capital on that point because it's obvious, and really doesn't need to
> be argued.  

If it doesn't need to be argued, why does pgp2.x and pgp5.x use long
term communication keys?  Why does pgp5.x then go exacerbate this
problem encouraging use of not one but two long term communications
keys.  Why does it provide recovery methods for long term
communications keys when the stated user requirement is to recover
stored email archives?

ie. the discussion just took this form:

Adam: X is a bad security idea.  X is used in pgp2.x and pgp5.x

Kent: modification Y to pgp5.x doesn't make it any worse

Adam: So?  It's still a bad idea, and here are ways to make it more
      secure, and harder for governments to abuse to boot

Kent: ?  (we're waiting)

Surely the most straight forward way to provide recovery for email
archives is to archive the emails encrypted to a storage-only key,
with this key escrowed in some way?  You then don't need to recover
email in transit -- you don't even have a copy of it.

This is clearly more resistant to government abuse.  Do you disagree?

(The above paragraph is basically all my CDR proposal is .. it seems
straight forward, intuitive, more secure; I went through and countered
your previous objections to worked example #1, you did not reply to
those counter-points).

> Furthermore the point applies just as well to current PGP keys.  The
> *only* additional vulnerabilities of CMR come from 1) the volume of
> data makes it a more interesting target and 2) the management of the
> CMR key(s) may be problematic.

You missed a couple:

3) the goverment will love to get come ask for your CMR key because it
protects all past emailed ciphertext

4) some governments (eg France) will probably ask for one of the CMR
keys to be theirs

> However, in a large organization the management of *user* keys is
> problematic, as well, and management of the CMR key(s), on balance,
> will probably be better.  So the additional vulnerability of CMR comes
> from the fact that it makes a lot of data accessible from one key. 
> This vulnerability could be reduced by having multiple CMR keys -- the
> accounting dept has one, the CEO has one, and it is the same as his
> private key that is not escrowed anywhere, etc etc etc.

Yes.  Several people have suggested this.  Also secret sharing is
being considered by PGP Inc for the next version I think.

> [Is it true that the private key associated with a CMR public key 
> could simply be discarded, rather than escrowed, and everything would 
> still work? -- except that you couldn't recover anything, of course...]

I would think so.  This would argue for updating the CMR
communications key as frequency as is practicable to minimise danger.
(Same argument as update requirements for user communications keys).
Hal Finney discussed this requirement of matching expiry frequency on
comms keys & corresponding CMR keys a few messages back.

> A more interesting argument is as follows: what is the real level of
> security needed for the business communications that will be covered
> by CMR? It seems obvious that the level of security required, on
> average, is really quite low.  Note that businesses send all kinds of
> important documents through regular mail, only protected *gasp* by
> PAPER ENVELOPES. 

This suggests that Tim May is right, and the simplest solution is to
store the decrypted received emails in clear on the disk.  Most of the
companies are in fact storing on disk.

> Anyway, Adam, I anxiously await the paper you are working on that 
> gives the real details of your proposals.  I'm sure it's readability 
> will be vastly improved if you religiously avoid the use of the word 
> GAK :-)

Could you provide a less emotive suitable alternative word which I can
use as a replacement to describe government communications key
grabbing attempts?  GACK is what Carl Ellison proposed as a more
accurate way to express "Goverment Access to Communications Keys" than
terms such as "key escrow", "key recovery", which are government
coined terms.  PGP Inc themselves being mostly cypherpunks and
pro-privacy people use the term GACK also.

GACK seems a pretty good acronym to me, accurate, descriptive.  Are we
getting goverment-correct now as well (as politically-correct)?  So
that we must not use terms which are offensive to governments?

(I will attempt to avoid negative political comments about PGP Inc's
implementation, and phrase in terms of constructive criticisms though,
and perhaps this was your point given my earlier outbursts in this
regard; perhaps you can help proof read for this).

Cheers,

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`

On Sun, Oct 19, 1997 at 07:15:00PM +0100, Adam Back wrote:
> 
> Kent Crispin <kent@bywater.songbird.com> writes:
> > On Sun, Oct 19, 1997 at 10:25:08AM +0100, Adam Back wrote:
> > > Also I must raise the point that it is not a lone stand.  Other people
> > > are arguing against PGP Inc's CMR proposal, and are arguing for more
> > > GAK resistant variants, and alternatives.  
> > 
> > Apparently for some internal reason you must raise the point, but it
> > is irrelevant.  I said your *proposals* were vaporware, not your
> > motivations.  It is, as I have said, a waste of time (and yes, mental
> > masturbation) to argue about motivations. 
> 
> Motivation is irrelevant.

Good.  We agree, and can therefore move on.

> You made one contribution in this area in your last post.  Keep up the
> technical contributions, and scenario likelihood evaluations.
> 
> > > However the biggest point of all is that: communications keys are more
> > > valuable to any attacker (government, unscrupulous little brother, or
> > > industrial spy) than storage keys.
> > > 
> > > I would be interested to see any one willing to burn their
> > > reputational capital refuting that simple point.
> > 
> > *Long term* communication keys.  Nobody is going to burn reputation
> > capital on that point because it's obvious, and really doesn't need to
> > be argued.  
> 
> If it doesn't need to be argued, why does pgp2.x and pgp5.x use long
> term communication keys? 


History.  Backward compatibility.  Time pressures.  And a design for
short term communication keys for email does not yet exist -- not from
you, not from anyone.  [Your CDR proposal uses *long term*
communication keys.]

These seem pretty compelling reasons to me. 

Just because something is desirable doesn't mean it is practical, or 
even possible.  

[...]
> 
> Surely the most straight forward way to provide recovery for email
> archives is to archive the emails encrypted to a storage-only key,
> with this key escrowed in some way?  You then don't need to recover
> email in transit -- you don't even have a copy of it.
> 
> This is clearly more resistant to government abuse.  Do you disagree?
> 
> (The above paragraph is basically all my CDR proposal is .. it seems
> straight forward, intuitive, more secure; I went through and countered
> your previous objections to worked example #1, you did not reply to
> those counter-points).

I did not because you presented it as a throwaway, with statements to
the effect that you already knew it was defective but you were
presenting it anyway.  Besides, in all honesty I did not find your
counterarguments very compelling, and I was content to wait until I 
saw a "real" proposal.  If I have a chance, though, I will go back 
and address that...

BTW, perhaps you remember a fairly long thread sometime back where I 
discussed the pros and cons of a "keysafe" model for data recovery 
keys? 

> > Furthermore the point applies just as well to current PGP keys.  The
> > *only* additional vulnerabilities of CMR come from 1) the volume of
> > data makes it a more interesting target and 2) the management of the
> > CMR key(s) may be problematic.
> 
> You missed a couple:
> 
> 3) the goverment will love to get come ask for your CMR key because it
> protects all past emailed ciphertext
> 
> 4) some governments (eg France) will probably ask for one of the CMR
> keys to be theirs

I include both of those under my number 1.

> > However, in a large organization the management of *user* keys is
> > problematic, as well, and management of the CMR key(s), on balance,
> > will probably be better.  So the additional vulnerability of CMR comes
> > from the fact that it makes a lot of data accessible from one key. 
> > This vulnerability could be reduced by having multiple CMR keys -- the
> > accounting dept has one, the CEO has one, and it is the same as his
> > private key that is not escrowed anywhere, etc etc etc.
> 
> Yes.  Several people have suggested this.  Also secret sharing is
> being considered by PGP Inc for the next version I think.
> 
> > [Is it true that the private key associated with a CMR public key 
> > could simply be discarded, rather than escrowed, and everything would 
> > still work? -- except that you couldn't recover anything, of course...]
> 
> I would think so.  This would argue for updating the CMR
> communications key as frequency as is practicable to minimise danger.
                        ^^^^^^^^^frequently?

?I don't see the connection.  My point was that you can generate a key
pair, throw away the private key, and use the public key as the CMR
key.  Perhaps you could just use random bits in the correct format for
the public key, and never generate a key pair at all.  This would meet
external requirement of having a CMR key, but it would be meaningless,
since the missing private key could never be used to decrypt anything. 
Thus, though externally an organization (say an ISP) would be
complying with a regulation, in fact it would be impossible to 
recover any email anyway...

In any case, I presume the "danger" you refer to is the danger that 
someone will snarf the CMR key.  Changing it frequently will reduce 
the number of compromised messages if any given key is compromised.  
(Of course, the CMR keys will have to be preserved forever in a 
little database of some sort -- if you change them often, that 
database will be large...)

> (Same argument as update requirements for user communications keys).
> Hal Finney discussed this requirement of matching expiry frequency on
> comms keys & corresponding CMR keys a few messages back.

> 
> > A more interesting argument is as follows: what is the real level of
> > security needed for the business communications that will be covered
> > by CMR? It seems obvious that the level of security required, on
> > average, is really quite low.  Note that businesses send all kinds of
> > important documents through regular mail, only protected *gasp* by
> > PAPER ENVELOPES. 
> 
> This suggests that Tim May is right, and the simplest solution is to
> store the decrypted received emails in clear on the disk.  Most of the
> companies are in fact storing on disk.

It is the MUA that uses PGP (Eudora, Mutt, whatever) that decides how
to store the decrypted files, not PGP.  PGP decrypts the files and
gives them to the MUA, which displays them to the user.  The MUA has
the option of storing it encrypted or not, as delivered, or with 
another key.  PGP isn't in control, it's the MUA, isn't it?

> > Anyway, Adam, I anxiously await the paper you are working on that 
> > gives the real details of your proposals.  I'm sure it's readability 
> > will be vastly improved if you religiously avoid the use of the word 
> > GAK :-)
> 
> Could you provide a less emotive suitable alternative word which I can
> use as a replacement to describe government communications key
> grabbing attempts?  GACK is what Carl Ellison proposed as a more
> accurate way to express "Goverment Access to Communications Keys" than
> terms such as "key escrow", "key recovery", which are government
> coined terms.  PGP Inc themselves being mostly cypherpunks and
> pro-privacy people use the term GACK also.
> 
> GACK seems a pretty good acronym to me, accurate, descriptive.  Are we
> getting goverment-correct now as well (as politically-correct)?  So
> that we must not use terms which are offensive to governments?
>
> (I will attempt to avoid negative political comments about PGP Inc's
> implementation, and phrase in terms of constructive criticisms though,
> and perhaps this was your point given my earlier outbursts in this
> regard; perhaps you can help proof read for this).

Whatever.  It does strike me that you seem to have difficulty in
maintaining composure whenever the term comes up, your prose gets
hasty, with missing words and odd syntax, and I suspect that your
usually razor-sharp edge suffers as well....  :-)

-- 
Kent Crispin				"No reason to get excited",
kent@songbird.com			the thief he kindly spoke...
PGP fingerprint:   B1 8B 72 ED 55 21 5E 44  61 F4 58 0F 72 10 65 55
http://songbird.com/kent/pgp_key.html

Toto <toto@sk.sympatico.ca> writes:
> Kent Crispin wrote:
> > You keep talking as if your CDR proposal is other than vaporware.  So
> > far as I have seen you don't have a proposal, you have a wish.
> 
>   Given Adam's many accomplishments in the arena of CypherPunks issues,
> I find it hard to make a case for his discussion in this area to be
> mere mental masturbation.

Thanks for the vote of confidence Toto.

Also I must raise the point that it is not a lone stand.  Other people
are arguing against PGP Inc's CMR proposal, and are arguing for more
GAK resistant variants, and alternatives.  

Several amongst those who have so argued are higher reputation than
myself: Bruce Schneier, (plus some others with similar crypto
credentials I have asked for comments from off list which I can not
reveal due to ethics of email confidentiality).  I have some small
about of credibility myself I think also.

In addition I consider myself, Tim May, Peter Trei, Attila T Hun, and
the many others arguing for more resistant variants to have some
reputation, and it seems unlikely to me that we would all burn our
reputations over an insignifcant point.  We are collectively arguing
because (and I think the others will agree) we think that there are
more resistant variants than the CMR proposal used in pgp5.5.  These
variants are also practical within the constraints imposed by the
plug-in APIs, and user requirements PGP must work within, I believe.

Even Kent Crispin who seemed to dismiss the first round as an
insignificant difference, is offering more resistant variants.  PGP
Inc's Jon Callas together with cypherpunks Bill Stewart, Attila T Hun,
and myself were also arguing that even TLS (transport level security),
or in other words an extra encryption envelope over the recovery
information is an improvement.  (Particularly if you do as I argue for
and try to make the TLS keys user owned where possible, and try to
make the system as forward secrect as possible).

However the biggest point of all is that: communications keys are more
valuable to any attacker (government, unscrupulous little brother, or
industrial spy) than storage keys.

I would be interested to see any one willing to burn their
reputational capital refuting that simple point.

That point is the simple central starting point for all arguments
about the dangers of allowing recovery information to be transmitted
with the communication.  Recovery information should be local
whereever possible.  Bruce Schneier had harsh words to say about
violating this principle in one of his recent cypherpunks posts.

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`

Adam Back wrote:
> However the biggest point of all is that: communications keys are more
> valuable to any attacker (government, unscrupulous little brother, or
> industrial spy) than storage keys.
> 
> I would be interested to see any one willing to burn their
> reputational capital refuting that simple point.
> 
> That point is the simple central starting point for all arguments
> about the dangers of allowing recovery information to be transmitted
> with the communication.  Recovery information should be local
> whereever possible.  Bruce Schneier had harsh words to say about
> violating this principle in one of his recent cypherpunks posts.

  Anyone notice the court ruling in regard to the company that sued
to retrieve information that was inside an employee's head, claiming
that his employment agreement made *all* of his ideas the property
of the company.
  Anyone notice that the Thought Judge ruled that the Thought Laws
required the individual to divulge said ideas, or be imprisoned by
the Thought Police?

   Real-Time Message Recovery = Real-Time Thought Recovery 
                      PGP/CMR = Digital Brain Implants 
Government Access to Thoughts = Government Access to Brains

TruthMonger