Myriachan <myriachan@gmail.com> writes:

> Wouldn't this encourage the use of std::random_device, typically
> implemented as a cryptographically-secure random number generator, to
> seed an algorithm that is not cryptographically-secure, possibly
> making unaware programmers believe that they are doing correct
> procedures for generating keys?
>
> There's nothing wrong with using std::random_device to seed a typical
> random number generator, so long as you're aware that the result
> should not be considered secure for cryptography.

I don't know.  Neither `std::random_device` nor any of the engines are
cryptographically secure sources of randomness and the standard does not
suggest this.  Any code that attempts to do cryptography using any of
these tools is suspicious.  Of course, people are implementing broken
cryptography all the time and granted, *somebody will* think like you
anticipated it and misuse the tools.  But then again, in the absence of
the new possibility to seed, that somebody would probably have used a
single integer to seed the same engine so not much is lost.

On the other hand, if you *know* that your implementation of
`std::random_device` is indeed backed by a cryptographically secure
source of entropy -- which, to my knowledge, none of the popular
implementations attempts to promise -- you could use the new feature to
obtain key material like this

    std::array<std::uint32_t, 16> bytes;  // 512 bit
    std::random_device device {};
    device.generate(bytes.begin(), bytes.end());

which could be an alternative to the `getrandom(2)` call provided by
Linux.  But in the absence of a guarantee in the standard, I'd rather
use the platform-specific feature directly and fail hard if it is not
available than relying on some implementation-specific property that
silently falls back to non-secure randomness on some platforms.

I'd certainly not use libstdc++' `std::random_device` (which is the only
one where I know exactly how it is implemented) for cryptography.  And
the implementation is clear about this: `std::random_device::entropy`
always returns 0.  (Which is honest but, of course, not too useful.)

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

.

------=_Part_921_1370186215.1455305699394
Content-Type: multipart/alternative;
 boundary="----=_Part_922_1992834832.1455305699394"

------=_Part_922_1992834832.1455305699394
Content-Type: text/plain; charset=UTF-8

On Thursday, February 11, 2016 at 12:15:59 PM UTC-8, Moritz Klammler wrote:
>
> On the other hand, if you *know* that your implementation of
> `std::random_device` is indeed backed by a cryptographically secure
> source of entropy -- which, to my knowledge, none of the popular
> implementations attempts to promise
>

The big three implementations of std::random_device all use
cryptographically-secure algorithms by default:

libcxx uses arc4random on Linux, /dev/urandom on Mac OS X, rand_s on
Windows.

libstdc++ uses x86 rdrand if available, otherwise /dev/urandom.

MSVC STL uses rand_s -> RtlGenRandom -> ioctl on \Device\ksecdd.

Melissa

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_922_1992834832.1455305699394
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Thursday, February 11, 2016 at 12:15:59 PM UTC-8, Morit=
z Klammler wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On the other =
hand, if you *know* that your implementation of
<br>`std::random_device` is indeed backed by a cryptographically secure
<br>source of entropy -- which, to my knowledge, none of the popular
<br>implementations attempts to promise<br></blockquote><div><br>The big th=
ree implementations of std::random_device all use cryptographically-secure =
algorithms by default:<br><br>libcxx uses arc4random on Linux, /dev/urandom=
 on Mac OS X, rand_s on Windows.<br><br>libstdc++ uses x86 rdrand if availa=
ble, otherwise /dev/urandom.<br><br>MSVC STL uses rand_s -&gt; RtlGenRandom=
 -&gt; ioctl on \Device\ksecdd.<br><br>Melissa<br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

------=_Part_922_1992834832.1455305699394--
------=_Part_921_1370186215.1455305699394--

.

Myriachan <myriachan@gmail.com> writes:

> On Thursday, February 11, 2016 at 12:15:59 PM UTC-8, Moritz Klammler wrote:
>>
>> On the other hand, if you *know* that your implementation of
>> `std::random_device` is indeed backed by a cryptographically secure
>> source of entropy -- which, to my knowledge, none of the popular
>> implementations attempts to promise
>>
>
> The big three implementations of std::random_device all use
> cryptographically-secure algorithms by default:
>
> libcxx uses arc4random on Linux, /dev/urandom on Mac OS X, rand_s on
> Windows.
>
> libstdc++ uses x86 rdrand if available, otherwise /dev/urandom.
>
> MSVC STL uses rand_s -> RtlGenRandom -> ioctl on \Device\ksecdd.

If you `#define _GLIBCXX_USE_RANDOM_TR1`, `std::random_device` from
libstdc++ will use a deterministic random source (a default-seeded
Mersenne twister engine).  I don't know whether this is still true today
but at least in the past I was told that the default for MinGW builds
was to use this option (as there is no `/dev/urandom` on Windows).  I
wouldn't like my cryptography to break silently pretending that
everything is fine when compiled with the wrong version of the standard
library.

You could (partially) mitigate this risk if you check

    std::random_device device {};
    if (device.entropy() < 30.0)
      throw std::runtime_error {"too little entropy"};

but since libstdc++ and libc++ always report 0.0 entropy (which is
standards compliant) using this in portable code is basically equivalent
to not using `std::random_device` in the first place.  I also don't
think they would report 0 entropy if they wanted to advertise the use of
the random data for cryptography.

Furthermore, I wouldn't trust RDRAND as the only source of entropy for
my cryptography.  It is a good choice for generating non-deterministic
random numbers really fast so I like the fact that libstdc++ uses it but
since I cannot look into my chip to see whether it really uses hardware
entropy or just AES-encrypts a counter, I wouldn't want my life to
depend on good faith.  The technical data officially provided by Intel
looks sound but the pressure exercised by secret agencies on large
companies to subvert their cryptography has been too large as that I
would like to trust any closed system manufactured by them.  The fact
that the kernel hackers reported to have experienced "pressure" to
implement `/dev/random` exclusively via RDRAND [1] didn't really help
mollify me.  Of course, if you're using proprietary crypto software, you
can equally well use the RDRAND instruction for key generation, too.

My point is -- but I guess I'm repeating myself -- that the `<random>`
facilities are designed for numerical simulations and similar purposes
and excel in this area.  For cryptography, it is better to depend on
features that were explicitly designed for that purpose and fail loudly
when they are not available.

[1] https://plus.google.com/+TheodoreTso/posts/SDcoemc9V3J

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On s=C3=A1bado, 13 de fevereiro de 2016 18:46:14 PST Moritz Klammler wrote:
> The fact
> that the kernel hackers reported to have experienced "pressure" to
> implement `/dev/random` exclusively via RDRAND [1] didn't really help
> mollify me.  Of course, if you're using proprietary crypto software, you
> can equally well use the RDRAND instruction for key generation, too.

The "pressure" was because the engineers trying to get the feature in thoug=
ht=20
it was the best thing since sliced bread, so they couldn't understand how=
=20
others wouldn't want it.

One of the biggest problems with the pre-RDRAND kernel crypto was enough=20
entropy at boot time: the kernel wants to generate the boot id and a few ot=
her=20
random numbers in the first millisecond after being loaded, when it hasn't =
yet=20
loaded any device drivers so it can collect external entropy. Meanwhile, th=
e=20
processor has already been running for a least a couple billion cycles, so =
the=20
PRNG engine has enough entropy.

So the conversation went, "Dude, this solves your problem, why won't you ta=
ke=20
it?" "NSA may have got to you!" "You can inspect it with an electron=20
microscope"=20

You can fill in the gaps on LKML discussions after that.

[I'm calling Ted a little paranoid, but he's right that there's no reason=
=20
*not* to add additional sources of entropy when they're available. The=20
discussion was only when RDRAND was the only available source. Disclaimer: =
I=20
work for Intel]

--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-propos=
als/.

.