[Cryptography] randomness for libraries, e.g. OpenSSL
leichter at lrw.com
Wed Nov 30 07:18:12 EST 2016
>>>> As a corollary: We need to to inveigle the OS providers and
>>>> hardware providers to solve the problem.
>>> That. Rather than spending energy on solving the problem in code, which is a really hard objective because of many factors, some of which are listed below, put the energy into Inveiglement....
>> Ahem. Intel went and provided the hardware. And if you read the messages here ... you shouldn't trust it.
> Well. My advice was to trust it about five bits, on the assumption that
> Intel was both allowed and motivated to act in good faith, and didn't
> get sabotaged when it tried to do so.
Why five bits? What kind of attack leaves you with 5 bits of randomness, but no more?
If Intel was "allowed and motivated to act in good faith and didn't get sabotaged" then *all* the bits, produced at a very high rate, are good.
If Intel *was* somehow forced to cooperate, for all you know what's really in there is a DRNG based on, say, time and a wired-in unique 256-bit starting point. (The starting point might not be visible to anyone - but some TLA receives a list of all possible starting points, of which there will only be a couple of hundred billion at most, readily searchable.) Then you get *no* bits from the hardware.
You're pulling a number - 5 bits - out of thin air, without an attack model or any kind of theory to justify it. Looking more broadly ... that's what leads to these endless discussions. A number of years back, arguing from "engineering gut" that various sources had some "entropy", and that if you just mixed enough of them, the result had "enough entropy", might have been acceptable. There wasn't really any theoretical base to do better. But that's no longer true. John Denker, among others, has proposed mechanisms that produce "hard randomness" based on pretty solid physical assumptions. And we now even have a theory of mixers (combiners), some of it amazing recent.
I would suggest that we should be treating proposals to build random number sources based on unsupported assumptions pulled out of the air, and complex algorithms that no one can justify, in *exactly* the same way as we would treat a proposal to "strengthen" AES by making some small "obvious" improvements to its key scheduling algorithm.
More information about the cryptography