bdes man page on 4.4BSD

Man page or keyword search:  
man Server   1065 pages
apropos Keyword Search (all sections)
Output format
4.4BSD logo
[printable version]

BDES(1)								       BDES(1)

NAME
       bdes - encrypt/decrypt using the Data Encryption Standard

SYNOPSIS
       bdes [ -abdp ] [ -F N ] [ -f N ] [ -k key ]
	    [ -m N ] [ -o N ] [ -v vector ]

DESCRIPTION
       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  get‐
       pass(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.

       -d     Decrypt the input.

       -F     Use N-bit alternative cipher feedback mode.  Currently N must be
	      a	 multiple  of 7 between 7 and 56 inclusive (this does not con‐
	      form to the alternative CFB mode specification).

       -f     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     Use key as the cryptographic key.

       -m     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 out‐
	      put.  MACs are only available in cipher block chaining  mode  or
	      in cipher feedback mode.

       -o     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     Set the initialization vector to vector; the  vector  is	inter‐
	      preted  in  the  same  way as the key.  The vector is ignored in
	      electronic codebook mode.

       The key and initialization vector are taken as sequences of ASCII char‐
       acters which are then mapped into their bit representations.  If either
       begins with ``0X'' or ``0x'', that one is taken as a sequence of	 hexa‐
       decimal 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  pro‐
       vided, 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 256 to  248  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 very strong cryptosystem, and other than table
       lookup attacks, key search attacks, and Hellman's time-memory  tradeoff
       (all  of which are very expensive and time-consuming), no cryptanalytic
       methods for breaking the DES are known  in  the	open  literature.   No
       doubt  the  choice  of  keys  and  key security are the most vulnerable
       aspect of bdes.

IMPLEMENTATION NOTES
       For implementors wishing to write software compatible  with  this  pro‐
       gram,  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 cor‐
       rupted 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 con‐
       tains  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.

SEE ALSO
       crypt(1), crypt(3), getpass(3)

       Data Encryption Standard, Federal Information Processing Standard  #46,
       National	 Bureau	 of Standards, U.S. Department of Commerce, Washington
       DC (Jan. 1977)

       DES Modes of Operation, Federal Information  Processing	Standard  #81,
       National Bureau of Standards, U.S. Department of Commerce Washington DC
       (Dec. 1980)

       Dorothy Denning, Cryptography and Data  Security,  Addison-Wesley  Pub‐
       lishing Co., Reading, MA ©1982.

       Matt  Bishop,  Implementation  Notes  on bdes(1), Technical Report PCS-
       TR-91-158, Department of Mathematics and	 Computer  Science,  Dartmouth
       College, Hanover, NH  03755 (Apr. 1991).

DISCLAIMER
       THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
       ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
       IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
       ARE DISCLAIMED.	IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
       FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
       DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
       OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
       HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
       LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
       OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
       SUCH DAMAGE.

BUGS
       There is a controversy raging over whether the DES will still be secure
       in a few years.	The advent of special-purpose  hardware	 could	reduce
       the  cost  of any of the methods of attack named above so that they are
       no longer computationally infeasible.

       As the key or key schedule is stored in memory, the encryption  can  be
       compromised  if	memory is readable.  Additionally, programs which dis‐
       play programs' arguments may compromise the key and initialization vec‐
       tor,  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 poten‐
       tial 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 Cryptol‐
       ogy  -  Crypto  '86  Proceedings , Springer-Verlag New York, ©1987, pp.
       9-32.)

4.3 Berkeley Distribution	 June 29, 1993			       BDES(1)
[top]

List of man pages available for 4.4BSD

Copyright (c) for man pages and the logo by the respective OS vendor.

For those who want to learn more, the polarhome community provides shell access and support.

[legal] [privacy] [GNU] [policy] [cookies] [netiquette] [sponsors] [FAQ]
Tweet
Polarhome, production since 1999.
Member of Polarhome portal.
Based on Fawad Halim's script.
...................................................................
Vote for polarhome
Free Shell Accounts :: the biggest list on the net