FIPS 140 service indicator revamp

[NIIBE Yutaka]

Hello,

In the gniibe/t7340 branch, I changed the
gcry_get_fips_service_indicator macro by commit of
c9ede5a4bb64681056d4ed5a0a4665ba8f4efa4c.

The change is:
==========================
It may return: GPG_ERR_INV_OP, GPG_ERR_NOT_SUPPORTED, or 0.

GPG_ERR_INV_OP: new FIPS service indicator is not implemented
(meaning it's old library).

GPG_ERR_NOT_SUPPORTED: something is non-compliant.

0: it's compliant.
==========================

It's a macro, so that we don't introduce any new ABI for this, but
because of that, GPG_ERR_INV_OP handling is needed in applications.

In tests/t-kdf.c, it goes like this:

          ec = gcry_get_fips_service_indicator ();
          if (ec == GPG_ERR_INV_OP)
            {
              fail ("gcry_kdf_derive test %d unexpectedly failed to check the FIPS service indicator.\n",
                    tvidx);
              continue;
            }

... and ec == 0 means it's compliant.

Let us confirm if we all agree this part of: how applications use the
new FIPS 140 service indicator feature (after the revamp); in the
applications, after success of a function, it calls
gcry_get_fips_service_indicator.  This will be the change from libgcrypt
to applications if they care about FIPS 140 compliance, and no other
changes are needed.  Important thing is that if applications don't care
about FIPS 140 compliance, no changes.


BTW, I noticed that:

  The posts by Stephan Mueller are not archived in lists.gnupg.org for
  some reason (I received four meassages in this thread).  And my emails
  to David Sugar resulted errors.

So, for this message, I put only a single recipient of gcrypt-devel.


Anyway, let us proceed...

Werner Koch <wk at gnupg.org> wrote:
> I think it is sufficient to return an error code and leave the subalgo
> alone.

Yes.  Stephan also says it's boolean.  I learned.

> 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.

I see.

For now, I distinguish two things: internal state (record) and external
boolean value.  Perhaps, internal state is also ok to be just boolean.
--