why does RAND_add() take "randomness" as a "double"?

[Jakob Bohm]

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