[Whonix-devel] revive randomsound?

Mon Feb 3 12:53:09 CET 2020

Daniel Silverstone:
> There are also devices one can purchase which can increase the available
> entropy pool if your hosts are regularly running dry.  For example the
chaoskey
> by Keith Packard and Bdale Garbee.

This might work well for an individual, however we as a Linux
distribution are working on software solutions to make good entropy
quality available easily for as many users in the default installation.

Daniel Silverstone:
> These days I'd recommend ensuring that host systems harvest entropy
from as
> many sources as possible, optionally sharing them around among
themselves (I
> believe there's software for this kind of thing) and then qemu has a
virtio-rng
> device which allows transfer of entropy from host to guest (at a
controlled
> rate).

That is our plan. Using as many diverse entropy sources as possible. We
already install by default haveged, jitterentropy-rng package, load
jitterentropy-rng kernel module, use virtio-rng for VMs. Currently I am
working on packaging and integration of twuewand (a truerand algorithm
for generating entropy). [1]

Daniel Silverstone:
> It was designed to gather sound at all times it was running.
> 
>> * I assume form the package description it relies on sound output and
>> not microphone input unlike van Heusden's audio-entropyd
> 
> It was meant to use an input line, microphone or line-in.
> 
>> * How well can it function in a virtual environment?
> 
> Probably not usefully at all.

Could we test that please? I am eager to test entropy by randomsound but
I would need help with the C code.

I am still wondering if randomsound could be made useful nowadays. It is
packages in Debian and probably other Linux distributions. [2] This
results in an easy "sudo apt install randomsound" usability.

I've looked at the source code of randomsound and it looks good. Not too
much code.

Biggest problem currently I see with randomsound is that it cannot be
easily analyzed. It writes directly to /dev/random. Hacking the code to
write to /tmp/randomsound.bin instead (and a previous "touch
/tmp/randomsound.bin") does not work either.

Nowadays lots of randomsound features could be dropped in order to
reduce the code size and make it more maintainable.

demonizing: This is no longer required in the age of systemd. Programs
can be developed as if running in foreground and systemd will launch
them properly into the background without application support needed.

random quality: Since nothing written to /dev/random can worsen kernel
entropy quality [3], I don't see a risk. Only potential enhancement by
using randomsound.

debiasing: Since nothing written to /dev/random can worsen its entropy
quality [3], would it be sane to avoid this to safe CPU load? But even
if we wanted debiasing, wouldn't it be better to implement this in an
external tool and pipe to it? Or would piping randomsound to an external
debiasing tool reduce performance too much?

crediting entropy: ioctl RNDGETENTCNT and RNDADDENTROPY is no longer
required. We don't want to credit the entropy for better security [4]
but even if we wanted, wouldn't it be better to use a separate tool such
as rndaddentropy [5] for it and pipe to it? (shell: randomsound |
rndaddentropy)

entropy pool counting, buffering: This is no longer required as per above.

verbose output: due to above a lot verbosity output and if/else could be
removed too.

simplification: randomsound could simply write its output to stdout. And
errors to stderr. That's it. No other features needed.

Once randomsound is writing to stdout (or any file) I could analyze its
output with various entropy tests [6] (such as rngtest, ent, dieharder)
in various environments (host and VMs) and see if it is still useful
nowadays.

If test results are good, I could work on work on system integration.
I.e. Writing a systemd unit file and shell wrapper script for either
running at boot to generate a number of random bytes before
sysinit.target and/or to run randomsound with low CPU (systemd can
easily limit system resources such as CPU too) to help re-seeding
/dev/random after the system booted.

randomsound might not even need a feature to exit after XX bytes.
Similar to:

cat /dev/random | base64 | head --bytes=128

I might be able to read XX amount of bytes and then close the pipe.

randomsound | base64 | head --bytes=128

(Or: randomsound | head --bytes=128 >/dev/random)

(Or: randomsound | debiasing | head --bytes=128 | rndaddentropy)

randomsound would just need to terminate properly on usual signals such
as sigterm and sigpipe. Or I might even find a solution to send sigkill
in the pipe (sigpipe would be cleaner, I guess).

Would you be interested to revive randomsound? If yes, could you please
add randomsound to git(hub) (or something) and add a branch that writes
to stdout?

CC'd whonix-devel public mailing list so all our users can benefit from
your reply.

Kind regards,
Patrick

[1]
https://www.whonix.org/wiki/Dev/Entropy#twuewand_-_a_truerand_algorithm_for_generating_entropy

[2] https://packages.debian.org/buster/randomsound

[3] https://www.whonix.org/wiki/Dev/Entropy#Write_to_.2Fdev.2Frandom

[4] https://www.whonix.org/wiki/Dev/Entropy#Credit_Entropy

[5]
https://www.whonix.org/wiki/Dev/Entropy#rndaddentropy_-_An_RNDADDENTROPY_ioctl_wrapper

[6] https://www.whonix.org/wiki/Dev/Entropy#Entropy_Tests