On Thu, Sep 09, 2004, Charles B Cranston wrote: > Perhaps one way to think of the IV is that it is part of the key. > That is, the IV and key are used to encrypt, and then the (same) IV > and the (same) key can decrypt. It's just that if the IV is sent > in clear text ("included in the structure...") then it is not secret. > > One popular algorithm is to use MD5 to make a 128 bit hash of a > password string, then use 64 bits of it as an IV and the other 64 > bits of it as a DES key. So the IV and the key are innately related. > Of course you could use the first and second 64 bits of an SHA1 hash > just as well. In these cases, the IV can be regenerated from the > password string at decrypt time, as long as it is the same string :-) >
Just using the password hash as a key (this is still used from time to time) is vulnerable to dictionary or substitution attacks so it isn't recommended. Its primary weakness is that the same password always produces the same key and IV. If part of the plaintext is known (for example its a fixed or predictable header) then an attacker can produce a huge dictionary of ciphertexts in advance based on large numbers of common passwords of this plaintext. Then when the ciphertext is received the attacker compares it against the table and, if successful, can rapidly recover the password with a single dictionary lookup. For this reason a "salt" is used which is a random value which is used along with the password to derive the key. One simple way is to concatenate the salt with the password before passing it through a digest algorithm. This avoids the attack because the salt is generated each time and the same password will produce different keys. The attacker must not know the salt in advance: so using a fixed value for the salt is out. That's pretty much what PKCS#5 v1.0 uses. Newever applications should really use something like PKCS#5 v2.0 PBES2 which is known to be resistant to various attacks. Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Funding needed! Details on homepage. Homepage: http://www.drh-consultancy.demon.co.uk ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]