in reply to Re: How to decrypt a file encrypted with vi -x or shell crypt
in thread How to decrypt a file encrypted with vi -x or shell crypt

There's crypt(1) and there's crypt(3). I am referring to crypt(1) i.e. the shell command, viz:
User Commands                                            crypt(1)

NAME
     crypt - encode or decode a file

SYNOPSIS
     crypt [ password ]

DESCRIPTION
     crypt encrypts and decrypts the contents of  a  file.  crypt
     reads  from  the  standard  input and writes on the standard
     output.  The password is a key  that  selects  a  particular
     transformation.   If  no  password is given, crypt demands a
     key from the terminal and turns off printing while  the  key
     is being typed in. crypt encrypts and decrypts with the same
     key:

          example% crypt key<clear.file> encrypted.file
          example% crypt key<encrypted.file | pr

     will print the contents of  clear.file.

     Files encrypted by crypt are compatible with  those  treated
     by the editors ed(1), ex(1), and vi(1) in encryption mode.

     The security of encrypted files depends  on  three  factors:
     the  fundamental method must be hard to solve; direct search
     of the key space must be infeasible; "sneak paths" by  which
     keys or cleartext can become visible must be minimized.

     crypt implements a  one-rotor  machine  designed  along  the
     lines  of  the  German Enigma, but with a 256-element rotor.
     Methods of attack on such machines are  widely  known,  thus
     crypt provides minimal security.

     The transformation of a key into the  internal  settings  of
     the  machine  is deliberately designed to be expensive, that
     is, to take a substantial fraction of a second  to  compute.
     However,  if  keys  are restricted to (say) three lower-case
     letters, then encrypted files can be read by expending  only
     a substantial fraction of five minutes of machine time.

     Since the key is an argument to the  crypt  command,  it  is
     potentially visible to users executing ps(1) or a derivative
     command.  To minimize this possibility, crypt takes care  to
     destroy  any  record  of the key immediately upon entry.  No
     doubt the choice of keys  and  key  security  are  the  most
     vulnerable aspect of crypt.

FILES
     /dev/tty
           for typed key

--
I'm Not Just Another Perl Hacker

  • Comment on Re^2: How to decrypt a file encrypted with vi -x or shell crypt

Replies are listed 'Best First'.
Re^3: How to decrypt a file encrypted with vi -x or shell crypt
by bronto (Priest) on Aug 27, 2004 at 10:38 UTC

    First, you should always say on which OS you are running: there is no crypt on my Linux box, but there is one (with the same man page as yours) on Solaris

    Second, you say:

    For the time being, I have advised him to backtick the shell's crypt command. I know that this is insecure by way of making the password visible to ps, but this will allow him to develop the rest of the script.

    but, wait! The man page also says:

    Since the key is an argument to the crypt command, it is potentially visible to users executing ps(1) or a derivative command. To minimize this possibility, crypt takes care to destroy any record of the key immediately upon entry. No doubt the choice of keys and key security are the most vulnerable aspect of crypt.

    so the problem with ps is limited by the program itself. What you should care of instead is that the algorithm is very easy to break, even with brute force attacks:

    crypt implements a one-rotor machine designed along the lines of the German Enigma, but with a 256-element rotor. Methods of attack on such machines are widely known, thus crypt provides minimal security.

    Therefore, if the contents of the file are really "sensitive", you really should discard vi - x and look for another option alltogether. There are a bunch of modules on CPAN that let you work with pgp: just choose the one that best fits your needs.

    Ciao!
    --bronto


    The very nature of Perl to be like natural language--inconsistant and full of dwim and special cases--makes it impossible to know it all without simply memorizing the documentation (which is not complete or totally correct anyway).
    --John M. Dlugosz