MD5-HMAC 2x as slow after call to gcry_create_nonce

[Werner Koch]

On Thu, 28 Feb 2013 00:12, linux at paip.net said:
> This is odd.  It appears that if we call gcry_create_nonce in our
> program, subsequent calls to MD5-HMAC are about 2.5x as slow as when we
> don't.  The source for a test program is attached.  The second argument

It looks like you are bugged by this:

  /* The fast random pool function as called at some places in
     libgcrypt.  This is merely a wrapper to make sure that this module
     is initialized and to lock the pool.  Note, that this function is a
     NOP unless a random function has been used or _gcry_initialize (1)
     has been used.  We use this hack so that the internal use of this
     function in cipher_open and md_open won't start filling up the
     random pool, even if no random will be required by the process. */
  void
  _gcry_fast_random_poll (void)

It sounds as if you would like an option to disable this feature.  As
always, the problem is with libraries - an application might decide that
it can do without it but a library should not enforce such a policy.

You may be interested in this feature:

 * Added a random number generator to directly use the system's RNG.
   Also added an interface to prefer the use of a specified RNG.

 GCRYCTL_SET_PREFERRED_RNG_TYPE  NEW.
 GCRYCTL_GET_CURRENT_RNG_TYPE    NEW.
 GCRY_RNG_TYPE_STANDARD          NEW.
 GCRY_RNG_TYPE_FIPS              NEW.
 GCRY_RNG_TYPE_SYSTEM            NEW.

See this comment for some background info:

      /* After any initialization has been done we only allow to
         upgrade to the standard RNG (handled above).  All other
         requests are ignored.  The idea is that the application needs
         to declare a preference for a weaker RNG as soon as possible
         and before any library sets a preference.  We assume that a
         library which uses Libgcrypt calls an init function very
         early.  This way --- even if the library gets initialized
         early by the application --- it is unlikely that it can
         select a lower priority RNG.

         This scheme helps to ensure that existing unmodified
         applications (e.g. gpg2), which don't known about the new RNG
         selection system, will continue to use the standard RNG and
         not be tricked by some library to use a lower priority RNG.
         There are some loopholes here but at least most GnuPG stuff
         should be save because it calls src_c{gcry_control
         (GCRYCTL_SUSPEND_SECMEM_WARN);} quite early and thus inhibits
         switching to a low priority RNG.
       */
  


Shalom-Salam,

   Werner


-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.