Newsgroups: sci.crypt
Path: msuinfo!uchinews!linac!att!cbnewsh!cbnewsh!wcs
From: wcs@cbnewsh.ATT.COM (Bill Stewart 908-949-0705 erebus.att.com!wcs)
Subject: Re: Why public domain encryption software may not be good enough.
Organization: AT&T Bell Labs Random Organization Name Generator
Distribution: na
Date: Fri, 31 Jan 1992 04:55:17 GMT
Message-ID: <WCS.92Jan30235517@cbnewsh.ATT.COM>
In-Reply-To: karn@qualcom.qualcomm.com's message of Thu, 30 Jan 1992 23: 23:49 GMT
References: <3269@wet.UUCP> <1992Jan30.232349.3454@qualcomm.com>
Sender: wcs@cbnewsh.cb.att.com (Bill Stewart 908-949-0705 erebus.att.com!wcs)
Lines: 58

Phil, Perry Metzger, and others have commented on Peter Davidson's
questions-with-implied-advertisement(:-), so I'll try to be brief here.

First of all, while I don't really trust software where I haven't seen
the source code, and while I'm comfortable writing shell scripts and C
programs to do what I want, I *do* think there's real value
in putting together a high-quality user interface or toolset that can
handle the common encryption problems with minimal effort.
It's even more valuable for the MS-DOS users, who don't have real pipes 
or adequate multi-tasking, and often aren't programmers.
If you can provide them with good-quality encryption, a good interface,
and sufficient reason to believe your company, that's a Good Thing.
Doing so in the public domain, with source, is even better, of course.
Doing so in the public domain, without source, is obviously untrustable.

Unlike Perry, I'm *not* convinced that a 7-line Perl script will
really wipe out a disk file, given an arbitrary collection of
pseudo-disk-drivers underneath, which may be compressing your data,
NFS-squawking-over-Ethernets, caching it without reuse-protecting,
re-shuffling the blocks on the fly for disk-seek optimization,
or copy-on-writing it onto WORM drives in a File Motel.
Once a file gets written to disk, trashing it in place is a good start,
but you can't trust it to be gone unless you certifiably trash your media.

Integrating encryption into an editor is (mildly) ugly, but it does
mean your cleartext isn't written onto disk, unless your system has
swapping or paging like most real OS's.  (MS-DOS users are safe here! :-)
Integrating it into disk drivers is interesting, depending on your key
management approach; there are people who make hardware encryptors as well.

Thanks for pointing out Norton's DISKREET; I'm more likely to trust
Norton than some random garage-company, and a convenient user interface helps.
Do you know how keys are handled?  Per file? Session? VirtualDrive?
  Phil> And last BUT NOT LEAST, there is no documentation on the format of the
  Phil> DISKREET encrypted file system. I have no reason to doubt Norton's
  Phil> ...[comments on trust and "oops" trapdoors]...
Yes.  I hate it when vendors do that.

  Phil> DISKREET does come with a "fast, proprietary, non-DES" encryption
  Phil> mode, but I think we don't need to say much more about that.

To give them a bit of slack, it's still slightly better than not using it,
though I'll use real encryption on my 99 MHz 586 palmtop when it arrives :-)
Sure, it won't stop the NSA or probably even a good non-professional,
but if some burglar rips off your computer and sells it, 
your typical stolen-computer chop-shop probably won't sell your data
to the highest bidder; reformatting it is less work.
And if the Secret Service busts down your door because one of your co-workers 
said something about politically incorrect drugs in alt.cybermud,
you've got some time and technical leverage to go to court with
before they can figure out how to read your private email,
and you can have your lawyer watch while they're doing it.

-- 
				Pray for peace;      Bill
#Bill Stewart +1-908-949-0705 erebus.att.com!wcs AT&T Bell Labs 4M312 Holmdel NJ

		... counting stars by candlelight ...
