Re: [Qemu-devel] [PATCH 3/6] crypto: use correct derived key size when timing pbkdf

[Eric Blake]

On 09/08/2016 11:27 AM, Daniel P. Berrange wrote:
> Currently when timing the pbkdf algorithm a fixed key
> size of 32 bytes is used. This results in inaccurate
> timings for certain hashes depending on their digest
> size. For example when using sha1 with aes-256, this
> causes us to measure time for the master key digest
> doing 2 sha1 operations per iteration, instead of 1.
> 
> Instead we should pass in the desired key size to the
> timing routine that matches the key size that will be
> used for real later.
> 
> Signed-off-by: Daniel P. Berrange <address@hidden>
> ---
>  crypto/block-luks.c       |  2 ++
>  crypto/pbkdf.c            | 10 +++++++---
>  include/crypto/pbkdf.h    |  6 +++++-
>  tests/test-crypto-pbkdf.c |  1 +
>  4 files changed, 15 insertions(+), 4 deletions(-)
> 

>  int qcrypto_pbkdf2_count_iters(QCryptoHashAlgorithm hash,
>                                 const uint8_t *key, size_t nkey,
>                                 const uint8_t *salt, size_t nsalt,
> +                               size_t nout,
>                                 Error **errp)
>  {
>      int ret = -1;
> -    uint8_t out[32];
> +    uint8_t *out;
>      long long int iterations = (1 << 15);
>      unsigned long long delta_ms, start_ms, end_ms;
>  
> +    out = g_new0(uint8_t, nout);

Why g_new0()? Aren't we going to immediately be overwriting its
contents, in which case g_new() is slightly faster?

Also, this changes from stack to heap for the sensitive memory, which
changes the analysis of how likely the memory is to be paged out
somewhere where we don't need spare copies floating around (if that is
indeed something we want to worry about).

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature