On 21/05/2019 16:44, Salz, Rich via openssl-users wrote:
When I overhauled the RAND mechanism, I tried to deprecate this use of floating
point, in favor of just a number from 0 to 100 but was voted down.
It *is* stupid. Luckily, on a modern system with system-provided randomness to
seed the RNG, you never need this call.
Perhaps it would have been more acceptable to use a binary base,
instead of a decimal percentage, as there is nothing inherently
decimal about this value.
Good options inspired by other cryptographic libraries include:
- Number of bits of entropy passed in call (For example, a
perfectly balanced coin flipper could provide the 4 byte
values "head" or "tail" with an entropy of 1 bit).
- 256th of bits ditto (for example a coin flipper with a known
slight imbalance could report 252/256th of a bit for each flip
included in the buffer).
- 32th of bits ditto (makes the "100%" case equal to
(bytecount << 8)).
In each of those 3 cases, the internal measure of "entropy
left" would be in that same unit, and a compatibility mapping
for the old API would do the conversion of the double as a
pure inline macro that doesn't trigger "float used" compiler
magics in programs that don't use it.
Clarifying notes:
- The current limit of considering only 32 bytes of entropy
is an artifact of the current set of RNG algorithms, and
should not be exposed in the API design. For example
future addition of post-quantum algorithms may necessitate
having an RNG with an internal state entropy larger than
256 bits.
- Future RNG implementations may include logic to safely
accumulate obtained entropy into "batches" before updating
the RNG state, as this may have cryptographic benefits.
- The use of a dummy double to force the alignment of
structures and unions to the "highest known" value can
be trivially replaced by another type where it is not
already treated as "not actually floating point
operations" by the compiler. For example by passing
"-Ddouble=long long" as a compiler option.
- The use of floating point registers in CPU-specific
vector unit optimizations can be readily avoided by
a no-asm compile.
- Floating point calculations in test programs such as
"openssl speed" is not relevant to actual library use.
- On Linux x86, test programs that avoid all floating
point can be checked via the PF_USED_MATH flag or its
upcoming Linux 5.x replacement. This may be useful
in the test suite.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
