| Sysop: | Amessyroom |
|---|---|
| Location: | Fayetteville, NC |
| Users: | 23 |
| Nodes: | 6 (0 / 6) |
| Uptime: | 40:45:38 |
| Calls: | 583 |
| Calls today: | 1 |
| Files: | 1,138 |
| Messages: | 110,393 |
Simulating a coin flip using C++'s <random> header file.
/*
* Compile in Visual studio:
* cl /EHsc /std:c++20 main.cpp */
#include <iostream>
#include <random>
using namespace std;
int main()
{
std::random_device random_device;
std::mt19937 random_engine{random_device()};
std::uniform_int_distribution<int> distribution{0, 1};
int heads = 0; int tails = 0;
for (int p = 0; p < 10000; p++)
{
int coinFlip = distribution(random_engine);
if (coinFlip == 0)
heads++;
else
tails++;
}
cout << "Heads: " << heads << " Tails: " << tails << endl; cout <<
"Heads: " << (double)heads*100/10000 << "% Tails: " << (double)tails*100/10000 << "%" << endl;
}
/*
* Typical output:
* Heads: 5066 Tails: 4934 * Heads: 50.66% Tails: 49.34%
*/
On Thu, 10 Jul 2025 17:19:03 +0000, Jack wrote:
Simulating a coin flip using C++'s <random> header file.
/*
* Compile in Visual studio:
* cl /EHsc /std:c++20 main.cpp */
#include <iostream>
#include <random>
using namespace std;
int main()
{
std::random_device random_device;
std::mt19937 random_engine{random_device()};
std::uniform_int_distribution<int> distribution{0, 1};
int heads = 0; int tails = 0;
for (int p = 0; p < 10000; p++)
{
int coinFlip = distribution(random_engine);
if (coinFlip == 0)
heads++;
else
tails++;
}
cout << "Heads: " << heads << " Tails: " << tails << endl; cout <<
"Heads: " << (double)heads*100/10000 << "% Tails: " <<
(double)tails*100/10000 << "%" << endl;
}
/*
* Typical output:
* Heads: 5066 Tails: 4934 * Heads: 50.66% Tails: 49.34%
*/
std::mt19937 is not cryptograhically secure, don't use it.
Mr Flibble <flibble@red-dwarf.jmc.corp> writes:
On Thu, 10 Jul 2025 17:19:03 +0000, Jack wrote:
Simulating a coin flip using C++'s <random> header file.
/*
* Compile in Visual studio:
* cl /EHsc /std:c++20 main.cpp */
#include <iostream>
#include <random>
using namespace std;
int main()
{
std::random_device random_device;
std::mt19937 random_engine{random_device()};
std::uniform_int_distribution<int> distribution{0, 1};
int heads = 0; int tails = 0;
for (int p = 0; p < 10000; p++)
{
int coinFlip = distribution(random_engine);
if (coinFlip == 0)
heads++;
else
tails++;
}
cout << "Heads: " << heads << " Tails: " << tails << endl; cout
<<
"Heads: " << (double)heads*100/10000 << "% Tails: " <<
(double)tails*100/10000 << "%" << endl;
}
/*
* Typical output:
* Heads: 5066 Tails: 4934 * Heads: 50.66% Tails: 49.34% */
std::mt19937 is not cryptograhically secure, don't use it.
It's perfectly suitable for flipping a coin, which cannot by any stretch
be considered "cryptography".
On Thu, 10 Jul 2025 18:25:46 +0000, Scott Lurndal wrote:
Mr Flibble <flibble@red-dwarf.jmc.corp> writes:
On Thu, 10 Jul 2025 17:19:03 +0000, Jack wrote:
Simulating a coin flip using C++'s <random> header file.
/*
* Compile in Visual studio:
* cl /EHsc /std:c++20 main.cpp */
#include <iostream>
#include <random>
using namespace std;
int main()
{
std::random_device random_device;
std::mt19937 random_engine{random_device()};
std::uniform_int_distribution<int> distribution{0, 1};
int heads = 0; int tails = 0;
for (int p = 0; p < 10000; p++)
{
int coinFlip = distribution(random_engine);
if (coinFlip == 0)
heads++;
else
tails++;
}
cout << "Heads: " << heads << " Tails: " << tails << endl; cout
<<
"Heads: " << (double)heads*100/10000 << "% Tails: " <<
(double)tails*100/10000 << "%" << endl;
}
/*
* Typical output:
* Heads: 5066 Tails: 4934 * Heads: 50.66% Tails: 49.34% */
std::mt19937 is not cryptograhically secure, don't use it.
It's perfectly suitable for flipping a coin, which cannot by any stretch
be considered "cryptography".
No it isn't.
random() % 2 after a suitable seed is sufficient for coin flipping.
If you're really fussed about random number generation and use linux then
you can do worse than use /dev/urandom or even better /dev/hwrng which uses the hardware rng on the CPU though for some reason seems to be root access only. Wierd.
Am 13.07.2025 um 09:50 schrieb Muttley@DastardlyHQ.org:
random() % 2 after a suitable seed is sufficient for coin flipping.
If you're really fussed about random number generation and use linux then
you can do worse than use /dev/urandom or even better /dev/hwrng which uses >> the hardware rng on the CPU though for some reason seems to be root access >> only. Wierd.
Why is /dev/hwrng root-only ? I guess on x86 it bases on the same
Am 13.07.2025 um 09:50 schrieb Muttley@DastardlyHQ.org:
random() % 2 after a suitable seed is sufficient for coin flipping.
If you're really fussed about random number generation and use linux then
you can do worse than use /dev/urandom or even better /dev/hwrng which
uses
the hardware rng on the CPU though for some reason seems to be root
access
only. Wierd.
Why is /dev/hwrng root-only ? I guess on x86 it bases on the same instructions you could access in userspace (RDRAND) without any
restrictions.
On 13/07/2025 10:29, Bonita Montero wrote:
Am 13.07.2025 um 09:50 schrieb Muttley@DastardlyHQ.org:
random() % 2 after a suitable seed is sufficient for coin flipping.
If you're really fussed about random number generation and use linux
then
you can do worse than use /dev/urandom or even better /dev/hwrng
which uses
the hardware rng on the CPU though for some reason seems to be root
access
only. Wierd.
Why is /dev/hwrng root-only ? I guess on x86 it bases on the same
instructions you could access in userspace (RDRAND) without any
restrictions.
Your guess may or may not be correct - there can be many hardware RNGs,
many of which are much better than cpu instructions.-a And on systems
that use something else for their hardware RNG, root-only access (by default) makes sense.
It may also be to discourage the use of such devices or cpu instructions
for code that needs cryptographically secure random sources.-a The
quality of CPU instruction random numbers has varied significantly
through the ages, and you'd be na|>ve to rely on it directly. /dev/
urandom is a better choice for almost anything involving security.
For coin-tossing, however, pretty much any reasonable pseudo-RNG will be fine.
On Sun, 13 Jul 2025 10:29:24 +0200
Bonita Montero <Bonita.Montero@gmail.com> wibbled:
Am 13.07.2025 um 09:50 schrieb Muttley@DastardlyHQ.org:
random() % 2 after a suitable seed is sufficient for coin flipping.
If you're really fussed about random number generation and use linux then >>> you can do worse than use /dev/urandom or even better /dev/hwrng which uses >>> the hardware rng on the CPU though for some reason seems to be root access >>> only. Wierd.
Why is /dev/hwrng root-only ? I guess on x86 it bases on the same
No idea, seems odd. Maybe its just the way its set up on the machine I have >access to right now. I'll check on other distros when I get a chance.
Am 13.07.2025 um 14:32 schrieb David Brown:
On 13/07/2025 10:29, Bonita Montero wrote:
Am 13.07.2025 um 09:50 schrieb Muttley@DastardlyHQ.org:
random() % 2 after a suitable seed is sufficient for coin flipping.
If you're really fussed about random number generation and use linux
then
you can do worse than use /dev/urandom or even better /dev/hwrng
which uses
the hardware rng on the CPU though for some reason seems to be root
access
only. Wierd.
Why is /dev/hwrng root-only ? I guess on x86 it bases on the same
instructions you could access in userspace (RDRAND) without any
restrictions.
Your guess may or may not be correct - there can be many hardware RNGs,
many of which are much better than cpu instructions.-a And on systems
that use something else for their hardware RNG, root-only access (by
default) makes sense.
It may also be to discourage the use of such devices or cpu instructions
for code that needs cryptographically secure random sources.-a The
quality of CPU instruction random numbers has varied significantly
through the ages, and you'd be na|>ve to rely on it directly. /dev/
urandom is a better choice for almost anything involving security.
So why is /dev/urandom accessible for anyone if it has comparable
quality ?
On Sun, 13 Jul 2025 14:32:24 +0200
David Brown <david.brown@hesbynett.no> wibbled:
that use something else for their hardware RNG, root-only access (by >>default) makes sense.
It may also be to discourage the use of such devices or cpu instructions >>for code that needs cryptographically secure random sources. The
quality of CPU instruction random numbers has varied significantly
through the ages, and you'd be na|>ve to rely on it directly.
/dev/urandom is a better choice for almost anything involving security.
urandom is most definately not as secure as hwrng as its purely software >driven with all the issues that entails.
Muttley@DastardlyHQ.org writes:
On Sun, 13 Jul 2025 10:29:24 +0200
Bonita Montero <Bonita.Montero@gmail.com> wibbled:
Am 13.07.2025 um 09:50 schrieb Muttley@DastardlyHQ.org:
random() % 2 after a suitable seed is sufficient for coin flipping.
If you're really fussed about random number generation and use linux then >>>> you can do worse than use /dev/urandom or even better /dev/hwrng which uses
the hardware rng on the CPU though for some reason seems to be root access >>>> only. Wierd.
Why is /dev/hwrng root-only ? I guess on x86 it bases on the same
No idea, seems odd. Maybe its just the way its set up on the machine I have >> access to right now. I'll check on other distros when I get a chance.
the rngd daemon reads /dev/hwrng which provides entropy for
the rngd which provides data to /dev/urandom and /dev/random
(which augment the HW entropy with kernel entropy). Applications
should use /dev/urandom or /dev/random.
Am 13.07.2025 um 14:32 schrieb David Brown:
On 13/07/2025 10:29, Bonita Montero wrote:
Am 13.07.2025 um 09:50 schrieb Muttley@DastardlyHQ.org:
random() % 2 after a suitable seed is sufficient for coin flipping.
If you're really fussed about random number generation and use linux
then
you can do worse than use /dev/urandom or even better /dev/hwrng
which uses
the hardware rng on the CPU though for some reason seems to be root
access
only. Wierd.
Why is /dev/hwrng root-only ? I guess on x86 it bases on the same
instructions you could access in userspace (RDRAND) without any
restrictions.
Your guess may or may not be correct - there can be many hardware
RNGs, many of which are much better than cpu instructions.-a And on
systems that use something else for their hardware RNG, root-only
access (by default) makes sense.
It may also be to discourage the use of such devices or cpu
instructions for code that needs cryptographically secure random
sources.-a The quality of CPU instruction random numbers has varied
significantly through the ages, and you'd be na|>ve to rely on it
directly. /dev/ urandom is a better choice for almost anything
involving security.
So why is /dev/urandom accessible for anyone if it has comparable
quality ?
On Sun, 13 Jul 2025 14:32:24 +0200
David Brown <david.brown@hesbynett.no> wibbled:
that use something else for their hardware RNG, root-only access (by
default) makes sense.
It may also be to discourage the use of such devices or cpu instructions
for code that needs cryptographically secure random sources. The
quality of CPU instruction random numbers has varied significantly
through the ages, and you'd be na|>ve to rely on it directly.
/dev/urandom is a better choice for almost anything involving security.
urandom is most definately not as secure as hwrng as its purely software driven with all the issues that entails.
Muttley@DastardlyHQ.org writes:
On Sun, 13 Jul 2025 14:32:24 +0200
David Brown <david.brown@hesbynett.no> wibbled:
that use something else for their hardware RNG, root-only access (by >>>default) makes sense.
It may also be to discourage the use of such devices or cpu instructions >>>for code that needs cryptographically secure random sources. The >>>quality of CPU instruction random numbers has varied significantly >>>through the ages, and you'd be na|>ve to rely on it directly. >>>/dev/urandom is a better choice for almost anything involving security.
urandom is most definately not as secure as hwrng as its purely software >>driven with all the issues that entails.
That is not the case. urandom output is derived from multiple entropy pools, including hwrng if available.
/dev/urandom provides a higher quality source of random numbers than
most hardware random number generators - especially the simplistic ones found in some cpus.-a It is also documented (with the source available, obviously), and analysed by independent experts - unlike cpu random
number generators which could be buggy, have unexpected biases or uneven distributions, or even be compromised with backdoors or predictable sequences (extreme paranoia is a virtue for cryptographers).