Re: FIPS 140 service indicator revamp

Stephan Mueller <[email protected]> wrote:
> Could you please help me finding the function _gcry_thread_context_set_fsi?

It's in a branch:

   https://dev.gnupg.org/source/libgcrypt/history/gniibe%252Ft7340/

In the commit:

   https://dev.gnupg.org/rCfa87b8de038878704c381ac1e63cafee78e9b798

In the file:
   https://dev.gnupg.org/source/libgcrypt/browse/gniibe%252Ft7340/src/fips.c$81


My intention is that those two functions may be provided by
non-libgcrypt implementation.  In that case, replacing the functions by
use of ERRNO is possible.


Writhing the code, I thought about general cases; There could be
multiple causes for FIPS 140 compliance.

If we will change _gcry_kdf_derive with GCRY_KDF_PBKDF2 to finish its
computation under FIPS mode, possible causes are:

- passphrase length too small
- salt length too small
- iteration number is too small
- minimum key size is too small

I wonder if all of these should be recorded within the FIPS service
indicator.  It could be done by implementing a chain of causes (while
it's only "unsigned long" value now in my branch).

Shall I do something like:

 - recording a chain of causes within the FIPS service indicator
   (heavy implementation)

 - ERRNO implementation as an alternative (#ifdef, perhaps),
   only retains the last cause (or the first one)
   (light implementation)

My opinion is that exposing implementation detail (for ERRNO use) is not
good, at least for starting point.
--