So we must run pulseaudio not per user but by the system.
And we must verify/control that the audio-entropyd gets the audio from the right input. (mic?)

Created attachment 815407 [details]
pulseaudio version of audio-entropyd

Please find attached a PoC/WiP version of an audio-entropyd that works with pulseaudio.
One can run the daemon and leave pulseaudio in per user mode.
Once a pulseaudio daemon is present the entropyd connects to it and records audio, used to credit the entropy pool.
Stell in need to be added: port selection as just a device is not sufficient in most cases, as well as volume adjustment. Pulseaudio is not so simple as it should be for these simple cases.
This code needs careful auditing.

Created attachment 815408 [details]
audio-entropyd for pulseaudio Makefile

udo, can you also attach sha1.c and sha1.h ?

Created attachment 815823 [details]
sha1.c

Created attachment 815824 [details]
sha1.h

(In reply to Tom "spot" Callaway from comment #4)
> udo, can you also attach sha1.c and sha1.h ?

Done, same code from 1999.

Also, is there a reason you worked off the old code as opposed to 2.0.3?

No special ones; this one work for me.(TM)
It's just a proof-of-concept as noted about the pulseaudio changes needed.

Thanks for posting this.  I was having trouble getting audio-entropyd to work in F20.  Your input gave me enough hints to get it working with the unaltered package.

I have two sound devices.  I use pavuctl to turn off device 1 to pulse so I can use alsa with it.  I started audio-entropyd using
audio-entropyd -d plughw:1 -N 11025 -s
as root and it ran fine.  Eventually, because the card has the sample rates available, I was able to use 
audio-entropyd -d plughw:1 -N 44100 -s
and 
audio-entropyd -d plughw:1 -N 88200 -s
successfully.  The random data is generated more rapidly at the higher sample rates.  The plughw does automatic format conversion in alsa, so the cards internal pipeline width doesn't have to match the 16 bits that audio-entropyd wants.

I turned off the self tests in audio-entropyd because it wouldn't create any random data with them turned on.  I guess it must just be to verify that audio-entropyd is generating legitimate random data before using it.  When I run
cat /dev/urandom | rngtest -c 1000
it passed the tests most of the time.  Even pulling 10000 or 100000.  The entropy added to /dev/random is apparently enough to augment the pseudorandom generator.  This source is too slow to provide significant entropy to use /dev/random directly for use by rngtest.  Takes forever to get enough data to operate on, but passed all the tests in rngtest perfectly with -c 10.  Probably the same tests that audio-entropyd is using to filter the raw data.  :-)

~  04:41 PM  xxxxxx  20
$ cat /dev/random | rngtest -c 10
rngtest 4
Copyright (c) 2004 by Henrique de Moraes Holschuh
This is free software; see the source for copying conditions.  There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

rngtest: starting FIPS tests...
rngtest: bits received from input: 200032
rngtest: FIPS 140-2 successes: 10
rngtest: FIPS 140-2 failures: 0
rngtest: FIPS 140-2(2001-10-10) Monobit: 0
rngtest: FIPS 140-2(2001-10-10) Poker: 0
rngtest: FIPS 140-2(2001-10-10) Runs: 0
rngtest: FIPS 140-2(2001-10-10) Long run: 0
rngtest: FIPS 140-2(2001-10-10) Continuous run: 0
rngtest: input channel speed: (min=2.631; avg=2.721; max=2.955)Kibits/s
rngtest: FIPS tests speed: (min=37.036; avg=46.657; max=48.906)Mibits/s
rngtest: Program run time: 71792786 microseconds
~  04:43 PM  xxxxxx  20
$

I ran into the SELinux bug on reboot.  I fixed it according to the instructions in journalctl,
Feb 22 10:46:50 localhost python[610]: SELinux is preventing /usr/sbin/audio-entropyd from read access on the file /usr/share/alsa/alsa.conf.
                                       
*****  Plugin catchall_boolean (89.3 confidence) suggests   ******************
                                       
If you want to determine whether entropyd can use audio devices as the source for the entropy feeds.
Then you must tell SELinux about this by enabling the 'entropyd_use_audio' boolean.
You can read 'alsa_selinux' man page for more details.
Do
setsebool -P entropyd_use_audio 1

*****  Plugin catchall (11.6 confidence) suggests   **************************

If you believe that audio-entropyd should be allowed read access on the alsa.conf file by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# grep audio-entropyd /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp
                                       
I used the second suggestion.  But it didn't persist across a reboot.  I also noticed that, as far as I can tell, the configuration file in /etc/sysconfig/audio-entropyd is ignored.  So, killing two birds with one stone, I added a line to the daemon watch configuration file,
/etc/dwatch.conf
which configures dwatch that runs every 5 minutes to restart audio-entropyd with my chosen parameters.
That line was
# directive	argument	command
P "audio-entropyd" echo 3840 > /proc/sys/kernel/random/write_wakeup_threshold && /usr/sbin/audio-entropyd -v -n plughw:2 -N 44100 -s

I upped the entropy limit in proc to 3840 from 896.  If I have the entropy, I might as well use it.  If I make it 4032 or 3968, the entropy gets drained all the time.  At 3840 it seems to only get drained when things like crond or systemd run.  Then it is quiet for a few minutes.  It seems that the kernel or system jobs determine how much entropy to use based on how much is available in the pool.

This means that when the audio-entropyd daemon fails at startup from systemd, it restarts as soon as dwatch runs (within 5 minutes).  That's acceptable for my needs since there will be the retained pool from before shutdown, and I don't have a large need for generating keys immediately upon startup.

For now I've left the -v on the invocation, in order to see the patterns, but eventually, once I think it is working properly, I'll let it run silently.

Feb 22 11:26:50 localhost audio-entropyd[3527]: woke up due to low entropy state (3788 bits left)
Feb 22 11:26:53 localhost audio-entropyd[3527]: Entropy credit of 5036 bits made (3788 bits before, 3989 bits after)
Feb 22 11:27:58 localhost audio-entropyd[3527]: woke up due to low entropy state (3823 bits left)
Feb 22 11:28:01 localhost audio-entropyd[3527]: Entropy credit of 5234 bits made (3823 bits before, 3941 bits after)
Feb 22 11:28:59 localhost audio-entropyd[3527]: woke up due to low entropy state (3835 bits left)
Feb 22 11:29:02 localhost audio-entropyd[3527]: Entropy credit of 4982 bits made (3835 bits before, 3974 bits after)

I should probably schedule a chron job every day that checks the quality of the random output.  Just a simple 
cat /dev/random | rngtest -c 100
That will take an hour or so to complete.  I'll have to read up on journalctl to see how to redirect the output so it goes into the journal.

I started looking at this in order to see why it was having problems.  And ended up doing extensive refactoring.  I streamlined the code so it is more efficient.  Enhanced the entropy extraction algorithm ideas.  It still gets about the same amount of entropy, about 1 bit for every 8 frames of sound capture, but it uses a slightly different hurdle.  Added support for the configuration file in /etc/sysconfig/audio_entropyd.  The buffers are now persistent until the program ends, and it pauses and resumes the device if it is capable of it instead of closing and opening it for each read.  That's still available for the devices that need it, but the throughput is doubled when pausing and resuming because there is no need to throw a buffer of data away each time.  Changed the size of the requested channel size to 32 bit from 16 bit, and use plughw so the program will work with devices that have any native internal data size, from 8 bits to 32 bits.

I ran the rngtest program for 10000 cycles.  The error rate is much lower than for the /dev/urandom device, the CPRNG of the linux kernel.  Here's the output.
$ cat /dev/random | rngtest -c 10000
rngtest 4
Copyright (c) 2004 by Henrique de Moraes Holschuh
This is free software; see the source for copying conditions.  There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

rngtest: starting FIPS tests...
rngtest: bits received from input: 200000032
rngtest: FIPS 140-2 successes: 9991
rngtest: FIPS 140-2 failures: 9
rngtest: FIPS 140-2(2001-10-10) Monobit: 0
rngtest: FIPS 140-2(2001-10-10) Poker: 2
rngtest: FIPS 140-2(2001-10-10) Runs: 5
rngtest: FIPS 140-2(2001-10-10) Long run: 1
rngtest: FIPS 140-2(2001-10-10) Continuous run: 1
rngtest: input channel speed: (min=5.278; avg=5.517; max=6.119)Kibits/s
rngtest: FIPS tests speed: (min=35.651; avg=48.278; max=88.303)Mibits/s
rngtest: Program run time: 35403370395 microseconds

I think this is acceptable.  The /dev/urandom device has an error rate of about .1%, and would have about 100 errors for a run of this length.  These tests are old and I would like to test with dieharder, but when I ran it on /dev/urandom as
cat /dev/urandom | dieharder -a -g200
it took several hours to complete.  Since /dev/random is about 1000 times slower, it would take months to run just this basic set of tests.  So, I see audio-entropyd being used as a source of randomness for PRNGs so they become actual RNGs.  That is, injecting randomness into their streams so they become unpredictable.  I might work on this idea, so I can test with dieharder.

I provide the patch above with my changes.  They are for the 2.0.3 version.  You can apply them in two ways.

Copy the patch into the source directory where audio-random.c is and run
patch -p0 < audio-entropyd-allow-32bit.patch
or place audio-entropyd-allow-32bit.patch in rpmbuild/SOURCE and alter the audio-entropyd.spec file when building the src.rpm so it looks like this:
Source2:  audio-entropyd.conf

#Build patches
Patch0:         audio-entropyd-allow-32bit.patch

BuildRequires:  alsa-lib-devel
BuildRequires:  systemd-units
Requires(post): systemd-sysv
Requires(post): systemd-units
Requires(preun): systemd-units
Requires(postun): systemd-units

%description
Audio-entropyd generates entropy-data for the /dev/random device.

%prep
%setup -q

# Build patches
%patch0 -p0 -b  .allow-32bit

Incidentally, I found no reason for SELinux to be complaining about audio-entropyd.  The calls it makes to alsa are standard API calls, and don't alter any of alsa's files.  Maybe the error comes out of systemd or dbus?

Created attachment 869266 [details]
Patch for audio-entropyd.c in version 2.0.3, many enhancements

See comment above for the many changes this patch makes.  I want to thank the previous authors for providing the original program.  Great idea!

Created attachment 869267 [details]
New style configuration file for version 2.0.3 patched with enhancements.

This is a new style configuration file that will work with audio-entropyd patched with the enhancements.  Put it in /etc/sysconfig/ as audio-entropyd as this path is hard coded into the source.  I didn't add an option to change it.

In comment 12, there is an error:
This,
Copy the patch into the source directory where audio-random.c is and run
should be this,
Copy the patch into the source directory where audio-entropyd.c is and run

Created attachment 869681 [details]
Patch for audio-entropyd 2.0.3 with further enhancements

This patch has all the changes of the previous patch, but also adds new configuration options to the program.  The options are now
    {"always_close",  0, NULL, 'a' },
    {"device",  1, NULL, 'd' },
    {"do-not-fork",  0, NULL, 'n' },
    {"entropy-filter",  1, NULL, 'e' },
    {"sample-rate", 1, NULL, 'r' },
    {"sample-size", 1, NULL, 'z' },
    {"skip-size", 1, NULL, 's' },
    {"internal-test",  0, NULL, 'i' },
    {"store-in-file",  1, NULL, 'f' },
    {"verbose",  0, NULL, 'v' },
    {"help",  0, NULL, 'h' },

always-close tells audio-entropyd to close and open the device for each read, even if it is capable of pausing and resuming.
sample-size tells audio-entropyd to read X samples each read of the device.
skip-size tells audio-entropyd to skip X samples before each read of the device.
internal-test tells audio-entropyd to perform internal tests.  Used to be default, now must be requested.  Changed short form to 'i'.
store-in-file tells audio-entropyd to store output into the file given.  Just a more descriptive name.
entropy-filter tells audio-entropyd to use the requested filter to extract entropy from the stream.  There are several tests including the original in 2.0.3.  It should be easy to add your own test as it is just a stanza in an if-else statement.
sample-rate now uses short form 'r'. 

I gave all the globals modified camel case names, so they would be easily recognized.

The instructions for using the patch are the same.

Created attachment 869682 [details]
A new style configuration file that will work with the latest patch for 2.0.3.

This configuration file should be moved to /etc/sysconfig/audio-entropyd.  It has all the new options provided by the latest patch in the proper format.

Forgot to say that the latest patch disables the rate lock of the device that audio-entropyd used to do.  Rate lock is redundant when using get_rate_near, since that will get a rate native to the device that will not be resampled.  e.g. if 44100 is requested and the closest rate the device provides is 48000, alsa will set the rate to 48000 and do no conversion.

To my knowledge, there is no way to tell pulse to pass streams through without resampling.  It needs to standardize everything to a fixed rate to provide all the functionality it does, and it does this on the fly.  It's been years, so that might have changed, with API calls providing pass through.  If it hasn't, and you don't want resampling in pulse, request a frame rate that is the same as the pulse frame rate.  Or change the pulse rate to match what you request or the device provides.

Created attachment 871083 [details]
Patch for 2.0.3 that adds enhancements, including support for configuration file

This has all the changes of the previous patches, and adds many more.  It cleans up some excess memory use, adds functionality to the added entropy filters, and fixes the usage message to reflect all the changes.

Use the same instructions as previously posted to use the patch.

This is probably the last patch I will be providing, as I am happy with the behavior I am now seeing from audio-entropyd.  It still fails on start with the message about access denied, but I think that has to be an error in another program.  It starts without errors, and runs fine when subsequently started by dwatch from the /etc/dwatch.conf file with this line in the file.

P "audio-entropyd" /usr/bin/echo 3840 > /proc/sys/kernel/random/write_wakeup_threshold && /usr/bin/echo 5 > /proc/sys/kernel/random/urandom_min_reseed_secs && /usr/sbin/audio-entropyd

Created attachment 871096 [details]
Configuration file for 2.0.3 that works with latest patch.

This file has all the configuration values that the patched version of audio-entropyd will expect.  Place it as /etc/sysconfig/audio-entropyd.  

There is some description of each option and what it does, as well as commented reasonable values that can be used.

As I said above, unless I find a major bug, I won't be posting any more patches.  And thanks again for providing this.

audio-entropyd-2.0.3-6.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/audio-entropyd-2.0.3-6.fc20

audio-entropyd-2.0.3-6.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/audio-entropyd-2.0.3-6.fc19

Package audio-entropyd-2.0.3-6.fc19:
* should fix your issue,
* was pushed to the Fedora 19 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing audio-entropyd-2.0.3-6.fc19'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2014-4913/audio-entropyd-2.0.3-6.fc19
then log in and leave karma (feedback).

Package audio-entropyd-2.0.3-6.fc20:
* should fix your issue,
* was pushed to the Fedora 20 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing audio-entropyd-2.0.3-6.fc20'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2014-4914/audio-entropyd-2.0.3-6.fc20
then log in and leave karma (feedback).

audio-entropyd-2.0.3-6.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.

audio-entropyd-2.0.3-6.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.