Home / server / Questions / 354532
In Process
grifferz
Asked: 2012-01-29 03:52:45 +0800 CST

How to tell when an Entropy Key is overloaded?

  • 772

I have several Entropy Keys with egd in front of them and then all load balanced by haproxy. I then have many client machines using the haproxy service IP as a network source of entropy. I have no idea how much entropy they are requesting.

The Entropy Keys can produce a limited amount of usable entropy. The specs say about 30 kilobit/sec minimum. As far as I can see, the Entropy Key doesn't have a way to query how much it is being asked for. The EGD protocol seems quite hard to sniff to find this information. Clients can request a variable amount of entropy, and they might not get back the same amount.

Has anyone found a simple way to measure how much is being requested from an Entropy Key?

It would be good to know, in order to be able to plan when additional keys are required, and to spot haywire clients.

linux entropy-pool

3 Answers

  1. The only two things that come to mind is trying to measure the response time of your entropy server (there should be a significant increase in latency if it can't keep up) or pooling /proc/sys/kernel/random/entropy_avail and monitoring how much entropy you have (I'm assuming that egd is using /dev/random and not the hardware directly).

    • 4

  2. It looks like the source tarball for ekeyd has a munin plugin for providing ekey statistics.

    Even if you're not running munin I guess it would be possible to extrapolate the script into something usable for your infrastructure.

    I think we both know the authors of the device and software though, so might be worth prodding them. :-)

    • 2

  3. Try:

    dd if=/dev/random of=/dev/null bs=1K count=1M

    When it finishes, dd will report the read bandwidth, so you will know the amount of entropy provided. You can run it in the server (disconnected from its clients) to measure entropy production, and in the clients, to measure how much are they receiving.

    Killing the running dd process with SIGUSR1 signal will instruct it to report its I/O statistics, so you don't need to wait for it to finish (see man dd).

    Also, clients should expose an increase in their download-bandwidth consumption, because of the entropy being read from the server (e.g.: nethogs plus netstat).

    • 0