Hi everyone
I just got my hands on a T5120 running Sol10. As far as I've read, the T2 chip has a built-in hardware number generator. My question is: how can I access it to get random numbers in either C or Fortran? I'm using Sun Studio 12.4.
I am currently trying to write an application for simulating stochastic motion of Brownian particles and being able to get true random numbers instead of pseudo-random numbers is of great use for me.
Thank you in advance
/dev/random has a limitation - a good one. When the entropy pool is empty, it will not return values. It blocks on read(). /dev/urandom is the same as /dev/random except that when the entropy pool has no more values it will return a value anyway.
The entropy pool is a kernel-only readable object.
I'll be more specific.
Say I want to get a random number in fortran through the following statement 'call random_number(arg)'. The question is: how can I make sure that this call does not return a pseudo-random number but instead a random number generated by the HARDWARE "true" random number generator of the SPARC T2 chip?
I need this for simulations so I do require true random numbers.
Thanks
Hi.
Some suggestions:
Sources of true random sequences
0) AVOID /dev/random /dev/urandom:
The kernel random-number generator is designed to produce
a small amount of high-quality seed material to seed a
cryptographic pseudo- random number generator (CPRNG). It
is designed for security, not speed, and is poorly suited
to generating large amounts of random data. Users should be
very economical in the amount of seed material that they
read from /dev/urandom (and /dev/random); unnecessarily
reading large quantities of data from this device will have
a negative impact on other users of the device.
-- excerpt from man urandom
1) http://www.fourmilab.ch/hotbits/
2) http://random.irb.hr/index.php
3) https://www.random.org/
4) perl module:
Net::Random - get random data from online sources
Sample output, 5 integers (min, max vary):
From fourmilab.ch : 600 1785 384 1466 1212
From qrng.anu.edu.au: 2498 2234 2071 2573 2868
From random.org : 7014 5940 5911 6289 3246
Best wishes ... cheers, drl
@drl: You should avoid using Linux documentation with Solaris. It might not be relevant which is especially the case in this thread.
@toguro123 You should first make sure the n2rng provider (kernel module) is enabled:
# cryptoadm list | grep rng
Then you might have a look to the n2rng provider kernel statistics and see if they increase after your calls.
# kstat -m n2rng
I believe cryptoadm also let you configure /dev/random to only use the hardware generator but I haven't the precise command to run. You might have a look to cryptoadm documentation.
Hi, jlliagre.
OK, thanks for the comment. I'll add an excerpt from Solaris. It looks quite similar to me, but it might be more on point for Solaris users. I'm trying emphasize that /dev/random & /dev/urandom are probably not good sources for true random sequences, and that the net resources mentioned are such sources, and that they would (generally) be portable.
Sources of true random sequences
0) AVOID /dev/random /dev/urandom:
The kernel random-number generator is designed to produce
a small amount of high-quality seed material to seed a
cryptographic pseudo- random number generator (CPRNG). It
is designed for security, not speed, and is poorly suited
to generating large amounts of random data. Users should be
very economical in the amount of seed material that they
read from /dev/urandom (and /dev/random); unnecessarily
reading large quantities of data from this device will have
a negative impact on other users of the device.
-- excerpt from man urandom (linux)
Applications retrieve random bytes by reading /dev/random
or /dev/uran- dom. The /dev/random interface returns random
bytes only when suffi- cient amount of entropy has been
collected. If there is no entropy to produce the requested
number of bytes, /dev/random blocks until more entropy can
be obtained. Non-blocking I/O mode can be used to disable
the blocking behavior. The /dev/random interface also
supports poll(2). Note that using poll(2) does not increase
the speed at which random numbers can be read.
-- excerpt from man urandom (Solaris)
1) http://www.fourmilab.ch/hotbits/
2) http://random.irb.hr/index.php
3) https://www.random.org/
4) perl module:
Net::Random - get random data from online sources
Sample output, 5 integers (min, max vary):
From fourmilab.ch : 600 1785 384 1466 1212
From qrng.anu.edu.au: 2498 2234 2071 2573 2868
From random.org : 7014 5940 5911 6289 3246
Best wishes ... cheers, drl
You are right, the manual pages are indeed similar. The point here is the recommendation to avoid /dev/random and /dev/urandom might be valid when using a cryptographic pseudo random number generator but not that much in the OP case, which is specifically about the UltraSPARC T2 and newer high-performance internal hardware random number generator. The latter bases its entropy on physical measurements, i.e. not purely software generated sequences so shouldn't suffer from rapid entropy exhaustion like its software counterpart.
See this last paragraph in Solaris random(7d) manual:
Other relevant manual pages are cryptoadm(1m) and n2rng(7d)
Thank you all for your responses; these give me a good place to start.
OK guys looking at this completely laterally.
Hear me out before ridiculing and apologies for any typos...
This requires an installation of SOX on a personal home computer, NOT, the said machine.
Forget the intended machine at this point. The only assumption to be made is that OP is allowed to transfer a file to said machine.
How about using a home computer of any kind, in this case my MacBook Pro, circa August 2012, OSX 10.7.5, default bash terminal, feeding a white noise generator into the mic input of the 'on_board' sound system using an avalanche diode idea via a zener.
1) The noise is definitely random, white thermal noise in circuits by definition IS.
2) Theoretically any raw data file can be almost limitless is size.
3) Because it is byte sized per sample and raw then you could decide whether your values are 8 to 64, (or more), bits in length.
4) The passband of the computer's mic circuit is peculiar to the machine recorded on. EG 300Hz to 5KHz or much wider, who knows, adding to the randomness.
5) You can't guarantee that these specifications are even flat and my have small peaks and troughs throughout the passband.
6) Aliasing WRT the sampling frequencey is an added bonus to the randomness, assuming linear interpolation.
7) If an added amplifer stage is needed to full scale the mic circuit, then another bonus to the randomness due to its own small internal noise generated.
That is all I can think of at the moment.
Once you have the file, transfer it to the main machine and decide what bit depth is suitable and use any floating point value as your multiplier.
This is what I term as "my weapon of last resort". And no matter how stupid this looks it works.
#!/bin/sh
# random.sh <seconds[1 to 59]>
SECS="$1"
/full/path/to/sox -q -V0 -d -t raw -r 96000 -b 8 -c 1 -e unsigned-integer -> /tmp/random.dat trim 0 00:"$SECS"
exit 0
#
# Ultra simple noise generator.
#
# +-------> +9V
# |
# ___|___ +
# / \ |
# / \ ZD1
# '_____'
# Mic I/P | | |
# O----*----| |-----*
# | | | |
# / C1 /
# \ \
# / R1 / R2
# \ \
# / /
# \ \
# | |
# O----*-----*------*-------> 0V
# __|__
# /////
# Parts:-
# ZD1 .......... 1W, 6.8V zener.
# C1 ........... 1uF non polarised capacitor.
# R1 ........... 2.7K to 4.7K resistor, any power and tolerance.
# R2 ........... 82 to 120 ohms resistor, any power and tolerance.
# Obviuosly a battery, etc...
Lol! Lovely ... who else than Dr. Audioscope would come up with sth. like this...
I forgot to add...
If you are not too bothered about the format of the file you could use the mic/earphone socket on your phone and use the voice recorder on it. Just a thought.
That's high-quality noise too, straight from quantum breakdown fluctuations.
Hi.
See also Comparison of hardware random number generators - Wikipedia, the free encyclopedia some as low as U$12 ... cheers, drl