Re: FIPS 140 service indicator revamp

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

_______________________________________________
Gcrypt-devel mailing list
[email protected]
https://lists.gnupg.org/mailman/listinfo/gcrypt-devel

-----BEGIN PGP SIGNATURE-----

iIMEARYIACsWIQSHd0YfKgdOvEgNNZQZzByeCFsQegUCZz7vVQ0cd2tAZ251cGcu
b3JnAAoJEBnMHJ4IWxB6oQEBAJs+eI3581ZUHvucTrRGFDCVZVH5kLTxb+wek8ik
mfBKAP9+2agdr/2iFg/buNiMZjnTdZkrHXt5YWoUGSj5vNGvDg==
=MeGD
-----END PGP SIGNATURE-----