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

On Mon, Oct 20, 2008 at 1:08 PM, Dwayne C. Litzenberger <[email protected]> wrote:
> On Mon, Oct 20, 2008 at 08:59:44AM -0700, Paul Hoffman wrote:
> Yes, and as far as I know, any certification effort would have to target
> FIPS 186-2, not the FIPS 186-3 draft.  That makes it difficult to implement
> a policy of avoiding weak algorithms, since the appropriate replacements
> might not be in the standard yet.

Not true. You could implement both, as many others who have gotten
certified have. You do not have to make any algorithm you consider
weak part of your shipping product.

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

So, don't do DSA. No one is forcing you to. Probably no one is even
asking you to. RSA is part of FIPS 186-2 and -3. You will be in good
company ignoring DSA completely. At least in the VPN field, almost no
one does DSA.

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

The other tangible benefit of swapping your current PRNG with one that
is FIPS-approved is that you will know that the PRNG you end up with
is correct. That is important to some users.  You would be amazed at
the number of hand-rolled PRNGs that people are sure are correct that
have flaws.

>> 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
> European, Russian, Japanese, and Chinese standards didn't specify different
> algorithms.

I have never heard of that, and I work with manufacturers who
implement at least the first three. Do you have any evidence of
differences in PRNG requirements?

> If I'm going to care about certification, why would I limit
> myself to the US standards?  I don't even live in the US.

No one said you you limit yourself to US standards. If you want to add
support for NESSIE, GOST, and Camillia, feel free to. (Sorry, I don't
know the name of the Chinese standard you referred to.)  I don't even
believe that *you* should try to get PyCrypto certified. I am
proposing that you use the best known crypto practices, and don't do
anything that would prevent someone else who wants to gat a
PyCrytpo-based system from spending the time and effort to get their
system certified, anywhere in the world.

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

Note that other crypto libraries include ECC, and it seems kind of
unlikely that they have licenses for them.

>> 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
> optional "FIPS mode" or "FIPS build", it seems like only a small fraction of
> users actually choose the certified/certifiable code over the "normal" code.

You seem to think there are two different code bases in all those
products. I have seen the opposite in all cases I have looked at.
Where there is a difference is that the "FIPS mode", by nature, puts a
boundary around the code it uses, but tht doesn't prevent the non-FIPS
mode from using the same code.

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

Fully agree with the first part, not at all with the second unless you
have any evidence.

> I treat FIPS and NIST special publications just like any other peer-reviewed
> source: useful, but tentative, and susceptible to errors, omissions,
> obsolescence and politics.

That's a healthy attitude.

> I'm certainly not going to make a special effort
> to avoid the standards,

Err, you said above that you weren't going to use the PRNG from FIPS
186-3, but instead use your own.

> but I have no intention of ever compromising the
> security of PyCrypto (or adding patent-encumbered code) just because some
> standard or certification process says I should.

Sounds fine.