On November 17, 2021 6:31 PM, brian m. carlson wrote: > To: rsbecker@xxxxxxxxxxxxx > Cc: 'Jeff King' <peff@xxxxxxxx>; 'Carlo Arenas' <carenas@xxxxxxxxx>; > git@xxxxxxxxxxxxxxx > Subject: Re: [PATCH 1/2] wrapper: add a helper to generate numbers from a > CSPRNG > > On 2021-11-17 at 20:19:49, rsbecker@xxxxxxxxxxxxx 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
