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

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

[Laszlo Ersek]

(resending, with my subscription to <openssl-users@openssl.org> completed)

Hi OpenSSL Developers,

(cross-posting <openssl-users@openssl.org> and <devel@edk2.groups.io>,)

OpenSSL commit [1] changed the representation of the "entropy amount" --
later renamed to "randomess" in [2] -- from "int" to "double". I've read
the commit message:

commit 853f757ecea74a271a7c5cdee3f3b5fe0d3ae863
Author: Bodo Möller <bodo@openssl.org>
Date:   Sat Feb 19 15:22:53 2000 +0000

    Allow for higher granularity of entropy estimates by using 'double'
    instead of 'unsigned' counters.
    Seed PRNG in MacOS/GetHTTPS.src/GetHTTPS.cpp.

    Partially submitted by Yoram Meroz <yoram@mail.idrive.com>.

and also checked "MacOS/GetHTTPS.src/GetHTTPS.cpp" at the same commit.
But, I'm none the wiser.

Can someone please explain what is gained by using a floating point type
here?

Is it really a relevant use case that entropy is fed from an external
source to OpenSSL such that truncating the amount to a whole number of
bits would cause significant lossage? (Admittedly, it could be relevant
if the individual randomness bit counts were in the (0, 1) interval,
both boundaries exclusive.)

Using floating point for randomness representation is a problem for
environments that prefer to avoid floating point altogether, such as
edk2 ("UEFI") firmware

Thanks,
Laszlo

[1] https://github.com/openssl/openssl/commit/853f757ecea7
[2] https://github.com/openssl/openssl/commit/f367ac2b2664

Re: [edk2-devel] why does RAND_add() take "randomness" as a "double"?

[Laszlo Ersek]

Hi,

On 05/21/19 16:15, Laszlo Ersek wrote:
> (resending, with my subscription to <openssl-users@openssl.org> completed)
> 
> Hi OpenSSL Developers,
> 
> (cross-posting <openssl-users@openssl.org> and <devel@edk2.groups.io>,)

I've received comments on the openssl-user mailing list, but
regrettably, all of those responses stripped the <devel@edk2.groups.io>
email address. So, AFAICS, none of the followup has reached
<devel@edk2.groups.io>. As a replacement, please see the thread at
<https://mta.openssl.org/pipermail/openssl-users/2019-May/010509.html>.

Thanks
Laszlo

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

[Paul Dale]

Double makes sense.  Entropy is often estimated as a real value.

E.g. we have the aforementioned coin flipper feeding data serially.
Adding each bit sequentially means 0.125 bytes of entropy per call.

Not the best example....

Pauli
-- 
Oracle
Dr Paul Dale | Cryptographer | Network Security & Encryption 
Phone +61 7 3031 7217
Oracle Australia


-----Original Message-----
From: Laszlo Ersek [mailto:lersek@redhat.com] 
Sent: Wednesday, 22 May 2019 12:15 AM
To: openssl-users@openssl.org
Cc: Jian J Wang <jian.j.wang@intel.com>; edk2-devel-groups-io <devel@edk2.groups.io>; Lu, XiaoyuX <xiaoyux.lu@intel.com>; Ard Biesheuvel <ard.biesheuvel@linaro.org>
Subject: why does RAND_add() take "randomness" as a "double"?

(resending, with my subscription to <openssl-users@openssl.org> completed)

Hi OpenSSL Developers,

(cross-posting <openssl-users@openssl.org> and <devel@edk2.groups.io>,)

OpenSSL commit [1] changed the representation of the "entropy amount" -- later renamed to "randomess" in [2] -- from "int" to "double". I've read the commit message:

commit 853f757ecea74a271a7c5cdee3f3b5fe0d3ae863
Author: Bodo Möller <bodo@openssl.org>
Date:   Sat Feb 19 15:22:53 2000 +0000

    Allow for higher granularity of entropy estimates by using 'double'
    instead of 'unsigned' counters.
    Seed PRNG in MacOS/GetHTTPS.src/GetHTTPS.cpp.

    Partially submitted by Yoram Meroz <yoram@mail.idrive.com>.

and also checked "MacOS/GetHTTPS.src/GetHTTPS.cpp" at the same commit.
But, I'm none the wiser.

Can someone please explain what is gained by using a floating point type here?

Is it really a relevant use case that entropy is fed from an external source to OpenSSL such that truncating the amount to a whole number of bits would cause significant lossage? (Admittedly, it could be relevant if the individual randomness bit counts were in the (0, 1) interval, both boundaries exclusive.)

Using floating point for randomness representation is a problem for environments that prefer to avoid floating point altogether, such as
edk2 ("UEFI") firmware

Thanks,
Laszlo

[1] https://github.com/openssl/openssl/commit/853f757ecea7
[2] https://github.com/openssl/openssl/commit/f367ac2b2664

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

[Ard Biesheuvel]

(remove openssl user list)

On Wed, 22 May 2019 at 03:48, Paul Dale <paul.dale@oracle.com> wrote:
>
> Double makes sense.  Entropy is often estimated as a real value.
>
> E.g. we have the aforementioned coin flipper feeding data serially.
> Adding each bit sequentially means 0.125 bytes of entropy per call.
>
> Not the best example....
>

It looks like the people saying double is a good idea didn't actually
look at the code. The double argument is compared to a size_t cast to
double, and assigned that same value under some conditions.

I think the problem is that the double argument is part of the RAND
API, so they cannot easily change it.

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

[Laszlo Ersek]

Hi OpenSSL Developers,

(cross-posting <openssl-users@openssl.org> and <devel@edk2.groups.io>,)

OpenSSL commit [1] changed the representation of the "entropy amount" --
later renamed to "randomess" in [2] -- from "int" to "double". I've read
the commit message:

commit 853f757ecea74a271a7c5cdee3f3b5fe0d3ae863
Author: Bodo Möller <bodo@openssl.org>
Date:   Sat Feb 19 15:22:53 2000 +0000

    Allow for higher granularity of entropy estimates by using 'double'
    instead of 'unsigned' counters.
    Seed PRNG in MacOS/GetHTTPS.src/GetHTTPS.cpp.

    Partially submitted by Yoram Meroz <yoram@mail.idrive.com>.

and also checked "MacOS/GetHTTPS.src/GetHTTPS.cpp" at the same commit.
But, I'm none the wiser.

Can someone please explain what is gained by using a floating point type
here?

Is it really a relevant use case that entropy is fed from an external
source to OpenSSL such that truncating the amount to a whole number of
bits would cause significant lossage? (Admittedly, it could be relevant
if the individual randomness bit counts were in the (0, 1) interval,
both boundaries exclusive.)

Using floating point for randomness representation is a problem for
environments that prefer to avoid floating point altogether, such as
edk2 ("UEFI") firmware

Thanks,
Laszlo

[1] https://github.com/openssl/openssl/commit/853f757ecea7
[2] https://github.com/openssl/openssl/commit/f367ac2b2664