Re: My own little replacement for the Unix crypt

From: Lanny Ripple (lanny_at_cisco.com)
Date: 02/29/04

  • Next message: RPK: "CAST self-decrypting archive; RC6" 
    Date: Sat, 28 Feb 2004 23:08:37 -0600

    What does this solve? I can plug in any type of authentication
    module I want to *nix so your solution is as good as mine. (At
    some point under a password based scheme I have to map a username
    to a password and if the user's password is "banana" the best
    crypto in the world is useless.)

       -ljr

    beej wrote:
    > I wanted a simple, effective crypto program for *nix, and since 'crypt'
    > is weak and everything else seems to be either commercial (expensive) or
    > of questionable origin I decided to write my own. I'm not foolish
    > enough to try to design a crypto algorithm, so I snagged the source for
    > Skipjack and used that. Here are the basic steps my little prog
    > employs. Does anyone notice any obvious or serious flaws here? How
    > secure is this?
    >
    > 1. Get the names of the source and destination files from the user.
    > 2. Ask the user whether to encrypt or decrypt the source file.
    >
    > If we're encrypting...
    >
    > 3. Get a password from the user.
    > 4. Run the password through SHA to create a 160-bit irreversible hash.
    > 5. Use the hash to key a stream cipher.
    > 6. Call the stream cipher ten times, but instead of using the keystream
    > to encrypt any data, use the bytes to form a key for Skipjack.
    > 7. Grab the system time and use it to initialize the stock random number
    > generator that comes with Unix.
    > 8. Call the stock Unix random number generator eight times, and use the
    > bytes to form an initialization vector (for Cipher Block Chaining).
    > 9. Read in the source file and encrypt it with Skipjack in Cipher Block
    > Chaining mode, using the key and initialization vector created above.
    > At the same time, form a 32-bit CRC value using the plaintext.
    > 10. Dump the initialization vector, CRC value and ciphertext into the
    > destination file.
    >
    > If we're decrypting...
    >
    > 3. Get a password from the user.
    > 4. Run the password through SHA to create a 160-bit irreversible hash.
    > 5. Use the hash to key a stream cipher.
    > 6. Call the stream cipher ten times, but instead of using the keystream
    > to encrypt any data, use the bytes to form a key for Skipjack.
    > 7. Open the source file and read in the stored 32-bit CRC value and
    > initialization vector.
    > 8. Read in the rest of the source file and decrypt it with Skipjack in
    > Cipher Block Chaining mode, using the key created above and the
    > initialization vector from the file. At the same time, form a 32-bit
    > value from the plaintext.
    > 9. Dump the decrypted data to the destination file.
    > 10. If the CRC value from the source file doesn't match the CRC value
    > that was generated from the decrypted data, then tell the user that the
    > process failed (the password was probably wrong).
    >
    >
    > My own thoughts:
    >
    > 1. The user could supply a weak password. The program doesn't directly
    > use the password, so that offers a small degree of protection against a
    > bad password, but it would still be possible for an attacker to guess
    > passwords until the right one is found. I guess the only way to fix
    > this is to have the prog enforce some password rules.
    >
    > 2. The stock RNG routines that come with Unix are notoriously bad, but
    > does that really matter for the initialization vector? The IV is
    > basically meant to be "extra" data, and there's nothing random about
    > data in general, so there's no point in trying to make the IV
    > cryptographically strong.
    >
    > 3. Can the CRC (based on the original plaintext and stored as plaintext
    > with the encrypted data) be used to derive any of the original data? I
    > don't see how it could... But then, I'm not a mathematician.

  • Next message: RPK: "CAST self-decrypting archive; RC6"