[440] in cryptography@c2.net mail archive
question about using PGP in the workplace (fwd)
daemon@ATHENA.MIT.EDU (Michael C Taylor)
Tue Apr 1 18:51:11 1997
Date: Mon, 31 Mar 1997 10:10:16 -0400 (AST)
From: Michael C Taylor <mctaylor@mta.ca>
To: cryptography@c2.net
[Forwarded from efc-talk@efc.ca, Electronic Frontier Canada -MCT]
---------- Forwarded message ----------
Date: 27 Mar 1997 01:58:29 -0000
From: Baal <Baal@nym.alias.net>
To: efc-talk@insight.dcss.McMaster.CA
Subject: question about using PGP in the workplace
> From: djones@insight.dcss.McMaster.CA
> Subject: question about using PGP in the workplace
> Date: Fri, 14 Mar 97 13:44:58 EST
> From: djones@insight.dcss.McMaster.CA (David Jones)
> [ forwarded to efc-talk anonymously, at the request of the sender -- dj ]
> - - -
> As the use of PGP is becoming more and more widespread,
> I imagine that many companies (or company employees) are
> starting to use it for personal as well as work related matters.
> It would not seem totally unreasonable for a company
> in this situation to think about putting in place a
> company keyserver and perhaps implementing some sort of
> key escrow scheme.
I suspect that if employers think about it at all, their first impulse
would be to either:
1. Ban the use of encryption altogether; this would have the added
benefit of making keyword searches on email much, much easier.
2. If encryption is allowed, restrict its use to specified
circumstances and ban the use of their equipment and facilities for
any and all personal use, and mandate that all keys be escrowed.
As far as I'm aware, the vast majority of employers do not have policies
regarding the use of encryption. In fact I believe that most of them
don't even have explicit, written policies covering under what
circumstances they have access to employee email.
The best advice, as far as I am concerned, is for employees to just pay
for another account for your own private use, and use your employer's
account for business only.
> This would be to insure that were someone to leave the company,
> his/her business email could be deciphered so that the person's
> successor could get "full context". I'm wondering what are people's
> opinions/ideas on this kind of key escrow in the workplace.
> Perhaps employees of such a company should have two keys:
> one for work related matters (put into escrow), and
> one for personal stuff (*not* put into escrow)?
Well, personally, I think that key escrow sux! However, I'm not certain
that 'escrow' is the appropriate term here. More than likely, what will
happen is that the employer will supply employees with a copy of PGP
which has been set-up to automatically encrypt all outgoing messages
with a key held by the company.
Frankly, anyone who 'escrows' their private key, placing it into the
hands of a third party, needs their head examined. Remember, the
private key can be used for *signing* as well as encryption/decryption.
Handing out your private key is kind of like handing out blank
documents, with your signature already on it. Not something I'd advise
*anyone* doing.
Even the so-called "Business Edition" of PGP, which features
sign-only and encrypt-only keys, can be circumvented; all it takes it
a disk editor and one can change a single byte in the key to change it
from sign-only to both sign-and-encrypt.
The only possible scenario under which I would even *consider*
'escrowing' one or more of my private keys, would be though the use of a
program implementing a 'secret sharing' protocol, such as that devised
by Adi Shamir. Hal Finney's SECSPLIT accomplishes this.
>From the SecureDrive documentation, written by Edgar Swank:
[On backing up SecureDrive keys]
One possible solution is to use a "secret sharing" protocol such as
the Cypherpunk program Secure Split to split your keyfile into N
parts any M (M <= N) of which can reconstruct the original file,
but any fewer parts than M are useless. You can then send the N
parts to N friends on the net, some of whom will be outside your
country. Establish some protocol so you can tell your friend if
you're acting under duress, in which case he can refuse to return
the file, or (better) can return some other file, which will fail
to restore the original keyfile.
One location of this program is
ftp://idea.sec.dsi.unimi.it/pub/security/crypt/code/secsplit.zip
Here are some excerpts from the SECSPLIT documentation:
Shamir secret sharing
Based on "How to Share a Secret", by Adi Shamir, Communications
of the ACM, November, 1979, Volume 22, Number 11, page 612.
Copyright (C) 1993 Hal Finney, 74076.1041@compuserve.com.
Version 1.1, October, 1993.
This software is being placed in the public domain.
This program divides a file into n pieces, such that any k of
them are sufficient to reconstruct the original file, but that
k-1 pieces give NO information about the original file (except
its length).
It has been written for and tested on DOS and Unix systems.
[snip]
Shamir's algorithm relies on cryptographically strong,
unguessable, random numbers. This version of the program uses
the IDEA cryptographic algorithm used in the PGP encryption
program to generate its random numbers. This is thought to be a
strong source of random numbers. The main potential weakness is
in the initialization of the random number generator, which is
based on the contents of the file being split, along with the
current time of day. This should be an unguessable seed as long
as the contents of the file are not known by the attacker.
> Anyone on this list have any experience with this kind of thing?
> Opinions? Comments?
Seeing as I'm my own employer, I don't have a problem with my employer
reading my email... <g>
> Aside: this raises a midly annoying technical problem. PGP has an
> option called "ENCRYPTTOSELF" which when used means that your
> outgoing mail encrypted with someone else's key will also be encrypted
> using your own (so that you can read the copies of your outgoing mail
> that your mailer keeps). But there's no provisions for this
> "dual identity" thing...
Agreed, insofar as there is no *direct* method. However, one can
turn off the encrypt-to-self using the command-line argument
+encrypttoself=off.
What one can do, is to use 2 separate batch files to invoke PGP; one
which leaves encrypt-to-self on (where the corporate key is the 'self'),
the other which does not.
Encrypttoself is how the "Business Edition" of PGP handles corporate key
escrow; however I'm told that anyone who can modify an .ini file can get
around this--it's no big deal. For that matter, what's to stop an
employee from bringing in his *own* copy of PGP on a floppy disk, and
using that?
Baal <Baal@nym.alias.net>
1024/A21829FD 1995/07/10 PGP public key on keyservers
PGP Key Fingerprint: 5A 64 DB DB 2C FE C0 FE 63 A7 A3 59 58 DA A6 EA
