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

On November 17, 2021 3:02 PM, Jeff King wrote:

On Tue, Nov 16, 2021 at 07:36:51PM -0800, Carlo Arenas wrote:

quoted

quoted

quoted

for the little amount of random data we need, it might be wiser to
fallback to something POSIX like lrand48 which is most likely to
be available, but of course your tests that consume lots of random
data will need to change.

Unfortunately that won't help. You have to seed lrand48 with
something, which usually means pid and/or timestamp. Which are
predictable to an attacker, which was the start of the whole
conversation. You really need _some_ source of entropy, and only the OS

can provide that.

quoted

again, showing my ignorance here; but that "something" doesn't need to
be guessable externally; ex: git add could use as seed contents from
the file that is adding, or even better mix it up with the other
sources as a poor man's /dev/urandom

Those contents are still predictable. So you've made the attacker's job a little
harder (now they have to block tempfiles for, say, each tag you're going to
verify), but haven't changed the fundamental problem.

It definitely would help in _some_ threat models, but I think we should strive
for a solution that can be explained clearly as "nobody can DoS your
tempfiles" without complicated qualifications.

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.

Randall