RE: [PATCH 1/2] wrapper: add a helper to generate numbers from a CSPRNG

[<rsbecker@nexbridge.com>]

On November 17, 2021 6:31 PM, brian m. carlson wrote:
> To: rsbecker@nexbridge.com
> Cc: 'Jeff King' <peff@peff.net>; 'Carlo Arenas' <carenas@gmail.com>;
> 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:
> > I missed this one... lrand48 is also not generally available. I don’t think it is
> even available on Windows.
> >
> > 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