On Thu, Sep 09, 2004, Steve Hay wrote: > Dr. Stephen Henson wrote: > > >On Thu, Sep 09, 2004, Steve Hay wrote: > > > > > > > >>I've no idea what the ASN1_TYPE *param is, or where to get one from. I > >>had a look at EVP_CIPHER_param_to_asn1(), but it says that the cipher IV > >>in the ctx passed to it must be set when the call is made, which seems > >>to be a chicken-and-egg problem to me -- I haven't got the cipher IV yet ;) > >> > >>Any clues how to use PKCS5_v2_PBE_keyivgen() would be greatly appreciated. > >> > >> > >> > > > >The function itself is intended to be used to generate or supply various > >paramaters in an appropriate DER structure. > > > >The password based encryption functions are intended to be called via the > >EVP_PBE_CipherInit() interface which is very similar to EVP_CipherInit(). > >The ASN1_TYPE parameter comes from various places depending on the PBE > >algorithm in use. For PKCS#5 v2.0 PKCS5_pbe2_set() is used. This is primarily > >to allow the PBE stuff to be used in appropriate ASN1 structures. > > > >The IV is generated randomly and included in the structure. Currently there's > >no way to supply your own IV but that will be fixed at some point... > > > I'm afraid I don't know what "password based encryption" is, so I don't > know if this is the right thing to even be trying to do. It doesn't > sound like what I wanted... >
It one of various standards which convert a password into a key (and sometimes and IV). For various reasons it is not advisable to use a password directly as a key. > > > >Alternatively you can get at the "guts" of the function by using > >PKCS5_PBKDF2_HMAC_SHA1(). Then you have to generate your own salt and pass it > >to the function along with the password and interation count. > > > Sounds a little more hopeful. Where do I get the "salt" from? Would > randomly generating it lead to the same encryption/decryption problem as > with the IV above? Would hard-coding something in the source code > suffice or is that not advisable? > > However, PKCS5_PBKDF2_HMAC_SHA1() only seems to generate a key, not an > IV, but I already have a key -- it's the IV that I want! > > It may be worth taking a step back and reconsidering what I'm trying to > achieve. I'm just trying to create a program to encrypt (and later > decrypt) a plain text file. The user chooses (or more likely randomly > generates) a key and specifies this as the key to use when *building* > the program. > > I then discovered that the encryption/decryption functions require an IV > too, but still don't really know what an IV is... > > At the moment I'm trying to generate the IV, and also getting a new key, > from the "key" that the user has supplied, and I'm getting lost in all > sorts of things that I don't understand and wasn't expecting to > encounter -- passwords, IV's, salt, PKCS#5, etc :( > How is the "key" user supplied? Will then just input some human readable string or generate a random value in some way? > Is it necessary/advisable to generate a key+IV in this way, or would it > in fact suffice to have the user supply the IV too and just use the > given key+IV? > The IV is an initial value used by some ciphersuites. Unlike the key it is not sensitive information and can be included along with the message itself. So you might generate a random IV, write it out to a file, use it to initialize an encryption context then write out the encrypted data. At the other end you would read the IV from the file and use that. A salt is designed to avoid certain attacks on password based encryption. Specifically if the same password is used multiple times or if the password is vaguely guessable. Again you can generate a random value and prepend that to the data. Using a fixed value removes the protection a salt provides. Some password based encryption algorithms generate an IV too, others 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]
