[PATCH 0/4] Differentiate use of non-compliant flags in the SLI
Lucas Mulling
lucas.mulling at suse.com
Thu Mar 6 19:37:14 CET 2025
On Wed Mar 5, 2025 at 10:20 PM -03, NIIBE Yutaka wrote:
> The idea here is that:
>
> * For existing FIPS conscious applications with libgcrypt, it assumes
> old API of static indicator; That is, use of
> GCRYCTL_FIPS_SERVICE_INDICATOR_CIPHER,
> GCRYCTL_FIPS_SERVICE_INDICATOR_MAC,
> GCRYCTL_FIPS_SERVICE_INDICATOR_MD,
> GCRYCTL_FIPS_SERVICE_INDICATOR_KDF,
> GCRYCTL_FIPS_SERVICE_INDICATOR_FUNCTION, and
> GCRYCTL_FIPS_SERVICE_INDICATOR_PK_FLAGS. It has the behaviors of
> rejecting non-compliant use in some places in supported functions,
> but not for other places. It is OK with old API, non-supported
> functions don't reject (like MD5 can be used).
>
> * For new FIPS conscious applications, there are new API to check the
> indicator. We are now introducing new API for 1.12, and
> forward-compatible implementation in 1.11.
>
> * Existing tests in tests/ are basically with old API (except
> t-fips-service-ind). Update will be done in master for 1.12 after
> 1.11 branch will be created.
Agreed, this makes sense, thanks for the fixes!
More information about the Gcrypt-devel
mailing list