Newsgroups: sci.crypt
Path: msuinfo!caen!sdd.hp.com!cs.utexas.edu!uunet!walter!qualcom.qualcomm.com!chicago.qualcomm.com!karn
From: karn@chicago.qualcomm.com (Phil Karn)
Subject: Re: Non-Randomness in DES-Encrypted Files
Message-ID: <1992Jan22.070628.9122@qualcomm.com>
Sender: news@qualcomm.com
Nntp-Posting-Host: chicago.qualcomm.com
Organization: Qualcomm, Inc
References: <3238@wet.UUCP> <1992Jan22.031638.5203@cco.caltech.edu>
Distribution: usa
Date: Wed, 22 Jan 1992 07:06:28 GMT
Lines: 23

In article <1992Jan22.031638.5203@cco.caltech.edu> heathh@cco.caltech.edu (Heath Ian Hunnicutt) writes:
>>(which, it will be noted, does not preserve the size of the file during
>>encryption) 
>	Your ignorance is showing.  Any DES algorithm must round the
>number of bytes in the plaintext message up to a multiple of 8.  This
>is usually done by padding the end with 0x00 or such.  I believe
>differences in this padding cause some of the differences between
>output in your next two examples.

The "DES algorithm" is a block cipher which is specifically defined to
operate on 8-byte blocks of ciphertext or plaintext. Many of the
programs that *apply* DES to arbitrary collections of bytes do
generate ciphertext that is slightly larger than the plaintext, but
this is a function of the mode in which DES is used and is not an
inherent property of DES itself. In fact, there are ways to use DES to
encrypt data *without* adding bytes.  Hardware stream encryption boxes
using the DES output or cipher feedback modes are one example; for
each byte you put in, you get exactly one byte out. This mode uses DES
quite inefficiently (it typically encrypts less than 8 user bytes per
DES encryption operation) so it is almost never used in software
implementations where DES runs much more slowly than in hardware.

Phil
