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`
participants (3)
-
Adam Back -
Bill Stewart -
markļ¼ unicorn.com