Re: FIPS 140 service indicator revamp

Hello,

Thank you for your comment.

Stephan Mueller <[email protected]> wrote:
> I have only one comment: can I ask that the patch applies a fail-close 
> approach instead of a fail-open? I.e. teh indicator should be initialized to 
> return a failure and only if a known approved algorithm is found, it should be 
> set to 0.

I will do; I will change for a fail-close approach.

Let me confirm the whole picture.  Here are ongoing changes:

* Change 1: use of a new internal API for the FIPS service indicator.
  Current proposal is using thread local storage, with compiler support
  (__thread), to be conservative (not by modern C11 _Thread_local or C23
  thread_local).

* Change 2: new libgcrypt API for the FIPS service indicator (by macro
  and gcry_control with new number), for applications.

* Change 3: using the new internal API, modify libgcrypt; put
  initialization (of false), put update (of true) in a success path, for
  all relevant functions.

* Change 4 (possibly, some parts would be optional): modify libgcrypt so
  that it doesn't reject computation under FIPS mode for parameters, but
  continue to finish the computation.  After this change, it won't
  return an error for parameters issue (if it's not fatal), only setting
  a failure with the FIPS service indicator.

For a while, we keep current code around gcry_control with
GCRYCTL_FIPS_SERVICE_INDICATOR_* in libgcrypt, because there are already
some external code which use this API.
--