bdes - encrypt/decrypt using the Data Encryption Standard
bdes [-abdp] [-F N] [-f N] [-k key] [-m N] [-o N] [-v
vector]
bdes implements all DES modes of operation described in FIPS
PUB 81, including
alternative cipher feedback mode and both authentication modes.
bdes reads from the standard input and writes to the standard output. By
default, the input is encrypted using cipher block chaining
mode. Using
the same key for encryption and decryption preserves plain
text.
All modes but the electronic code book mode require an initialization
vector; if none is supplied, the zero vector is used. If no
key is specified
on the command line, the user is prompted for one (see
getpass(3)
for more details).
The options are as follows:
-a The key and initialization vector strings are to
be taken as
ASCII, suppressing the special interpretation
given to leading
``0X'', ``0x'', ``0B'' and ``0b'' characters.
This flag applies
to both the key and initialization vector.
-b Use electronic code book mode. This is not recommended for
messages longer than 8 bytes, as patterns in the
input will
show through to the output.
-d Decrypt the input.
-F N Use N-bit alternative cipher feedback mode. Currently N must
be a multiple of 7 between 7 and 56 inclusive
(this does not
conform to the alternative CFB mode specification).
-f N Use N-bit cipher feedback mode. Currently N must
be a multiple
of 8 between 8 and 64 inclusive (this does
not conform to
the standard CFB mode specification).
-k key Use key as the cryptographic key.
-m N Compute a message authentication code (MAC) of N
bits on the
input. The value of N must be between 1 and 64
inclusive; if
N is not a multiple of 8, enough 0 bits will be
added to pad
the MAC length to the nearest multiple of 8. Only the MAC is
output. MACs are only available in cipher block
chaining mode
or in cipher feedback mode.
-o N Use N-bit output feedback mode. Currently N must
be a multiple
of 8 between 8 and 64 inclusive (this does
not conform to
the OFB mode specification).
-p Disable the resetting of the parity bit. This
flag forces the
parity bit of the key to be used as typed, rather
than making
each character be of odd parity. It is used only
if the key
is given in ASCII.
-v vector Set the initialization vector to vector; the vector is interpreted
in the same way as the key. The vector is
ignored in
electronic codebook mode. For best security, a
different initialization
vector should be used for each file.
The key and initialization vector are taken as sequences of
ASCII characters
which are then mapped into their bit representations.
If either begins
with ``0X'' or ``0x'', that one is taken as a sequence
of hexadecimal
digits indicating the bit pattern; if either begins with
``0B'' or
``0b'', that one is taken as a sequence of binary digits indicating the
bit pattern. In either case, only the leading 64 bits of
the key or initialization
vector are used, and if fewer than 64 bits are
provided,
enough 0 bits are appended to pad the key to 64 bits.
According to the DES standard, the low-order bit of each
character in the
key string is deleted. Since most ASCII representations set
the high-order
bit to 0, simply deleting the low-order bit effectively
reduces the
size of the key space from 2**56 to 2**48 keys. To prevent
this, the
high-order bit must be a function depending in part upon the
low-order
bit; so, the high-order bit is set to whatever value gives
odd parity.
This preserves the key space size. Note this resetting of
the parity bit
is not done if the key is given in binary or hex, and can be
disabled for
ASCII keys as well.
The DES is considered a strong cryptosystem hobbled by a
short key, and
other than table lookup attacks, key search attacks, and
Hellman's timememory
tradeoff (all of which are expensive and time-consuming), no practical
cryptanalytic methods for breaking the DES are known
in the open
literature. As of this writing, the best known cryptanalytic method is
linear cryptanalysis, which requires an average of 2**43
known plaintextciphertext
pairs to succeed. Unfortunately for the DES, key
search attacks
(requiring only a single known plaintext-ciphertext
pair and trying
2**55 keys on average) are becoming practical.
As with all cryptosystems, the choice of keys and key security remain the
most vulnerable aspect of bdes.
For implementors wishing to write software compatible with
this program,
the following notes are provided. This software is believed
to be compatible
with the implementation of the data encryption standard distributed
by Sun Microsystems, Inc.
In the ECB and CBC modes, plaintext is encrypted in units of
64 bits (8
bytes, also called a block). To ensure that the plaintext
file is encrypted
correctly, bdes will (internally) append from 1 to 8
bytes, the
last byte containing an integer stating how many bytes of
that final
block are from the plaintext file, and encrypt the resulting
block.
Hence, when decrypting, the last block may contain from 0 to
7 characters
present in the plaintext file, and the last byte tells how
many. Note
that if during decryption the last byte of the file does not
contain an
integer between 0 and 7, either the file has been corrupted
or an incorrect
key has been given. A similar mechanism is used for
the OFB and CFB
modes, except that those simply require the length of the
input to be a
multiple of the mode size, and the final byte contains an
integer between
0 and one less than the number of bytes being used as the
mode. (This
was another reason that the mode size must be a multiple of
8 for those
modes.)
Unlike Sun's implementation, unused bytes of that last block
are not
filled with random data, but instead contain what was in
those byte positions
in the preceding block. This is quicker and more
portable, and
does not weaken the encryption significantly.
If the key is entered in ASCII, the parity bits of the key
characters are
set so that each key character is of odd parity. Unlike
Sun's implementation,
it is possible to enter binary or hexadecimal keys
on the command
line, and if this is done, the parity bits are not reset.
This allows
testing using arbitrary bit patterns as keys.
The Sun implementation always uses an initialization vector
of 0 (that
is, all zeroes). By default, bdes does too, but this may be
changed from
the command line.
crypt(3), getpass(3)
Data Encryption Standard, Federal Information Processing
Standard #46,
National Bureau of Standards, U.S. Department of Commerce,
January 1977,
Washington DC.
DES Modes of Operation, Federal Information Processing Standard #81,
National Bureau of Standards, U.S. Department of Commerce,
December 1980,
Washington DC.
Dorothy Denning, Cryptography and Data Security,
Addison-Wesley
Publishing Co., 1982, Reading, MA.
Matt Bishop, Implementation Notes on bdes(1), Technical Report PCSTR-91-158,
Department of Mathematics and Computer Science,
Dartmouth
College, April 1991, Hanover, NH 03755.
M.J. Wiener, Efficient DES Key Search, Technical Report 244,
School of
Computer Science, Carleton University, May 1994.
Bruce Schneier, Applied Cryptography (2nd edition), John
Wiley & Sons,
Inc., 1996, New York, NY.
M. Matsui, Linear Cryptanalysis Method for DES Cipher,
Springer-Verlag,
Advances in Cryptology -- Eurocrypt '93 Proceedings, 1994.
Blaze, Diffie, Rivest, Schneier, Shimomura, Thompson, and
Wiener, Minimal
Key Lengths for Symmetric Ciphers To Provide Adequate
Commercial
Security, Business Software Alliance, January 1996,
http://www.bsa.org/policy/encryption/cryptographers.html.
When this document was originally written, there was a controversy raging
over whether the DES would still be secure in a few years.
There is now
near-universal consensus in the cryptographic community that
the key
length of the DES is far too short. The advent of specialpurpose
hardware could reduce the cost of any of the methods of attack named
above so that they are no longer computationally infeasible;
in addition,
the explosive growth in the number and speed of modern microprocessors as
well as advances in programmable logic devices has brought
an attack
using only commodity hardware into the realm of possibility.
Schneier
and others currently recommend using cryptosystems with keys
of at least
90 bits when long-term security is needed.
As the key or key schedule is stored in memory, the encryption can be
compromised if memory is readable. Additionally, programs
which display
programs' arguments may compromise the key and initialization vector, if
they are specified on the command line. To avoid this bdes
overwrites
its arguments, however, the obvious race cannot currently be
avoided.
Certain specific keys should be avoided because they introduce potential
weaknesses; these keys, called the weak and semiweak keys,
are (in hex
notation, where p is either 0 or 1, and P is either e or f):
0x0p0p0p0p0p0p0p0p 0x0p1P0p1P0p0P0p0P
0x0pep0pep0pfp0pfp 0x0pfP0pfP0pfP0pfP
0x1P0p1P0p0P0p0P0p 0x1P1P1P1P0P0P0P0P
0x1Pep1Pep0Pfp0Pfp 0x1PfP1PfP0PfP0PfP
0xep0pep0pfp0pfp0p 0xep1Pep1pfp0Pfp0P
0xepepepepepepepep 0xepfPepfPfpfPfpfP
0xfP0pfP0pfP0pfP0p 0xfP1PfP1PfP0PfP0P
0xfPepfPepfPepfPep 0xfPfPfPfPfPfPfPfP
This is inherent in the DES algorithm (see Moore and Simmons, ``Cycle
structure of the DES with weak and semi-weak keys'',
Advances in
Cryptology - Crypto '86 Proceedings, Springer-Verlag New
York, (C)1987,
pp. 9-32.)
OpenBSD 3.6 June 29, 1993
[ Back ] |
