FIPS stuff (was: Re: PyCrypto rant thread)

Wearing my standards-weenie hat:

>    1. The standards are often many years behind the state of the art.  For
>     example, FIPS 186-3, which finally allows DSA keys to be larger than
>   1024 bits, still hasn't been published in non-draft form.

The publicly-available draft of FIPS 186-3 has been published for
quite a while now. The reason it is not final has everything to do
with US government bureacracy, and nothing to do with any technical
part being tentative.  Many IETF RFCs, for example, point to drafts of
FIPS documents while we wait (and wait and wait) for "real"
publication.

>    2. Different standards tend to specify different algorithms for the
> same thing.  For example, FIPS 186-2 (DSS) specifies a particular
> algorithm for generating primes using SHA-1, but it's specific to       DSA
> and not very useful elsewhere.

The prime generation code is in Appendix A of Draft FIPS 186-3. It is
applicable to generating probable primes and provable primes for any
system, not just for DSA. Also, in -3, it allows the use of SHA-256,
-384, and -512 as well as -1.

> I don't want to add multiple
> prime-generation functions (thus increasing the risk of       implementation
> bugs) just to pass certification.

Quite right. You should have just one that is usable everywhere. That
is the whole point of FIPS 186-3 and NIST SP 800-90.

>    3. From what I understand (and the situation is not at all clear to me)
>     some ECC patents have been licensed for use by the U.S. Federal
> Government, but not for others to use.

Not correct. You can license patents for ECC from Certicom for
non-USGovt use. If you are making products for specific USGovt use,
you may be able to get a free sublicense from the USGovt.

> It sounds like the U.S.
> government is moving toward ECC, but I will not be adding
> patent-encumbered features that nobody can actually use just to pass
> certification.

That makes sense, but it is not relevant to getting certified. Most of
the products with FIPS 140-2 certifications do not do ECC at all.

>    4. Barely anyone uses "certifiable" code anyway.

That is a difficult statement to prove either way without looking at
the build chains for every product that is released. Also, don't
forget that Microsoft's CAPI is certified.

> IIRC, either Mozilla
>     Seamonkey or Firefox has a FIPS mode, but it's not enabled by
> default,

...which shows that they *do* use the certified code, they just don't
demand that users use it...

> and "turn on FIPS mode" has never been suggested as a
> workaround in any security advisory I have seen.  OpenSSL's FIPS
> certification didn't prevent the Debian PRNG bug.

Both of those, while completely true, are completely orthogonal to
whether or not certification is useful.  They only show that certified
code can be misused with the same gusto as non-certified code.

> Rather than worry about an unlikely certification that won't matter anyway,
> I would rather write a simpler, secure, state-of-the-art implementation and
> let others worry about maintaining certification-specific branches.

That sounds like a good plan. Having said that, it would great if you
could re-evaluate your hesitancy to use certifiable methods from the
FIPS and NIST SP 800 series in the base code itself, regardless of
whether or not you or anyone intends to spend the (large amount of)
time and effort to be FIPS 140 certified.

--Paul Hoffman