On November 17, 2021 6:31 PM, brian m. carlson wrote:

To: rsbecker@nexbridge.com
Cc: 'Jeff King' <redacted>; 'Carlo Arenas' <redacted>;
git@vger.kernel.org
Subject: Re: [PATCH 1/2] wrapper: add a helper to generate numbers from a
CSPRNG

On 2021-11-17 at 20:19:49, rsbecker@nexbridge.com wrote:

quoted

I missed this one... lrand48 is also not generally available. I don’t think it is

even available on Windows.

quoted

If we need a generalized solution, it probably needs to be abstracted in git-

compat-util.h and compat/rand.[ch], so that the platform maintainers can
plug in whatever decent platform randomization happens to be available, if
any. We know that rand() is vulnerable, but it might be the only generally
available fallback. Perhaps get the compat layer in place with a test suite that
exercises the implementation before getting into the general git code base -
maybe based on jitterentropy or sslrng. Agree on an interface, decide on a
period of time to implement, send the word out that this needs to get done,
and hope for the best. I have code that passes FIPS-140 for NonStop ia64 (-
ish although not jitterentropy) and x86, and I'm happy to contribute some of
this.

I think in this case I'd like to try to stick with OpenSSL or other standard
interfaces if that's going to meet folks' needs.  I can write an HMAC-DRBG,
but getting entropy is the tricky part, and jitterentropy approaches are
controversial because it's not clear how unpredictable they are.  I'm also
specifically trying to avoid anything that's architecture specific like RDRAND,
since that means we have to carry assembly code, and on some systems
RDRAND is broken, which means that you have to test for that and then pass
the output into another CSPRNG.
I'm also not sure how maintainable such code is, since I don't think there are
many people on the list who would be familiar enough with those algorithms
to maintain it.  Plus there's always the rule, "Don't write your own crypto."

Using OpenSSL or system-provided interfaces is much, much easier, it means
users can use Git in FIPS-certified environments, and it avoids us ending up
with subtly broken code in the future.

I agree wholeheartedly. git in FIPS-certified environments is one of my actual goals - well, in this case, I am a proxy for my customers'. Sticking with OpenSSL would be far preferable to me than basically reimplementing what OpenSSL does. Even OpenSSH uses OpenSSL.

Regards,
Randall