On 22/05/2019 19:32, Dennis Clarke wrote:
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).
Let's drop the
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).
Let's drop the coin flipper. It was an off hand remark
I can understand why you may not want to break existing API. Why not add
another similar interface done the right way?
On 5/22/19, 1:11 PM, "openssl-users on behalf of Dr. Matthias St. Pierre"
wrote:
I think nobody of us needs to be convinced anymore that making it a
'double' was a bad
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
On 5/21/2019 9:48 PM, Paul Dale wrote:
Double makes sense. Entropy is often estimated as a real value.
Having a human readable calculation using floating point doesn't (to me)
mean that an API argument has to be a double.
From what I see in the code, the parameter 'double entropy' is used
On 5/21/2019 10:07 PM, Salz, Rich via openssl-users wrote:
>Then just set it to 1.0 and be done with it.
That hardly helps on systems that don't have floating point at all.
No it doesn't. Such systems aren't supported by OpenSSL. There are many
places were floating point is
>Then just set it to 1.0 and be done with it.
>That hardly helps on systems that don't have floating point at all.
No it doesn't. Such systems aren't supported by OpenSSL. There are many
places were floating point is used/supported.
Removing the second arg to RAND_add is the
"Salz, Rich via openssl-users" skrev: (21 maj 2019
17:27:44 CEST)
>>If it's a sarcasm, I'm missing the point.
>
>I was't being sarcastic, I was trying to show that the team, recently,
>still liked the use of floating point.
>
>>There are use cases when one wants to mix/add extra
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 &
On 5/21/19 3:27 PM, Salz, Rich via openssl-users wrote:
If it's a sarcasm, I'm missing the point.
I was't being sarcastic, I was trying to show that the team, recently, still liked the use of floating point.
There are use cases when one wants to mix/add extra randomness from,
On 5/21/19, 10:45 AM, "openssl-users on behalf of 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.
If it's a sarcasm, I'm missing the point.
>If it's a sarcasm, I'm missing the point.
I was't being sarcastic, I was trying to show that the team, recently, still
liked the use of floating point.
>There are use cases when one wants to mix/add extra randomness from, e.g.,
> an external source (that, for whatever reasons, is
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.
On 5/21/2019 10:15 AM, Laszlo Ersek wrote:
[snip]
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
14 matches
Mail list logo
