3 ms·
We've run into the /dev/random problem when doing heavy SSL traffic. We had to pipe in sources of entropy. It was a janky solution, but wasn't as janky as it mi
by karlkatzke 13y ago
We've run into the /dev/random problem when doing heavy SSL traffic. We had to pipe in sources of entropy. It was a janky solution, but wasn't as janky as it might sound.
- dspillett 13y agoIf you need more entropy for SSL traffic than a headless server that sees very little I/O load has available, I've found http://www.vanheusden.com/te/ http://www.vanheusden.com/te/ useful in the past. The ~800 bits/sec is produced in our tests isn't massive, but it was considerably than the machines we used it on could generate from the kernel's usual sources on these machines. It claims to produce valid results in VMs too, and given the way it works it might be perfectly valid to scale is some way simply by running more than one copy. If you want more than that in a cheap Heath Robinson manner (Americans: think Rube Goldberg if you are unaware of Heath, their work came from very similar inspirations) then many SoC solutions have a built-in RNG of sufficient quality for general cryptographic use and some solutions expose them easily. If you enable the relevant module a Raspberry Pi can provide up to ~550,000 bits/sec when asked to, for instance, which if one-off cost is a factor beats paying a few hundred dollars or more for a USB device providing the same sort of rate.
- gnyman 13y agoAnother solution that we are happy with at least is http://www.issihosts.com/haveged/ http://www.issihosts.com/haveged/ Based on the HAVEGE research http://www.irisa.fr/caps/projects/hipsor/ http://www.irisa.fr/caps/projects/hipsor/