FIPS 140 service indicator revamp

[NIIBE Yutaka]

Hello, again,

I think that the behavior changes will be inevitably introduced, with
the FIPS 140 service indicator revamp.  Under the FIPS mode, currently,
(in many cases,) it rejects computation in existing code of libgcrypt.
After the revamp, libgcrypt API won't reject the computation, but a
FIPS-conscious application needs to check if it's compliant or not
(using gcry_get_fips_service_indicator macro).

Perhaps, we need to introduce compatible flag to keep old behavior for
an application expecting rejection.

NIIBE Yutaka <gniibe at fsij.org> wrote:
> I'm going to try #3 and #4 for gcry_md_buffer function.

This was done by the commit to master:

	3478caac62c712547f7c0e07f4cf9602bc317997

Then, I proceed to modifying a set of functions which starts with
gcry_md_open.

Modifying those, I realized that the approach with the internal API of

	fips_service_indicator
	fips_service_indicator_mark_sucess

doesn't work well.  That's because there may be multiple components
involved.  For example, external API gcry_pk_* function may call
internal _gcry_md_* functions.  External API gcry_mac_* function may
call internal _gcry_cipher_* functions, and/or _gcry_md_* functions.
Here, all calls should be compliant, not only one.  When there are
multiple calls, a single path including mark_sucess doesn't mean it's
compliant.

Because of this, I'd like to propose a different apporach with:

	fips_service_indicator
	fips_service_indicator_mark_non_compliant

That is, initially, it assumes it's compliant and when anything
non-compliant computation involved, it marks non-compliant.  In the
existing code of libgcrypt, it tries to reject non-compliant computation
actually, so, this approach matches well to the existing code.

Well, evaluating correctness with mark_success would be easier but this
approach limited to simple functions.


Attached are two patches.  One for the internal API change.  Another for
modifying a set of functions which starts with gcry_md_open.  An
application which expects rejection can use the
GCRY_MD_FLAG_REJECT_NON_FIPS with gcry_md_open.


It's tracked by:

    https://dev.gnupg.org/T7338
-- 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-fips-Change-the-internal-API-for-new-FIPS-service-in.patch
Type: text/x-diff
Size: 4519 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gcrypt-devel/attachments/20241212/8480d61b/attachment-0002.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-fips-md-Implement-new-FIPS-service-indicator-for-gcr.patch
Type: text/x-diff
Size: 10058 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gcrypt-devel/attachments/20241212/8480d61b/attachment-0003.patch>