xref: /netbsd/usr.bin/bdes/bdes.1 (revision c4a72b64)
1.\"	$NetBSD: bdes.1,v 1.9 2002/09/30 11:08:57 grant Exp $
2.\"
3.\" Copyright (c) 1991, 1993
4.\"	The Regents of the University of California.  All rights reserved.
5.\"
6.\" This code is derived from software contributed to Berkeley by
7.\" Matt Bishop of Dartmouth College.
8.\"
9.\" Redistribution and use in source and binary forms, with or without
10.\" modification, are permitted provided that the following conditions
11.\" are met:
12.\" 1. Redistributions of source code must retain the above copyright
13.\"    notice, this list of conditions and the following disclaimer.
14.\" 2. Redistributions in binary form must reproduce the above copyright
15.\"    notice, this list of conditions and the following disclaimer in the
16.\"    documentation and/or other materials provided with the distribution.
17.\" 3. All advertising materials mentioning features or use of this software
18.\"    must display the following acknowledgement:
19.\"	This product includes software developed by the University of
20.\"	California, Berkeley and its contributors.
21.\" 4. Neither the name of the University nor the names of its contributors
22.\"    may be used to endorse or promote products derived from this software
23.\"    without specific prior written permission.
24.\"
25.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
26.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
27.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
28.\" ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
29.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
30.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
31.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
32.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
33.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
34.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
35.\" SUCH DAMAGE.
36.\"
37.\"	@(#)bdes.1	8.1 (Berkeley) 6/29/93
38.\"
39.Dd December 1, 2001
40.Dt BDES 1
41.Os
42.Sh NAME
43.Nm bdes
44.Nd encrypt/decrypt using the Data Encryption Standard
45.Sh SYNOPSIS
46.Nm
47.Op Fl abdp
48.Op Fl F Ar N
49.Op Fl f Ar N
50.Op Fl k Ar key
51.Op Fl m Ar N
52.Op Fl o Ar N
53.Op Fl v Ar vector
54.Sh DESCRIPTION
55.Nm
56implements all DES modes of operation described in FIPS PUB 81,
57including alternative cipher feedback mode and both authentication
58modes.
59.Nm
60reads from the standard input and writes to the standard output.
61By default, the input is encrypted using cipher block chaining mode.
62Using the same key for encryption and decryption preserves plain text.
63.Pp
64All modes but the electronic code book mode require an initialization
65vector; if none is supplied, the zero vector is used.
66If no
67.Ar key
68is specified on the command line, the user is prompted for one (see
69.Xr getpass 3
70for more details).
71.Pp
72The options are as follows:
73.Bl -tag -width "-v vector" -compact
74.It Fl a
75The key and initialization vector strings are to be taken as ASCII,
76suppressing the special interpretation given to leading
77.Dq 0X ,
78.Dq 0x ,
79.Dq 0B ,
80and
81.Dq 0b
82characters.
83This flag applies to
84.Em both
85the key and initialization vector.
86.It Fl b
87Use electronic code book mode.
88This is not recommended for messages
89longer than 8 bytes, as patterns in the input will show through to the
90output.
91.It Fl d
92Decrypt the input.
93.It Fl F Ar N
94Use
95.Ar N Ns -bit
96alternative cipher feedback mode.
97Currently
98.Ar N
99must be a multiple of 7 between 7 and 56 inclusive (this does not conform
100to the alternative CFB mode specification).
101.It Fl f Ar N
102Use
103.Ar N Ns -bit
104cipher feedback mode.
105Currently
106.Ar N
107must be a multiple of 8 between 8 and 64 inclusive (this does not conform
108to the standard CFB mode specification).
109.It Fl k Ar key
110Use
111.Ar key
112as the cryptographic key.
113.It Fl m Ar N
114Compute a message authentication code (MAC) of
115.Ar N
116bits on the input.
117The value of
118.Ar N
119must be between 1 and 64 inclusive; if
120.Ar N
121is not a multiple of 8, enough 0 bits will be added to pad the MAC length
122to the nearest multiple of 8.
123Only the MAC is output.
124MACs are only available in cipher block chaining mode or in cipher feedback
125mode.
126.It Fl o Ar N
127Use
128.Ar N Ns -bit
129output feedback mode.
130Currently
131.Ar N
132must be a multiple of 8 between 8 and 64 inclusive (this does not conform
133to the OFB mode specification).
134.It Fl p
135Disable the resetting of the parity bit.
136This flag forces the parity bit of the key to be used as typed, rather than
137making each character be of odd parity.
138It is used only if the key is given in ASCII.
139.It Fl v Ar vector
140Set the initialization vector to
141.Ar vector ;
142the vector is interpreted in the same way as the key.
143The vector is ignored in electronic codebook mode.
144For best security, a different
145initialization vector should be used for each file.
146.El
147.Pp
148The key and initialization vector are taken as sequences of ASCII
149characters which are then mapped into their bit representations.
150If either begins with
151.Dq 0X
152or
153.Dq 0x ,
154that one is taken as a sequence of hexadecimal digits indicating the
155bit pattern;
156if either begins with
157.Dq 0B
158or
159.Dq 0b ,
160that one is taken as a sequence of binary digits indicating the bit pattern.
161In either case,
162only the leading 64 bits of the key or initialization vector
163are used,
164and if fewer than 64 bits are provided, enough 0 bits are appended
165to pad the key to 64 bits.
166.Pp
167According to the DES standard, the low-order bit of each character in the
168key string is deleted.
169Since most ASCII representations set the high-order bit to 0, simply
170deleting the low-order bit effectively reduces the size of the key space
171from
172.if t 2\u\s-356\s0\d
173.if n 2**56
174to
175.if t 2\u\s-348\s0\d
176.if n 2**48
177keys.
178To prevent this, the high-order bit must be a function depending in part
179upon the low-order bit; so, the high-order bit is set to whatever value
180gives odd parity.
181This preserves the key space size.
182Note this resetting of the parity bit is
183.Em not
184done if the key is given in binary or hex, and can be disabled for ASCII
185keys as well.
186.Pp
187The DES is considered a very strong cryptosystem hobbled by a short
188key, and other than table lookup attacks, key search attacks, and
189Hellman's time-memory tradeoff (all of which are very expensive and
190time-consuming), no practical cryptanalytic methods for breaking the
191DES are known in the open literature.
192As of this writing, the best
193known cryptanalytic method is linear cryptanalysis, which requires an
194average of
195.if t 2\u\s-343\s0\d
196.if n 2**43
197known plaintext-ciphertext pairs to succeed.
198Unfortunately for the DES, key search attacks (requiring only
199a single known plaintext-ciphertext pair and trying
200.if t 2\u\s-355\s0\d
201.if n 2**55
202keys on average) are becoming practical.
203.Pp
204As with all cryptosystems, the choice of keys and
205key security remain the most vulnerable aspect of
206.Nm "" .
207.Sh IMPLEMENTATION NOTES
208For implementors wishing to write software compatible with this program,
209the following notes are provided.
210This software is believed to be compatible with the implementation of the
211data encryption standard distributed by Sun Microsystems, Inc.
212.Pp
213In the ECB and CBC modes, plaintext is encrypted in units of 64 bits (8 bytes,
214also called a block).
215To ensure that the plaintext file is encrypted correctly,
216.Nm
217will (internally) append from 1 to 8 bytes, the last byte containing an
218integer stating how many bytes of that final block are from the plaintext
219file, and encrypt the resulting block.
220Hence, when decrypting, the last block may contain from 0 to 7 characters
221present in the plaintext file, and the last byte tells how many.
222Note that if during decryption the last byte of the file does not contain an
223integer between 0 and 7, either the file has been corrupted or an incorrect
224key has been given.
225A similar mechanism is used for the OFB and CFB modes, except that those
226simply require the length of the input to be a multiple of the mode size,
227and the final byte contains an integer between 0 and one less than the number
228of bytes being used as the mode.
229(This was another reason that the mode size must be a multiple of 8 for those
230modes.)
231.Pp
232Unlike Sun's implementation, unused bytes of that last block are not filled
233with random data, but instead contain what was in those byte positions in
234the preceding block.
235This is quicker and more portable, and does not weaken the encryption
236significantly.
237.Pp
238If the key is entered in ASCII, the parity bits of the key characters are set
239so that each key character is of odd parity.
240Unlike Sun's implementation, it is possible to enter binary or hexadecimal
241keys on the command line, and if this is done, the parity bits are
242.Em not
243reset.
244This allows testing using arbitrary bit patterns as keys.
245.Pp
246The Sun implementation always uses an initialization vector of 0
247(that is, all zeroes).
248By default,
249.Nm
250does too, but this may be changed from the command line.
251.Sh SEE ALSO
252.Xr crypt 3 ,
253.Xr getpass 3
254.Pp
255.Em "Data Encryption Standard" ,
256Federal Information Processing Standard #46,
257National Bureau of Standards,
258U.S. Department of Commerce,
259Washington DC
260(Jan. 1977).
261.Pp
262.Em "DES Modes of Operation" ,
263Federal Information Processing Standard #81,
264National Bureau of Standards,
265U.S. Department of Commerce
266Washington DC
267(Dec. 1980).
268.Pp
269Dorothy Denning,
270.Em "Cryptography and Data Security" ,
271Addison-Wesley Publishing Co.,
272Reading, MA
273\(co1982.
274.Pp
275Matt Bishop,
276.Em "Implementation Notes on bdes(1)" ,
277Technical Report PCS-TR-91-158,
278Department of Mathematics and Computer Science,
279Dartmouth College,
280Hanover, NH  03755
281(Apr. 1991).
282.Pp
283M.J. Wiener,
284.Em "Efficient DES Key Search" ,
285Technical Report 244,
286School of Computer Science,
287Carleton University
288(May 1994).
289.Pp
290Bruce Schneier,
291.Em "Applied Cryptography (2nd edition)" ,
292John Wiley \*[Am] Sons, Inc.,
293New York, NY
294\(co1996.
295.Pp
296M. Matsui,
297.Em "Linear Cryptanalysis Method for DES Cipher" ,
298Advances in Cryptology -- Eurocrypt '93 Proceedings,
299Springer-Verlag
300\(co1994.
301.Pp
302Blaze, Diffie, Rivest, Schneier, Shimomura, Thompson, and Wiener,
303.Em "Minimal Key Lengths for Symmetric Ciphers To Provide Adequate Commercial Security" ,
304Business Software Alliance,
305http://www.bsa.org/policy/encryption/cryptographers.html
306(January 1996).
307.Sh DISCLAIMER
308.Bd -literal
309THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
310ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
311IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
312ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
313FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
314DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
315OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
316HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
317LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
318OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
319SUCH DAMAGE.
320.Ed
321.Sh BUGS
322When this document was originally written, there was a controversy
323raging over whether the DES would still be secure in a few years.
324There is now near-universal consensus in the cryptographic community
325that the key length of the DES is far too short.
326The advent of
327special-purpose hardware could reduce the cost of any of the methods
328of attack named above so that they are no longer computationally
329infeasible; in addition, the explosive growth in the number and speed
330of modern microprocessors as well as advances in programmable logic
331devices has brought an attack using only commodity hardware into the
332realm of possibility.
333Schneier and others currently recommend using
334cryptosystems with keys of at least 90 bits when long-term security is
335needed.
336.Pp
337As the key or key schedule is stored in memory, the encryption can be
338compromised if memory is readable.
339Additionally, programs which display programs' arguments may compromise the
340key and initialization vector, if they are specified on the command line.
341To avoid this
342.Nm
343overwrites its arguments, however, the obvious race cannot currently be
344avoided.
345.Pp
346Certain specific keys should be avoided because they introduce potential
347weaknesses; these keys, called the
348.Em weak
349and
350.Em semiweak
351keys, are (in hex notation, where p is either 0 or 1, and P is either
352e or f):
353.Bd -literal -offset indent
3540x0p0p0p0p0p0p0p0p	0x0p1P0p1P0p0P0p0P
3550x0pep0pep0pfp0pfp	0x0pfP0pfP0pfP0pfP
3560x1P0p1P0p0P0p0P0p	0x1P1P1P1P0P0P0P0P
3570x1Pep1Pep0Pfp0Pfp	0x1PfP1PfP0PfP0PfP
3580xep0pep0pfp0pfp0p	0xep1Pep1pfp0Pfp0P
3590xepepepepepepepep	0xepfPepfPfpfPfpfP
3600xfP0pfP0pfP0pfP0p	0xfP1PfP1PfP0PfP0P
3610xfPepfPepfPepfPep	0xfPfPfPfPfPfPfPfP
362.Ed
363.Pp
364This is inherent in the DES algorithm (see Moore and Simmons,
365.Do
366Cycle structure of the DES with weak and semi-weak keys
367.Dc ,
368.Em "Advances in Cryptology \- Crypto '86 Proceedings" ,
369Springer-Verlag New York, \(co1987, pp. 9-32.)
370