# Running haveged to enhance your system entropy



## wlanboy (Mar 16, 2014)

Encryption is based on two main factors:


prime numbers
random numbers
On Linux the random numbers are generated by the pseudo random number generator.

It generates randomness from hardware interrupts e.g. by keyboard, mouse, disk or network I/O.

The main difference between /dev/random and /dev/urandom is that first is a blocking device.

So /dev/random waits until the entropy pool is filled to return random data.

/dev/urandom does not wait and therefore gerenates random data in a lower quality.

Lower quality means that previous data is repeated more likely.

So the quality of the entropy pool does have a direct inpact on the quality of SSL/TLS and other block ciphers.

One of my small servers does have a quite low entropy level:


cat /proc/sys/kernel/random/entropy_avail
129

One of my big (and busy) KVM servers does not have that problem:


cat /proc/sys/kernel/random/entropy_avail
4968

A level beyond 1000 is critical if you are using any OpenSSL based encryption.

If your server is handling a lot of SSL traffic (and handshakes) like any webserver or mailserver does, two things can happen:


The server waits until /dev/random is ready again
The server switches to /dev/urandom or it's own random generator (after a timeout)
There are userland solution like the audio_entropyd or the video_entropyd to feed the entropy pool, but they are not usable for headless servers.

But there are solutions for servers too - one of them is haveged.

It is a daemon that feeds the /dev/random pool on Linux using an adaptation of the HArdware Volatile Entropy Gathering and Expansion algorithm.

Installation is simple:


apt-get install haveged

Afterwards you have to check the default settings to ensure that enough bits are generated:


nano /etc/default/haveged

Content:


# Configuration file for haveged

# Options to pass to haveged:
# -w sets low entropy watermark (in bits)
DAEMON_ARGS="-w 2048"

After starting the server:


service haveged start

You should then set the daemon to autostart:


update-rc.d haveged defaults

There are - of course - better tests than cat to check if your entropy is ok:


apt-get install rng-tools

rng-test is using the FIPS-140 method to check the entropy:


cat /dev/random | rngtest -c 1000

Output would be:


rngtest 2-unofficial-mt.14
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: 2000032
rngtest: FIPS 140-2 successes: 1000
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=8.557; avg=17.635; max=24.236)Mibits/s
rngtest: FIPS tests speed: (min=68.610; avg=156.648; max=188.846)Mibits/s
rngtest: Program run time: 133849 microseconds

On 1000 runs there should not be more than 1 to 5 failures.

So check the line:


```
rngtest: FIPS 140-2 failures:
```


----------



## tonyg (Mar 16, 2014)

Are there any benefits to using haveged over rng?


----------



## lbft (Mar 16, 2014)

If the root user of any OpenVZ VPS can add entropy to the pool, would it be possible for one VPS to feed the pool a malicious entropy source and affect the security of other VPSes on the same node?


----------



## tchen (Mar 16, 2014)

lbft said:


> If the root user of any OpenVZ VPS can add entropy to the pool, would it be possible for one VPS to feed the pool a malicious entropy source and affect the security of other VPSes on the same node?


You shouldn't be able to feed /dev/random from within a container.  Haveged, TimerEntropy nor any other generator won't run in a guest VE.  Well, they'd run, but won't be able to set anything


----------



## lbft (Mar 16, 2014)

tchen said:


> You shouldn't be able to feed /dev/random from within a container.  Haveged, TimerEntropy nor any other generator won't run in a guest VE.  Well, they'd run, but won't be able to set anything


I had assumed that, but @wlanboy's post seems to imply that haveged does in fact run and put entropy into the pool.


----------



## tchen (Mar 16, 2014)

lbft said:


> I had assumed that, but @wlanboy's post seems to imply that haveged does in fact run and put entropy into the pool.


It does.  But only within KVM and other full virtualization environments.   (sorry, VE in the previous context was OpenVZ VE) 

edit: oh, I get what you mean now.  Ya, he left it unsaid.


----------



## lbft (Mar 16, 2014)

tchen said:


> It does.  But only within KVM and other full virtualization environments.   (sorry, VE in the previous context was OpenVZ VE)


I understand what you mean, but I'm suggesting that the way I read the post, wlanboy was suggesting that it works inside an OVZ container:



wlanboy said:


> One of my small OpenVZ servers does have a quite low entropy level:
> 
> 
> 
> ...


The entropy figures quoted after starting haveged only make sense compared to the initial OpenVZ numbers, and the conclusion only makes sense if you take the "something to solve" as referring to low available entropy inside an OpenVZ container, given his conclusion that the KVM VPS had gathered adequate entropy in the first place. The reference to providers not helping strongly suggests this is not to do with increasing entropy for the operator of an OpenVZ host node, either.


----------



## KuJoe (Mar 16, 2014)

We use rngd for our servers but I decided to give haveged a try and ran some tests, here's the results:

OpenVZ Node with rngd:


# cat /proc/sys/kernel/random/entropy_avail
3968
 

]# cat /dev/random | rngtest -c 1000
rngtest 2
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: 20000032
rngtest: FIPS 140-2 successes: 1000
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=10.007; avg=15.109; max=19073.486)Mibits/s
rngtest: FIPS tests speed: (min=89.969; avg=108.405; max=111.541)Mibits/s
rngtest: Program run time: 1438734 microseconds


OpenVZ Node with haveged:


# cat /proc/sys/kernel/random/entropy_avail
1147
 
# cat /dev/random | rngtest -c 1000
rngtest 2
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: 20000032
rngtest: FIPS 140-2 successes: 1000
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=1.141; avg=22.261; max=30.132)Mibits/s
rngtest: FIPS tests speed: (min=79.143; avg=106.370; max=111.541)Mibits/s
rngtest: Program run time: 1036496 microseconds

OpenVZ Node with both:


# cat /proc/sys/kernel/random/entropy_avail
3968
 

# cat /dev/random | rngtest -c 1000
rngtest 2
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: 20000032
rngtest: FIPS 140-2 successes: 1000
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=3.736; avg=18.521; max=19073.486)Mibits/s
rngtest: FIPS tests speed: (min=85.531; avg=99.397; max=110.892)Mibits/s
rngtest: Program run time: 1222103 microseconds


And compared to the same OpenVZ node without either:


```
# cat /proc/sys/kernel/random/entropy_avail
154
```


----------



## Shados (Mar 17, 2014)

wlanboy may have just mis-interpreted the data there - with haveged, you wouldn't see a slow, slight increase like that, you'd see it dramatically/immediately spike to >~1024 and spike back up there whenever it dropped below it. And yes, haveged will not work in OpenVZ. Also, in general you can't necessarily trust haveged in a virtual environment - it depends on how the VE treats RDTSC calls.

EDIT: @KuJoe you might want to set haveged to refill when it drops below 4000 or so instead of the default 1024 given rngd is keeping the pool at 3968 bits, then re-run the test. Probably won't be much difference though.


----------



## wlanboy (Mar 17, 2014)

lbft said:


> If the root user of any OpenVZ VPS can add entropy to the pool, would it be possible for one VPS to feed the pool a malicious entropy source and affect the security of other VPSes on the same node?


Nope:


echo "10" > /dev/random
bash: /dev/random: Operation not permitted



tchen said:


> You shouldn't be able to feed /dev/random from within a container.  Haveged, TimerEntropy nor any other generator won't run in a guest VE.  Well, they'd run, but won't be able to set anything


Yup it is a shared resource.



Shados said:


> wlanboy may have just mis-interpreted the data there - with haveged, you wouldn't see a slow, slight increase like that, you'd see it dramatically/immediately spike to >~1024 and spike back up there whenever it dropped below it. And yes, haveged will not work in OpenVZ. Also, in general you can't necessarily trust haveged in a virtual environment - it depends on how the VE treats RDTSC calls.
> 
> EDIT: @KuJoe you might want to set haveged to refill when it drops below 4000 or so instead of the default 1024 given rngd is keeping the pool at 3968 bits, then re-run the test. Probably won't be much difference though.


Yup - correct.

Sorry for the confusion - /dev/random is a shared source on OpenVZ.

You can run haveged only on full virtualization like on KVM.

Updated my post.


----------



## drmike (Mar 17, 2014)

Thanks for this Wlanboy!   I've used both approaches in the past on dedicated servers....

I've grafted this into my installation scripts here forward.  Keep up the great work!


----------



## Magiobiwan (Mar 17, 2014)

I remember finding haveged a couple months ago. Pushed it to servers and suddenly everything got MUCH faster. Our newest nodes with v3 CPUs and rrand were doing okay before the addition of haveged, but rrand wasn't feeding by default (rng-tools not installed or something).


----------



## Deleted (Mar 18, 2014)

IIRC haveged uses AES/AVX instructions on the CPU to seed the random number generator. The old method is slow because it has to use a very expensive ioport() to talk to the ISA bus, which takes a long time.

Also, running this on non ring0 hardware is silly because of privilege instruction emulation, which will probably make things slower.


----------



## KuJoe (Mar 18, 2014)

I switched off rngd and enabled haveged on our nodes to see if I can notice any difference and I can't say that I do, maybe our clients will though so I'll run it for a month and see what happens.


----------



## eva2000 (Mar 18, 2014)

Interesting thanks for the nice write up

this is what I see on my ramnode 128MB OpenVZ VPS which hosts my SPDY/SSL blog


----------



## Nick_A (Mar 18, 2014)

Yeah, someone recommended haveged to us a while back. Definitely a nice boost.


----------



## D. Strout (Mar 18, 2014)

KuJoe said:


> I switched off rngd and enabled haveged on our nodes to see if I can notice any difference and I can't say that I do, maybe our clients will though so I'll run it for a month and see what happens.


My 96MB, mostly idle OpenVZ box with you has 4096 entropy available. A 1024MB OVZ box I have with another provider not running haveged has 149 entropy available. So yeah.


----------



## KuJoe (Mar 18, 2014)

D. Strout said:


> My 96MB, mostly idle OpenVZ box with you has 4096 entropy available. A 1024MB OVZ box I have with another provider not running haveged has 149 entropy available. So yeah.


Before we switched to haveged it was 3986 entropy. I'm keeping rngd in our build template for now but I might change it to haveged depending on if I notice any difference or we get any tickets as a result over the next month.


----------



## eva2000 (Mar 18, 2014)

Nick_A said:


> Yeah, someone recommended haveged to us a while back. Definitely a nice boost.


my blog thanks you for it


----------



## wlanboy (Mar 26, 2014)

Magiobiwan said:


> I remember finding haveged a couple months ago. Pushed it to servers and suddenly everything got MUCH faster. Our newest nodes with v3 CPUs and rrand were doing okay before the addition of haveged, but rrand wasn't feeding by default (rng-tools not installed or something).





KuJoe said:


> I switched off rngd and enabled haveged on our nodes to see if I can notice any difference and I can't say that I do, maybe our clients will though so I'll run it for a month and see what happens.





Nick_A said:


> Yeah, someone recommended haveged to us a while back. Definitely a nice boost.


Checked this and the vps I have with theses providers do have the highest entropy levels of my vps pool.

This is for the OpenVZ offers - on KVM you have to fill your entropy pool on your own.


----------



## Magiobiwan (Mar 31, 2014)

Nick_A said:


> Yeah, someone recommended haveged to us a while back. Definitely a nice boost.


I'm fairly certain that was me. Made my VPS much faster, even though it's not doing anything super heavy on randomness.


----------



## drmike (Mar 31, 2014)

Yeah really liking haveged and using it on everything 

Was reading the technical info the other night.   Seems sufficiently believable and suitable drop in replacement for random.


----------



## wlanboy (Apr 4, 2014)

KuJoe said:


> We use rngd for our servers but I decided to give haveged a try and ran some tests, here's the results:


Can you add the config of both tools?


----------



## Mohammed H (Mar 10, 2015)

Hello,

thanks for the info.

also for KVM nodes you can allow KVM guests access /dev/random or /dev/hwrng (if you have hardware RNG) using virtio rng as explained here

http://rhelblog.redhat.com/2015/03/09/red-hat-enterprise-linux-virtual-machines-access-to-random-numbers-made-easy/

and using virsh edit you can enable RNG per guest using this xml entry

https://libvirt.org/formatdomain.html#elementsRng

Highest Regards

Mohammed H


----------

