FIPS 140 service indicator revamp

[NIIBE Yutaka]

Hello,

Thank you for your proposal with a patch.

David Sugar wrote:
> Libgcrypt implements a FIPS 140 service indicator to comply with the rules
> stipulated by FIPS 140-3. However, based on recent clarifications provided by
> NIST around the topic, the current implementation falls short of meeting these
> clarifications.
>
> The current service indicator "statically" returns the indicator whether an
> algorithm operates in a FIPS-compliant manner or not. This includes the
> indicator whether the cryptographic algorithm is an "approved" algorithm or
> not.
>
> The issue with this approach is that it is "static" in the sense that a caller
> asks libgcrypt whether algorithm X is approved or not. NIST clarified that
> such static behavior is not sufficient. NIST requests a "dynamic" indicator in
> the sense that during the processing of the actual request to perform a
> cryptographic operation, the indicator must be "generated" and "returned" to
> the caller. I.e. when the caller performs, say an RSA 1024 operation, that
> very API call is required to generate the indicator that the request was not
> FIPS compliant. Conversely, when the caller performs an RSA 2048 operation,
> that very API call must generate the indicator that it was an approved
> mechanism.

I see the situation.

Let us improve.  (Well, I don't have a skill for the better
wording/expression in English.  I use "us", meaning: gpg-team + you +
all, including its users.)

> Our solution we offer here is the use of the errno to convey the FIPS status
> indicator.

Could we ask you to reserve this decision, at this point?  I can imagine
the need for a thread local variable for the service indicator, but I
think that overloading ERRNO might be difficult to handle and/or
confusing for applications (library users).

For this, firstly, I propose the API of following:

	void _gcry_thread_context_set_fsi (unsigned long fsi);
	unsigned long _gcry_thread_context_get_fsi (void);
	unsigned long gcry_thread_context_get_fsi (void);

(Function name change/suggestion is welcome, here, fsi stands for FIPS
service indicator.)

Two functions are internal use for libgcrypt.  The last function is
exposed to libgcrypt users.

Implementation may be the one with ERRNO actually later, but for now,
let us hide and defer the implementation detail.

It's true that libgcrypt code-base doesn't yet have thread specific
context things; That's long-standing issue to be done.  Since libgcrypt
assumes C90+something (only) for build environment and tries to support
various OS and compilers, it would be tricky to implement.  For this
particular problem, I created a separate ticket (and a branch
gniibe/t7340):

	https://dev.gnupg.org/T7340

# So far, I found that use of pre-C99 non-standard __thread specifier
# seems work well.  Any feedback is welcome for this.

> The provided patch adjusts one cryptographic service to show the chosen
> approach. If we all agree, we will proceed in developing the patch series to
> cover the other services appropriately.

Thanks a lot for this constructive approach.

> - if the API return code is 0 -> errno contains the FIPS service indicator
>
> - if the API return code is != 0 -> errno contains the "regular" error
> indicator (i.e. the patch will not touch the errno)

Currently, I don't know if this is good.  My concern here is that this
will be a fundamental API change for libgcrypt users; I'm afraid it
requires changes for all/most applications.

In my opinion, two points are important.

* A function may be finished earlier, not completing the operation.
  In this case, the API return code should not be 0 (keeping the API).

* Introducing use of gcry_thread_context_get_fsi (after a function call)
  makes sense for FIPS certified applications to make sure if the
  function call of libgcrypt does not violate FIPS (new API).

			*	*	*

Well, may I ask for your patch also including a change of tests/t-kdf.c?
By doing so, it will be more clear to see how the change of libgcrypt
asks application changes.

--