Hello, Thank you for your comment.
Stephan Mueller <smuel...@chronox.de> 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. -- _______________________________________________ Gcrypt-devel mailing list Gcrypt-devel@gnupg.org https://lists.gnupg.org/mailman/listinfo/gcrypt-devel
