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