CMR paves the road to GAK, and provides no corporate security.

I've been mulling over PGP5's CMR feature for a while, trying to
decide what I think of it. It hasn't been easy, but I've come down
against it. I'm restricting my discussion to the use of CMR in 
corporate email. I am not addressing stored data.

> Jon Callas (jon@pgp.com) writes:

> There are two things I will discuss in this missive:

> (1) The assertion that Corporate Message Recovery is "just like Clipper"
> and why this is not true.
> (2) The fear a number of people have expressed that Corporate Message
> Recovery (CMR) could be used by the US government to slide in GAK. 

> I think we're agreed that CMR isn't itself GAK and I'll talk some about why
> it isn't with (1).

I think that we're a lot more worried that the presence of features like CMR
will make it easier for governments to mandate GAK. It's much tougher to 
insist on GAK if a switch requires new software to be developed, and
for everyone to purchase, install, and use espionage-enabled software. If
CMR -
like facilities are already in the software, then GAK could be mandated
overnight 
by executive order.

The inclusion of CMR drastically lowers the barriers to mandated GAK.

>CMR isn't like Clipper:

>* Clipper was a 64-bit key. CMR symmetric keys are full-strength keys (128
>bits or more), backed with a full-strength public key.

A word of advice: don't try to discuss Clipper in this forum without checking
your facts. Clipper used an 80 bit key.

> * Clipper's key was set in hardware by the manufacturer, and users were
> required to use it. 

Actually, the chips left the manufacturer 'blank'. They were to have their
unit keys set by some ill-defined process involving government employees.
It never really got nailed down, since Clipper was killed before the
key escrow agencies and systems were ramped up beyond demonstration levels.

> A CMR key is a software-enabled key, no user is ever
> required to use it.

With a CMR feature in place, a government can say "Starting now, encrypt 
to this key or we'll throw you in jail." Without CMR, they can't really do
this.

> There are cases in which a user might "volunteer" to
> use a CMR because they work for someone who requires it, 

[or because the State says it will toss his sorry ass in jail if he
 does not]

> but that's a
> problem we'll address with the PGP Secure Resume Server which allows
> headhunters to securely and anonymously find people who've made bad career
> decisions.

[or bad citizenship decisions?]

> * A CMR key can be revoked, reissued, or changed. You can periodically
> change it as a matter of policy. You can even stop using it. Clipper's was,
> again, set in hardware, with no option of not using it. 

Once again, you're unlikely to do this if the State decides that that would
be a good reason to jail you.

> * The Clipper symmetric algorithm was secret; CMR keys use publicly
> available algorithms.

True, but the point is moot - most people beleive that the NSA is perfectly
competant to write secure symmetric ciphers without outside review, and 
since they had given themselves a backdoor, there was no reason to leave 
the window unlocked as well.

> * With Clipper, there was always a concern that an outside agency had the
> keys. This is true with a number of other systems (the so-called key
> recovery systems), and is the reason that a number of them are lumped
> together with the term GAK. Note that the user-organization creates a CMR
> key, and the end-user enables it. If any government gets access to this
> key, it is because either (1) they solved the Discrete Logarithm Problem,
> (2) they broke the public CMR key, (3) they black-bagged your CMR key, or
> (4) they are using a subpoena, warrant, or discovery to get the key. We're
> working on a way around (1), we can't do anything about (2) or (3), but
> these are fine reasons not to use CMR! If you're beset by (4), you need
> lawyers, not cryptographers.

If the State could do (1), they would not be asking for key recovery in the
first place. (2) and (3), are greatly aided by CMR, since CMR provides 
high value targets; breaking or black-bagging a single key gives you access
to a great deal of traffic, and in the case of (4), you lose 5th Amendment
protection, since a third party holds a key.

> * With Clipper, there was a central repository of all the keys. With CMR,
> there is not. I discussed that in detail in my message, "Why Corporate
> Message Recovery isn't Key Escrow."

Once again, you haven't checked the record. Clipper keys were to be split, 
with different halves going to different government agencies. There were
fairly elaborate plans to prevent posession of only one half giving an
attacker an advantage. Thus there were *two* repositories, not one. 
(From the point of view of the paranoid, this was not much of a
comfort - both repositories belonged to the same entity.)

> I have noticed that a number of people have the tacit assumption that
> business people and corporations are in cahoots with the FBI, waiting to
> hand over everyone's secret key. As in all parts of life, there are many,
> many businesspeople and corporate execs who are not particularly moral. But
> I don't think that their immorality takes this form. If we could examine
> the dark, secret thoughts of a corporate scumwaffle -- the ones that he
> *really* hopes don't hit the papers -- I sincerely doubt that, "Oh, Louis,
> I love it when you rummage my drawers" is among them.

Here's an alternative interpretation. 

I think that 'business people and corporations' feel (with considerable 
justification, I might add) that they have a moral right to control the 
information which flows in and out of their worksites, just as they 
have a right to control to flow of material goods on and off of their 
premises. 

To control the flow of material goods, companies install security systems,
guards, metal detectors, etc. Depending on the type of good and it's value,
these more or less work, though they're never perfect; when the marginal cost
of improving security exceeds the loss that the improvement would prevent, 
you stop adding security. In the extreme case, the diamond workers of Namibia
have to undergo a full-body X-ray whenever they leave the diamond reserve.

Companies would like to be able to able to exercise similar control over data.
However, bits behave differently than do atoms. Physical barriers are almost
perfectly transparent. An employee can slip a multi-gigabyte DAT tape in
a shirt pocket, or transfer stego'd data undetected inside innocent cover
data,
perhaps with non-CMR'd superencryption.

For data, physical barriers - firewalls, passwords, isolated lans, access
controls
encryption, et al, can work more or less effectively to prevent
unauthorized outsiders
from acquiring data they should not. 

However, there is *no* way in which you can prevent a person you have
authorized to
receive data from making whatever use of it they desire, even if those uses
are 
opposed to your reasons for giving them the data.

CMR serves to give corporate executives the illusion that they can control the
uncontrollable. It lets them think they can monitor the expression of their
employess, while they can not. It lets them beleive that they can use
technology
to protect corporate proprietary data from theft by disloyal employees, while 
they can not. The only way to protect data is to make sure that employees 
share the goals and ends of the corporation; ie, give them a reason to be
loyal 
and trustworthy.

Classified agencies know this. In the classified world, there is a huge effort
to protect data from outside attack. There is a similarly intense effort to 
check that only loyal, reliable, trustworthy people get clearances, and 
strong 'need to know' controls to restrict what data even they can see.
However,
once a cleared person has acheived properly authorized access to classified 
data, there is (in my observation) remarkably little done to prevent them 
from deliberately walking off with it.

CMR provides an illusion that this loss can be prevented. It looks good in a
chief security officer's report; it gives warm fuzzies to senior management.
However, it provides no real security. In fact, it actually weakens security, 
since anyone with licit or illicit access to the CMR key(s) can read the data.

> Now then, the next topic is the fear that CMR will be used in some
> insidious government plot to slip in GAK everywhere.

> I worry about this, too. But I don't think it's feasible that CMR can be a
> stalking horse for GAK. If the government wants to GAK-enable all PGP,
> they'll have to have a plan similar to this:

[Strawman GAK plan deleted]

Here's a more realistic scenario.

1. OpenPGP with CMR becomes a standard, and is widely accepted and
installed. PGP gets
rich. (Are you going to claim that this could never happen?)

2. An executive order is signed by the President, ordering that all encrypted 
email include the FBI public key as a recipient. He notes that this will be
no 
burden to industry, since it's a freebie with the industry standard CMR
facility.

To summarize:

1. CMR cannot prevent disloyal employees from sending messages that their
   employers would want to prevent.

2. CMR, widely deployed, would greatly ease a transition to mandated GAK.

Given CMR's inability to provide an a desirable goal (improve corporate
security),
coupled with the severe downside (paving the road to GAK), I have decided that
I must oppose it.

> Jon Callas jon@pgp.com

Peter Trei
trei@ziplink.net

At 9:54 PM -0700 10/11/97, Trei Family wrote:
>Classified agencies know this. In the classified world, there is a huge effort
>to protect data from outside attack. There is a similarly intense effort to
>check that only loyal, reliable, trustworthy people get clearances, and
>strong 'need to know' controls to restrict what data even they can see.
>However,
>once a cleared person has acheived properly authorized access to classified
>data, there is (in my observation) remarkably little done to prevent them
>from deliberately walking off with it.

There's damn little you can do in a free society.  KeyKOS provided a
facility where you could give information to a program and ensure it could
not communicate it elsewhere.  However this facility involved running the
program in what amounted to solitary confinement.  While you can get away
to doing this to programs, people are (rightfully) different.


-------------------------------------------------------------------------
Bill Frantz       | Internal surveillance      | Periwinkle -- Consulting
(408)356-8506     | helped make the USSR the   | 16345 Englewood Ave.
frantz@netcom.com | nation it is today.        | Los Gatos, CA 95032, USA

[Padgett, you're Cc'd because I'm quoting something you once claimed
on Perry's list, I think]

I agree with basically every word Peter Trei wrote.  It's not often
you agree with a long post like that 100%, but I could not fault a
single point.

Contrast that to PGP's Jon Callas's recent posts where I found myself
disagreeing with a large proportion of both technical and political
points.

Just a couple of nit-picky comments on various things, and some
re-iteration of the technical arguments against GAK compliancy (to
supplement Peter's good political arguments):

> >* Clipper was a 64-bit key. CMR symmetric keys are full-strength keys (128
> >bits or more), backed with a full-strength public key.
> 
> A word of advice: don't try to discuss Clipper in this forum without checking
> your facts. Clipper used an 80 bit key.

Clipper was definately advertised as a 80bit key, I agree.

But I did once see someone else claim that it was a 64 bit key, and
this was by Padgett Peterson, who is usually pretty good with facts,
though perhaps his claim was speculation in this case.  (I've added
him to the Cc).

His reasoning was that the 16 bit checksum (which Matt Blaze
demonstrated could be brute forced thereby trashing the GAK
enforcement) would come out of the 80bit key size, thereby meaning
that it was only an effective 64 bit key.  I suppose this claim if it
is correct would be similar to DES keys being 64 bit, but 8bits being
parity (checksum again), and therefor being only 56 bit effective.
The DES case would set a precedent for NSA design involvement using
larger "keys" than effective keys.  If this is true, the clipper /
skipjack system was even more flawed than we believed, as not only was
it possible to brute force the checksum, but the key space could have
been brute forced also, possibly without knowing the algorithm either,
just by buying lots of clipper chips (though I think this would
require knowledge of the checksum algorithm).  But clearly the NSA
could have brute forced the traffic in addition to having back doors.

Of course, I think it likely that the key was actually a 96 bit key
with an effictive key size of 80bits after the 16 bit checksum.

Regardless, if Padgett's speculation is correct, I suspect this is not
what Jon was thinking.

> > * With Clipper, there was a central repository of all the keys. With CMR,
> > there is not. I discussed that in detail in my message, "Why Corporate
> > Message Recovery isn't Key Escrow."
> 
> Once again, you haven't checked the record. Clipper keys were to be split, 
> with different halves going to different government agencies. There were
> fairly elaborate plans to prevent posession of only one half giving an
> attacker an advantage. Thus there were *two* repositories, not one. 
> (From the point of view of the paranoid, this was not much of a
> comfort - both repositories belonged to the same entity.)

I must defend Jon a little bit here in that it was fairly widely
agreed that the wording in some of the Clipper documents (perhaps
FOIAed, perhaps released normally, don't know) that the NSA would have
an extra access for "national security" (there's that magic root
password to the constitution again).  The presumtion a lot of people
held was that the NSA would have a second unified copy of the split
databasee to enable this national security access.  I'm not sure of
course that this is actually ever explicitly admitted anywhere, and it
could be that they would just have direct access to both split
databases, but I wouldn't really have thought this was the likely; I
suspect the NSA would've wanted access without others even with in
special wire-tapping courts knowing their tapping activities.

Whether or not this is what Jon was referring to I don't know.


I agree with the negative political aspects Peter expressed of PGP's
"GAK compliancy" (as I like to call it) in PGP's pgp5.5 & SMTP policy
enforcer.

I also think there is a purely technical security case to be made
against this architecture which I have tried to lay out clearly in my
post titled:

	Subject: negative security aspects of GAK compliancy

Peter made some security points about this also.  I think we should be
able to win the argument about GAK compliancy purely on technical
reasons.

The only vaguely logical objection I've seen to arguing against GAK
compliancy on political grounds was Hal Finney's assertion that
OpenPGP should move towards more generalised forms of key assertions
in the form of PolicyMaker-like key assertions (Matt Blaze has a paper
and system called PolicyMaker).

However PolicyMaker I suspect will be a long time coming, and may not
be supported by all vendors due to complexity, and in addition even
with PolicyMaker, the same political and security arguments against
actual use of PGP Inc's GAK compliancy field (or PolicyMaker
assertions to the same effect) still forcefully apply.  And there are
still in particular security and political arguments against
implementing corporate access to mail archives, or corporate
sent/received mail snooping by using the SMTP GAK compliancy policy
enforcer.

Lastly I would comment that it is sad that we on cypherpunks are
having to expend so much energy trying to persuade PGP Inc with it's
supposed pro-privacy stance, and supposedly pro-privacy employees,
that they should be working against GAK, and even to get them to
acknowledge that what they are doing is pro-GAK, and big brotherish is
an uphill struggle.

PGP Inc with their poor PR management, and hugely insensitive pro-GAK
moves mean that PGP Inc is pissing away Phil Zimmermann's good
reputation at a huge rate of knots.

Wake up PGP.  Look what you are becoming.

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`

-----BEGIN PGP SIGNED MESSAGE-----

    original message(s) follow my comments:

    1.  agreed that GAK is awful from a security standpoint. it is just
        a huge hole open to abuse by supposedly trusted escrow agents and
        the usual government dishonesty and deceit.

        on top of that, GAK is an unpardonable sin, with CAK not far
        behind.

    2.  CMR does not lead to GAK. let's get the terms correct as to what
        can be done, versus what will be done.

        a)  there will be companies who start with GAK/CAK since it is
            simple to issue an order of compliance.

        b)  there will be companies who need to maintain content audit
            trails a) to prove they either did or did not do as stated,
            b) development records, etc. for instance for patents, c)
            historical customer records.

            hopefully this class will use signature, communications,
            and individual or group storage keys.  the need for encryption
            is paramount on computer systems --it is the equivalent of
            the locked file cabinet, sometimes in a locked secure area.

        c)  PGP today can meet the requirements of GAK, CAK, CMR, or
            just about any format you wish --and make corporate control
            a reality. 

            I could have a crude, but workable control program which would 
            prevent the use of pgp standalone as well --and I could have it
            up and running by tonight.

            secondly, add a few modifications to sendmail, and trying to
            slip one through the system is history.

    stating that CMR leads to GAK is the same argument that mary jane
    starts the victim on the road to horse.  

        -how's that allegorical illusion to blow by keyword scanners?

    likewise, I still believe I would much rather see PGP, Inc. implement
    a SNMP system to mandate corporate policy which can be adjusted from
    zero for the libertarians to GAK for the unpardonable sinners.  at
    least the employees of the latter can protest the ignorance of 
    management; despite the general attitude that all management personnel
    are the south ends of northbound horses, management is interested in
    calm, productive employees.

    if the government does mandate GAK, and really gets serious about
    enforcing it, there will be a lot of changes, and I for one will
    trade my computer for something more necessary as I build a bunker to     
    protect myself and children --there will be no government about that 
    time, or at least a government we will recognize.

        attila out, again


-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: latin1
Comment: No safety this side of the grave. Never was; never will be

iQCVAwUBNEJawL04kQrCC2kFAQHBCQQAqr0jk2wilOVAx83ZBEyU9ZLzFp0WVk9F
AoWlZwefOxngL+iCZbalLdrr94CECmLes3ugmbDukQfyminSlFsVVSKMkRD64uRm
91giq52/FUPjH4mE1IJZsj/07F0/slydkDcsBI7awfvl8VFxbAGF0oJDY4fAHlz9
ZBpxvSoPewo=
=jdGv
-----END PGP SIGNATURE-----

on or about 971012:1153 
    Adam Back <aba@dcs.ex.ac.uk> was purported to have 
    expostulated to perpetuate an opinion:

+[Padgett, you're Cc'd because I'm quoting something you once claimed on
+Perry's list, I think]

+I agree with basically every word Peter Trei wrote.  It's not often you
+agree with a long post like that 100%, but I could not fault a single
+point.

+Contrast that to PGP's Jon Callas's recent posts where I found myself
+disagreeing with a large proportion of both technical and political
+points.

+Just a couple of nit-picky comments on various things, and some
+re-iteration of the technical arguments against GAK compliancy (to
+supplement Peter's good political arguments):

+> >* Clipper was a 64-bit key. CMR symmetric keys are full-strength keys (128
+> >bits or more), backed with a full-strength public key.
+> 
+> A word of advice: don't try to discuss Clipper in this forum without checking
+> your facts. Clipper used an 80 bit key.

+Clipper was definately advertised as a 80bit key, I agree.

+But I did once see someone else claim that it was a 64 bit key, and
+this was by Padgett Peterson, who is usually pretty good with facts,
+though perhaps his claim was speculation in this case.  (I've added him
+to the Cc).

+His reasoning was that the 16 bit checksum (which Matt Blaze
+demonstrated could be brute forced thereby trashing the GAK
+enforcement) would come out of the 80bit key size, thereby meaning that
+it was only an effective 64 bit key.  I suppose this claim if it is
+correct would be similar to DES keys being 64 bit, but 8bits being
+parity (checksum again), and therefor being only 56 bit effective. The
+DES case would set a precedent for NSA design involvement using larger
+"keys" than effective keys.  If this is true, the clipper / skipjack
+system was even more flawed than we believed, as not only was it
+possible to brute force the checksum, but the key space could have been
+brute forced also, possibly without knowing the algorithm either, just
+by buying lots of clipper chips (though I think this would require
+knowledge of the checksum algorithm).  But clearly the NSA could have
+brute forced the traffic in addition to having back doors.

+Of course, I think it likely that the key was actually a 96 bit key
+with an effictive key size of 80bits after the 16 bit checksum.

+Regardless, if Padgett's speculation is correct, I suspect this is not
+what Jon was thinking.

+> > * With Clipper, there was a central repository of all the keys. With CMR,
+> > there is not. I discussed that in detail in my message, "Why Corporate
+> > Message Recovery isn't Key Escrow."
+> 
+> Once again, you haven't checked the record. Clipper keys were to be split, 
+> with different halves going to different government agencies. There were
+> fairly elaborate plans to prevent posession of only one half giving an
+> attacker an advantage. Thus there were *two* repositories, not one. 
+> (From the point of view of the paranoid, this was not much of a
+> comfort - both repositories belonged to the same entity.)

+I must defend Jon a little bit here in that it was fairly widely agreed
+that the wording in some of the Clipper documents (perhaps FOIAed,
+perhaps released normally, don't know) that the NSA would have an extra
+access for "national security" (there's that magic root password to the
+constitution again).  The presumtion a lot of people held was that the
+NSA would have a second unified copy of the split databasee to enable
+this national security access.  I'm not sure of course that this is
+actually ever explicitly admitted anywhere, and it could be that they
+would just have direct access to both split databases, but I wouldn't
+really have thought this was the likely; I suspect the NSA would've
+wanted access without others even with in special wire-tapping courts
+knowing their tapping activities.

+Whether or not this is what Jon was referring to I don't know.


+I agree with the negative political aspects Peter expressed of PGP's
+"GAK compliancy" (as I like to call it) in PGP's pgp5.5 & SMTP policy
+enforcer.

+I also think there is a purely technical security case to be made
+against this architecture which I have tried to lay out clearly in my
+post titled:

+	Subject: negative security aspects of GAK compliancy

+Peter made some security points about this also.  I think we should be
+able to win the argument about GAK compliancy purely on technical
+reasons.

+The only vaguely logical objection I've seen to arguing against GAK
+compliancy on political grounds was Hal Finney's assertion that OpenPGP
+should move towards more generalised forms of key assertions in the
+form of PolicyMaker-like key assertions (Matt Blaze has a paper and
+system called PolicyMaker).

+However PolicyMaker I suspect will be a long time coming, and may not
+be supported by all vendors due to complexity, and in addition even
+with PolicyMaker, the same political and security arguments against
+actual use of PGP Inc's GAK compliancy field (or PolicyMaker assertions
+to the same effect) still forcefully apply.  And there are still in
+particular security and political arguments against implementing
+corporate access to mail archives, or corporate sent/received mail
+snooping by using the SMTP GAK compliancy policy enforcer.

+Lastly I would comment that it is sad that we on cypherpunks are having
+to expend so much energy trying to persuade PGP Inc with it's supposed
+pro-privacy stance, and supposedly pro-privacy employees, that they
+should be working against GAK, and even to get them to acknowledge that
+what they are doing is pro-GAK, and big brotherish is an uphill
+struggle.

+PGP Inc with their poor PR management, and hugely insensitive pro-GAK
+moves mean that PGP Inc is pissing away Phil Zimmermann's good
+reputation at a huge rate of knots.

+Wake up PGP.  Look what you are becoming.

+Adam


 --
 "When I die, please cast my ashes upon Bill Gates. 
     For once, let him clean up after me! " 

 "Experience keeps a dear school, but fools will learn in no other."     
        --Benjamin Franklin
 ______________________________________________________________________
 "attila" 1024/C20B6905/23 D0 FA 7F 6A 8F 60 66 BC AF AE 56 98 C0 D7 B0

Attila T. Hun wrote:

>         c)  PGP today can meet the requirements of GAK, CAK, CMR, or
>             just about any format you wish --and make corporate control
>             a reality.
> 
>             I could have a crude, but workable control program which would
>             prevent the use of pgp standalone as well --and I could have it
>             up and running by tonight.
> 
>             secondly, add a few modifications to sendmail, and trying to
>             slip one through the system is history.
> 
>     stating that CMR leads to GAK is the same argument that mary jane
>     starts the victim on the road to horse.

  One problem is that Corporations are learning that it is in their best
interests, and moreover, *possible*, to computerize access to private
employee information both on and off the jobsite.
  As well, corporations share information amongst themselves that they
do not share with even the employee in question.

  There was the case of a man who tested positive for AIDS when getting
a physical, etc., for company health insurance. The health insurer 
turned him down for coverage, and wouldn't tell him why, although they
told his employer and every other health agency in the world. The man's
wife contacted AIDS much later and is now going to die, as well. 

  Companies exist who *require* their employees to put in long, unpaid
hours, center their life around the company, yet regard all of the
employees communications, even during *unpaid* time, to be owned by
them. Then they will turn around and fire said employee when they
read his/her private email and find out there is a history of cancer
in the family, or some such, even if it is in their imagination.
  There are already cases of people being denied health coverage
because of 'pre-existing' conditions, based on the fact that their
company communications revealed that their great-grandfather had the
same disease, etc.

  These are just small examples off the top of my head, but I know I
see more and more use of private information gleaned from inside and
outside companies to determine everything from health coverage to
promotions.
  I personally know of a woman who has been consistently denied 
promotions because her company's investigation of her revealed that
many of her female relatives have a large number of children. When
she changed jobs, that information was actually sent to her new
employer. (Perhaps she could spend the next ten years of her life
suing someone/everyone, but that's no way to live.)

  The strange shit is already happening, and will increase, as the
Corporations feel that what is good for the Government Gander is
good for the Corporate Goose.

TruthMonger