My own little replacement for the Unix crypt

From: beej (bj_at_con.sole)
Date: 02/28/04 

Date: Sat, 28 Feb 2004 09:47:18 -0500

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.