FIPS 140 service indicator revamp

Werner Koch wk at gnupg.org
Thu Nov 21 09:29:09 CET 2024


Hi!

Thanks for working on that.

+    default:
+      /* Record the reason of failure, in the indicator.
+       * Or putting GPG_ERR_NOT_SUPPORTED would be enough.  */
+      _gcry_thread_context_set_fsi ((unsigned long)((algo << 16) | subalgo));
+      break;

I think it is sufficient to return an error code and leave the subalgo
alone.  This would allow to use a pointer to a gpg_error_t variable
which is our common way of returning errors.

Or we change

  gpg_err_code_t _gcry_fips_indicator (unsigned long *p);

which currently always returns 0 to also or alternatively return the
service indicator value.  To avoid introducing a new function this is
not easy but in 1.12 we could add a new function as an alternative way
to return the value. Or we use an inline function.

To return a general failure (independent of the fsi state) we can use
any other error code.  We may - if really needed - also define a new
gpg_err_source_t value for FIPS to clarify that the error comes from the
fips interface.

Regarding debugging FIPS problems, log_debug or syslog can be used after
the library has been put into a verbose logging state.  This would allow
to track down which problem causes the FIPS failure.


Shalom-Salam,

   Werner


-- 
The pioneers of a warless world are the youth that
refuse military service.             - A. Einstein
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openpgp-digital-signature.asc
Type: application/pgp-signature
Size: 247 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gcrypt-devel/attachments/20241121/950fdb29/attachment.sig>


More information about the Gcrypt-devel mailing list