Re: FIPS stuff (was: Re: PyCrypto rant thread)

--ikeVEW9yuYc//A+q
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Oct 20, 2008 at 08:59:44AM -0700, Paul Hoffman wrote:
>Wearing my standards-weenie hat:
>
>>    1. The standards are often many years behind the state of the art.  F=
or
>>     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.

Yes, and as far as I know, any certification effort would have to target=20
FIPS 186-2, not the FIPS 186-3 draft.  That makes it difficult to implement=
=20
a policy of avoiding weak algorithms, since the appropriate replacements=20
might not be in the standard yet.

<rant>
DSA is a terrible signature algorithm, anyway.  If you ever have a=20
transient RNG failure while generating a DSA signature then your private=20
key is trivially (and permanently) compromised.  RSA only fails so=20
catastrophically during key generation.  Now that the patents on RSA have=
=20
expired, why should anyone use DSA in new applications?
</rant>

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

Sure, and that's great.  However, PyCrypto already has a PRNG, so using the=
=20
DSS prime-generation algorithm would require implementing *yet another=20
PRNG*.  The only tangible benefit of supporting the DSS prime-generation=20
algorithm is that it allows compact representation of the private key=20
(since you would only need to store the PRNG seed).

>> I don't want to add multiple
>> prime-generation functions (thus increasing the risk of       implementa=
tion
>> 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.

That's a very US-centric point of view.  I would be surprised if the=20
European, Russian, Japanese, and Chinese standards didn't specify different=
=20
algorithms.  If I'm going to care about certification, why would I limit=20
myself to the US standards?  I don't even live in the US.

>>    3. From what I understand (and the situation is not at all clear to=
=20
>>    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.

Sorry, I'm referring specifically to the patents that the NSA licensed.  As=
=20
far as I can tell, the NSA's license only covers U.S. federal government=20
use, not other uses.  That's what I meant.

As for being able to license patents separately from Certicom, I have no=20
motivation to help anyone who makes the software patent problem worse,=20
standards notwithstanding.  It's often a steep uphill battle to get=20
widespread adoption of any patent-encumbered crypto algorithm.  I want to=
=20
keep it that way.

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

Fair enough.  What I mean is that for the packages I've seen that have an=
=20
optional "FIPS mode" or "FIPS build", it seems like only a small fraction=
=20
of users actually choose the certified/certifiable code over the "normal"=
=20
code.

>Also, don't forget that Microsoft's CAPI is certified.

<rant>
Is that the same CAPI that gave us the massively brain-damaged=20
CryptGenRandom?  (http://eprint.iacr.org/2007/419)

That _anything_ written by Microsoft could be certified is exactly what's=
=20
wrong with the certification system: Certification doesn't make an=20
implementation secure.  It doesn't even make it reasonable to believe that =
=20
an implementation is secure.  Certification just makes it harder to fire=20
the moron who chose a "certified" implementation over a secure one.

I recently found out about a procurement process that was looking for a=20
full-disk encryption system that was FIPS 140 certified.  Did it matter=20
that FIPS 140 doesn't actually cover full-disk encryption?  Nope, and=20
products that weren't certified were dismissed without a second thought.
</rant>

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

It shows that the code is there, and that Mozilla is *huge*, not that the=
=20
code is widely used.

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

It suggests that certification status and number of security holes are=20
uncorrelated at best and inversely related at worst.

>> Rather than worry about an unlikely certification that won't matter anyw=
ay,
>> 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.

I treat FIPS and NIST special publications just like any other=20
peer-reviewed source: useful, but tentative, and susceptible to errors,=20
omissions, obsolescence and politics.  I'm certainly not going to make a=20
special effort to avoid the standards, but I have no intention of ever=20
compromising the security of PyCrypto (or adding patent-encumbered code)=20
just because some standard or certification process says I should.  I don't=
=20
care if Dual_EC_DRBG becomes a "mandatory" part of some standard; It's=20
still not getting into my tree.

--=20
Dwayne C. Litzenberger <[email protected]>
  Key-signing key   - 19E1 1FE8 B3CF F273 ED17  4A24 928C EC13 39C2 5CF7
  Annual key (2008) - 4B2A FD82 FC7D 9E38 38D9  179F 1C11 B877 E780 4B45

--ikeVEW9yuYc//A+q
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)

iEYEARECAAYFAkj85UEACgkQHBG4d+eAS0UtygCgsS0fdLFJLVtT2K54L2nMiKK7
skEAniIJ2iFWKXYcJAraqFY/WB1Ii/AM
=hV+P
-----END PGP SIGNATURE-----

--ikeVEW9yuYc//A+q--