Quantcast

AES key generation

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

AES key generation

Cyanure
Hi,

AES symmetric keys are 128, 192 or 256 bits long.

Is there a function in OpenSSL that creates (generates) an AES key (probably using internal salt) with the desired length (128, 192 or 256 bits) ?

Thank You.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: AES key generation

Victor Duchovni
On Mon, Jan 05, 2009 at 05:06:29AM -0800, Cyanure wrote:

>
> Hi,
>
> AES symmetric keys are 128, 192 or 256 bits long.
>
> Is there a function in OpenSSL that creates (generates) an AES key (probably
> using internal salt) with the desired length (128, 192 or 256 bits) ?

Keys are either:

    - Random bit patterns generated using a suitable cryptograph (P)RNG,
      e.g. read from /dev/urandom or /dev/random.

    - Password-based but strengthened via a suitable KDF (key-derivation
      function). It is here that you combine a "salt" value with the user's
      password, and for this OpenSSL includes (the yet to be documented)
      PKCS5_PBKDF2_HMAC_SHA1 declared in <openssl/evp.h>

        int PKCS5_PBKDF2_HMAC_SHA1(const char *pass, int passlen,
                                   unsigned char *salt, int saltlen, int iter,
                                   int keylen, unsigned char *out);

      the iteration count is often 1000, but should probably be higher for
      new applications.

--
        Viktor.
______________________________________________________________________
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
|  
Report Content as Inappropriate

Re: AES key generation

Cyanure
Thank you for your quick answer.

I have another question concerning the salt. Are there any recommendation about the salt length or how the salt is generated ?

And for the iteration number, you said that it is recommended to have more that 1000 iterations. In wich magnitude ? 5000, 10 000, 100 000 !?

Victor Duchovni wrote
On Mon, Jan 05, 2009 at 05:06:29AM -0800, Cyanure wrote:

>
> Hi,
>
> AES symmetric keys are 128, 192 or 256 bits long.
>
> Is there a function in OpenSSL that creates (generates) an AES key (probably
> using internal salt) with the desired length (128, 192 or 256 bits) ?

Keys are either:

    - Random bit patterns generated using a suitable cryptograph (P)RNG,
      e.g. read from /dev/urandom or /dev/random.

    - Password-based but strengthened via a suitable KDF (key-derivation
      function). It is here that you combine a "salt" value with the user's
      password, and for this OpenSSL includes (the yet to be documented)
      PKCS5_PBKDF2_HMAC_SHA1 declared in <openssl/evp.h>

        int PKCS5_PBKDF2_HMAC_SHA1(const char *pass, int passlen,
                                   unsigned char *salt, int saltlen, int iter,
                                   int keylen, unsigned char *out);

      the iteration count is often 1000, but should probably be higher for
      new applications.

--
        Viktor.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    openssl-users@openssl.org
Automated List Manager                           majordomo@openssl.org
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: AES key generation

Victor Duchovni
On Tue, Jan 06, 2009 at 07:02:44AM -0800, Cyanure wrote:

> I have another question concerning the salt. Are there any recommendation
> about the salt length or how the salt is generated ?

ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-5v2/pkcs5v2_1.pdf

   4.1 Salt
    [ ... lots of text about multi-use keys ... ]
    [ ... recommends at least 64 bits of salt ... ]

Generate random salts at least 64 bits in length, but use more (128 should
be enough) if that's an option. Make the salt as random as possible.

> And for the iteration number, you said that it is recommended to have more
> that 1000 iterations. In wich magnitude ? 5000, 10 000, 100 000 !?

ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-5v2/pkcs5v2_1.pdf

    4.2 Iteration count

    An iteration count has traditionally served the purpose of increasing
    the cost of producing keys from a password, thereby also increasing
    the difficulty of attack. For the methods in this document, a minimum
    of 1000 iterations is recommended. This will increase the cost of
    exhaustive search for passwords significantly, without a noticeable
    impact in the cost of deriving individual keys.

Time the KDF on your systems and see how many iterations are practical
without signficant resource impact on legitimate use cases. If it is
practical to make the count configurable, do so, otherwise hard-code
a sensible value that is at least 1000.

The iteration count is a multiplier on the CPU cost of brute-force
dictionary attacks. If you are not sure that users are choosing "strong"
passwords (they rarely do), you want to make dictionary attacks difficult
by making individual password->key calculations sufficiently slow thereby
limiting the throughput of brute-force attacks.

If no legitimate system is computing multiple password-based keys per
second, you could set the iteration count to consume 10-100ms of CPU
on 2008 processors, this is likely much more than 1000 iterations.
At a guess 1000 iterations will be O(1ms) per key on a typical modern CPU.
This is based on "openssl speed sha1" reporting:

type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
sha1             18701.67k    49726.06k   104600.90k   141349.84k   157502.27k

or about 10^6 16-byte SHA1 ops per second, doing 1000 iterations of HMAC
is approximately 2000 SHA1 ops and so should take about 2ms. In many
applications 10,000 or even 100,000 may be practical provided no
legitimate "actor" needs to perform password->key comptutations at
a moderately high rate.

--
        Viktor.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Loading...