encrypt - salt

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

encrypt - salt

Anant Rao
Hi,

I'm trying to encrypt non-password data with EVP_aes_256_cbc algo.

Here's what I'm currently doing:
I have the key already generated by some other means outside of my program - assume it's cryptographically strong. I'm, however, generating the IV with RAND_bytes within my program.

When I looked at an example of AES encryption on the page http://saju.net.in/code/misc/openssl_aes.c.txt , I see that there is a call to EVP_BytesToKey to generate the key and the IV.

My first question is if generating the IV this way is any stronger than calling RAND_bytes. Just looking at the signature of the function, I tend to think it is as it has an extra param "salt". If the answer is affirmative, then I plan to call the function (with some fixed salt) and use only IV out of it and ignore the key generated (as I already have the key from some external source as mentioned before). Is this a good/workable idea?

My second question is if EVP_BytesToKey's "count" param is used (by OpenSSL) in the key generation, IV generation or both.

Thanks!


Reply | Threaded
Open this post in threaded view
|

RE: encrypt - salt

Dave Thompson-5

EVP_BytesToKey implements (a tweak on) the original PKCS#5, which derived a key and IV

by iterated hashing of a (reusable but secret) password with random (i.e. unique) salt.

Given random salt this gives effectively random IV, but is unnecessarily complicated.

 

This was recognized as a not terribly good plan, and the improved PBKDF2 in PKCS#5v2

derives only the key in a slightly different way (iterated *HMAC* with salt *cumulated*)

leaving the IV, if any, as plain random outside the scope of the PBKDF2 primitive.

OpenSSL does implement PBKDF2, and can use it for PKCS#8 and PKCS#12 etc.,

but kept BytesToKey for compatibility with existing ‘enc’ files and ‘legacy’ (pre PKCS#8) keys.

(Which don’t even really use the iteration feature; they are hardcoded 1!)

 

Using BytesToKey with random salt to generate the IV is a waste of time,

and using it with fixed salt violates its specification. Just use random IV.

Unless you don’t trust your RNG. But in that case you’re better off fixing or

replacing the RNG, not trying weird things to prop it up.

 

BytesToKey (like PBKDF1) uses the one iteration count to produce data which is returned

for both key and IV. It does additional round(s) if and only if necessary, a PBKDF2-like tweak

not in standard PBKDF1, but still using the same count.

 

 

From: [hidden email] [[hidden email]] On Behalf Of Anant Rao
Sent: Saturday, May 10, 2014 21:58
To: [hidden email]
Subject: *** Spam *** encrypt - salt

 

Hi,

 

I'm trying to encrypt non-password data with EVP_aes_256_cbc algo.

 

Here's what I'm currently doing:

I have the key already generated by some other means outside of my program - assume it's cryptographically strong. I'm, however, generating the IV with RAND_bytes within my program.

 

When I looked at an example of AES encryption on the page http://saju.net.in/code/misc/openssl_aes.c.txt , I see that there is a call to EVP_BytesToKey to generate the key and the IV.

 

My first question is if generating the IV this way is any stronger than calling RAND_bytes. Just looking at the signature of the function, I tend to think it is as it has an extra param "salt". If the answer is affirmative, then I plan to call the function (with some fixed salt) and use only IV out of it and ignore the key generated (as I already have the key from some external source as mentioned before). Is this a good/workable idea?

 

My second question is if EVP_BytesToKey's "count" param is used (by OpenSSL) in the key generation, IV generation or both.

 

Thanks!

 

 

Reply | Threaded
Open this post in threaded view
|

Re: encrypt - salt

Hooman Fazaeli
On 5/16/2014 2:15 AM, Dave Thompson wrote:

EVP_BytesToKey implements (a tweak on) the original PKCS#5, which derived a key and IV

by iterated hashing of a (reusable but secret) password with random (i.e. unique) salt.

Given random salt this gives effectively random IV, but is unnecessarily complicated.

 

This was recognized as a not terribly good plan, and the improved PBKDF2 in PKCS#5v2

derives only the key in a slightly different way (iterated *HMAC* with salt *cumulated*)

leaving the IV, if any, as plain random outside the scope of the PBKDF2 primitive.

OpenSSL does implement PBKDF2, and can use it for PKCS#8 and PKCS#12 etc.,

but kept BytesToKey for compatibility with existing ‘enc’ files and ‘legacy’ (pre PKCS#8) keys.

(Which don’t even really use the iteration feature; they are hardcoded 1!)

 

Using BytesToKey with random salt to generate the IV is a waste of time,

and using it with fixed salt violates its specification. Just use random IV.

Unless you don’t trust your RNG. But in that case you’re better off fixing or

replacing the RNG, not trying weird things to prop it up.

 

BytesToKey (like PBKDF1) uses the one iteration count to produce data which is returned

for both key and IV. It does additional round(s) if and only if necessary, a PBKDF2-like tweak

not in standard PBKDF1, but still using the same count.

 


Which openssl function does key derivation based on PKCS#5v2?

-- 

Best regards.
Hooman Fazaeli
Reply | Threaded
Open this post in threaded view
|

Re: encrypt - salt

Tom Francis

On May 16, 2014, at 4:14 AM, Hooman Fazaeli <[hidden email]> wrote:

> On 5/16/2014 2:15 AM, Dave Thompson wrote:
>> EVP_BytesToKey implements (a tweak on) the original PKCS#5, which derived a key and IV
>> by iterated hashing of a (reusable but secret) password with random (i.e. unique) salt.
>> Given random salt this gives effectively random IV, but is unnecessarily complicated.
>>  
>> This was recognized as a not terribly good plan, and the improved PBKDF2 in PKCS#5v2
>> derives only the key in a slightly different way (iterated *HMAC* with salt *cumulated*)
>> leaving the IV, if any, as plain random outside the scope of the PBKDF2 primitive.
>> OpenSSL does implement PBKDF2, and can use it for PKCS#8 and PKCS#12 etc.,
>> but kept BytesToKey for compatibility with existing ‘enc’ files and ‘legacy’ (pre PKCS#8) keys.
>> (Which don’t even really use the iteration feature; they are hardcoded 1!)
>>  
>> Using BytesToKey with random salt to generate the IV is a waste of time,
>> and using it with fixed salt violates its specification. Just use random IV.
>> Unless you don’t trust your RNG. But in that case you’re better off fixing or
>> replacing the RNG, not trying weird things to prop it up.
>>  
>> BytesToKey (like PBKDF1) uses the one iteration count to produce data which is returned
>> for both key and IV. It does additional round(s) if and only if necessary, a PBKDF2-like tweak
>> not in standard PBKDF1, but still using the same count.
>>  
>>
> Which openssl function does key derivation based on PKCS#5v2?

Search the crypto/ subdirectory for occurrences of PKCS5_pbkdf2_set.  Basically, you use PKCS5_pbkdf2_set() to create an X509_ALGOR* to be passed to EVP_PBE_CipherInit (actually, you’d pass the algorithm member of the returned X509_ALGOR* as the first parameter to EVP_PBE_CipherInit), which can initialize an EVP_CIPHER_CTX* with the derived key so you can start encrypting/decrypting.  If you really need only the key, you might want to do something differently, since the actual key generation is not in a public method (IIRC).

TOM

> --
>
> Best regards.
> Hooman Fazaeli
>
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: encrypt - salt

michel-60
In reply to this post by Dave Thompson-5
Hi,

It is PKCS5_PBKDF2_HMAC(), in  crypto/evp/p5_crpt2.c

Le 16/05/2014 10:14, Hooman Fazaeli a écrit :
Which openssl function does key derivation based on PKCS#5v2?