Newsgroups: sci.crypt
Path: msuinfo!caen!sdd.hp.com!network.ucsd.edu!qualcom.qualcomm.com!qualcom.qualcomm.com!karn
From: karn@qualcom.qualcomm.com (Phil Karn)
Subject: Re: Follow-up to Postings on DES Non-Randomness, Part I
Message-ID: <1992Jan20.173207.21197@qualcomm.com>
Sender: news@qualcomm.com
Nntp-Posting-Host: qualcom.qualcomm.com
Reply-To: karn@chicago.qualcomm.com
Organization: Qualcomm, Inc
References:  <3243@wet.UUCP>
Distribution: usa
Date: Mon, 20 Jan 1992 17:32:07 GMT
Lines: 27

In article <3243@wet.UUCP>, naga@wet.UUCP (Peter Davidson) writes:
|> > Expert mode?	Never heard of it.
|>  
|> This is Central Point Software's terminology.  Non-expert mode allows you
|> to recover the key whereas expert mode does not.  "Mode" is not used in the
|> same sense as in "ECB mode".  In fact CPS's implementation of DES is DES in
|> ECB mode.

|> [...]

|> PCSECURE implements DES only in ECB mode.  The Private Line and MERLIN have
|> ECB as their default mode, although they also implement CBC and other modes.
|> I did not "select" ECB for testing, I simply noticed the anomalies in the
|> byte value frequencies in files encrypted using the default modes of these
|> encryption programs and proceeded to investigate further.

Why pay good money for insecure commercial encryption software when
you can find free, public domain software (including source) that does
it right? My DES code (ucsd.edu, /hamradio/packet/ka9q/des/des.tar)
defaults to CBC mode (although ECB can be chosen as an option), is
fully compatible with the SunOS "des" command (it even runs faster),
works under both MS-DOS and UNIX, and does NOT have a silly
"non-expert" mode.

Please stop attacking the ECB straw man...

Phil
