Re: Unidentified subject!
On 2/10/24 02:38, Thomas Schmitt wrote:
I have an own weak-random generator, but shred beats it by a factor of 10
when writing to /dev/null.
As a baseline, here is a 2011 Dell Latitude E6520 with Debian generating
a non-repeatable 1 GiB stream of cryptographically secure pseudo-random
numbers:
2024-02-10 14:10:27 dpchrist@laalaa ~
$ lscpu | grep 'Model name'
Model name: Intel(R) Core(TM) i7-2720QM CPU @
2.20GHz
2024-02-10 14:01:25 dpchrist@laalaa ~
$ cat /etc/debian_version ; uname -a
11.8
Linux laalaa 5.10.0-27-amd64 #1 SMP Debian 5.10.205-2 (2023-12-31)
x86_64 GNU/Linux
2024-02-10 14:01:47 dpchrist@laalaa ~
$ bash --version | head -n 1
GNU bash, version 5.1.4(1)-release (x86_64-pc-linux-gnu)
2024-02-10 14:13:08 dpchrist@laalaa ~
$ time dd if=/dev/urandom bs=8K count=128K | wc -c
1073741824
131072+0 records in
131072+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 4.30652 s, 249 MB/s
real 0m4.311s
user 0m0.107s
sys 0m4.695s
If the OP has a known good storage device of equal or larger size than
the UUT(s), I suggest using /dev/urandom and tee(1) to write the same
CSPRN stream to all of the devices and using cmp(1) to validate.
I use Perl. When I needed a CSPRNG, I searched and found:
https://metacpan.org/pod/Math::Random::ISAAC::XS
Using Perl and Math::Random::ISAAC::XS to generate a repeatable stream
of cryptographically secure pseudo-random numbers:
2024-02-10 14:09:12 dpchrist@laalaa ~
$ perl -v | head -n 2 | grep .
This is perl 5, version 32, subversion 1 (v5.32.1) built for
x86_64-linux-gnu-thread-multi
2024-02-10 14:09:53 dpchrist@laalaa ~
$ perl -MMath::Random::ISAAC::XS -e 'print
$Math::Random::ISAAC::XS::VERSION, $/'
1.004
2024-02-10 14:10:32 dpchrist@laalaa ~
$ time perl -MMath::Random::ISAAC::XS -e
'$i=Math::Random::ISAAC::XS->new(12345678); print pack 'L',$i->irand
while 1' | dd bs=8K count=128K | wc -c
1073741824
131072+0 records in
131072+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 82.6523 s, 13.0 MB/s
real 1m22.657s
user 1m22.892s
sys 0m5.810s
The 'perl ... | dd ...' pipeline appears to be limited to a block size
of 8,192 bytes. I do not know if this is due to bash(1), perl(1), or
dd(1) (?).
The repeatability of the ISAAC stream would substitute for the known
good storage device, but the throughput is ~19x slower than
/dev/urandom. A drive capacity validation tool would want to feature
concurrent threads and I/O on SMP machines.
David
Reply to: