Re: PGP Employee on MKR

shamrock@cypherpunks.to wrote:

> OK, I must be missing something. How can it be more evil if the email
> isn't automatically sent to the owner of the MK key than if the email is
> automatically cd'ed?

Uh, don't understand the question. The issue is that it's being encrypted
to multiple keys for one recipient.

> Agreed. And so did PGP 2.x and any version of PGP that allows for
> encryption to multiple keys. Anybody can take the 2.6 source and hardcode
> in a second recipient key.

But, for the fifth or sixth time, _that isn't being shipped as standard 
by PGP_. 

> I read the recently  proposed alternatives
> and fail to see how they would prevent GMR any more than PGP's solution.
> All I saw were convoluted and frequently hasty designs, many of which
> lend themselves even more to GAK then what PGP did.

Really? I seem to recall Jon Callas saying my system 'redesigned CMR' 
but was simpler than theirs. The mere fact that CMR requires an enforcer 
implies that it's a convoluted and hasty design. 

> Once, (as many of you know IMHO it is a "once", not an "if")  GAK becomes
> mandatory, it can be implemented with 2.6 just a easy as
> with 5.5.

But it can't; for a start 2.6-based GAK won't interoperate with 
international versions the way that CMR will. Cutting the US off from
encrypted mail from the rest of the world would probably not go down
too well.

Lucky, one question: wouldn't you be complaining if Netscape or Microsoft
were shipping a system which enforced encryption to snooping keys? Why should 
we feel any differently about PGP?

    Mark

At 02:38 AM 10/27/1997 -0800, mark@unicorn.com wrote:
>Really? I seem to recall Jon Callas saying my system 'redesigned CMR' 
>but was simpler than theirs. The mere fact that CMR requires an enforcer 
>implies that it's a convoluted and hasty design. 

Not true - you can't implement CMR without a mail enforcer unless
you can stop your employees from using non-CMR versions of PGP,
which is nearly impossible.  Even with an enforcer, of course,
you can't stop the determined employee from double-encrypting and
steganizing and otherwise getting their outbound bits past your enforcer
looking like the baseball game narrative from Wayner's Mimic Functions
or Pointy-Haired-Boss randomness, but they could also carry a floppy disk 
out the door or beam infrared out the window from their Newton.

Similarly, on incoming mail, you can't stop people from sending your
employees non-CMRed mail without an inbound-mail enforcer and
can't stop your employees from reading it with their own warez.

More importantly, though, PGP isn't a mail program, it's an encryptor,
and if you're trying to stop people from sending encrypted mail
back and forth, you've got to control the mail system as well as the
encryptors, and you probably already _do_ control the mail system.

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

Bill Stewart <stewarts@ix.netcom.com> writes:
> At 02:38 AM 10/27/1997 -0800, mark@unicorn.com wrote:
> >Really? I seem to recall Jon Callas saying my system 'redesigned CMR' 
> >but was simpler than theirs. The mere fact that CMR requires an enforcer 
> >implies that it's a convoluted and hasty design. 
> 
> Not true - you can't implement CMR without a mail enforcer unless
> you can stop your employees from using non-CMR versions of PGP,
> which is nearly impossible.  Even with an enforcer, of course,
> you can't stop the determined employee from double-encrypting and
> steganizing and otherwise getting their outbound bits past your enforcer
> or Pointy-Haired-Boss randomness, 

If the corporate is serious about preventing encrypted messages
leaving their net that they can't read, the simple solution is to
disallow employees from using encryption -- have the enforcer encrypt
it.

Even if you were to use CMR, it is dumb, dumb, dumb, to allow the
snoop key to remain after the message has passed the enforcer -- it
should strip it off on the way out.

> but they could also carry a floppy disk out the door or beam
> infrared out the window from their Newton.

Attempting to compress the plaintext helps -- if it won't compress
(much) you get suspicious.

Pointy-Haired-Boss randomness always works -- compresses well and can
encode anything.

> Similarly, on incoming mail, you can't stop people from sending your
> employees non-CMRed mail without an inbound-mail enforcer and
> can't stop your employees from reading it with their own warez.

Even with enforcer and CMR it's possible to get past it,
super-encryption, garbage in CMRK second recipient field, and
Pointy-Haired-Boss randomness.

Simpler, safer, and more effective to just escrow the employees
company use key -- that ensures there is only one recipient on the
message passing over the internet.

> More importantly, though, PGP isn't a mail program, it's an encryptor,
> and if you're trying to stop people from sending encrypted mail
> back and forth, you've got to control the mail system as well as the
> encryptors, 

So ultimately prevention largely falls back to controlling what
software people are running inside the building -- no laptops in or
out, no floppies in or out, no installing software, metal detector at
door, body scan, the works.


Detection of sending encrypted mails is easier -- just try to decrypt
everything and have all keys necessary escrowed.  Anything which can't
be read doesn't make it in; anything sent which can't be read results
in a sacked employee.


Companies which aren't after this level of paranoia, but just want to
be able to recover company business mails queued when employee is away
-- fine have separate personal use keys attached to the same
signature key.

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`