Crypto Question: Where do you get your entropy
[Scott asked that we post our questions from tonight's meeting] Where do you get your entropy? Entropy (real bytes of random numbers, not pseudo-random numbers) is key for cryptography. - when generating keys for public-key cryptosystems (RSA, ECC, ...) - when generating session keys via a Diffie-Hellman exchange - challenging the other side in various ways (eg. proving liveness or proving possession of a private key) - probably other cases that I'm not remembering at the moment In many cases a Cryptographic Pseudo-Random Number Generator (PRNG) is good enough, but not these. Sometimes a Cryptographic PRNG can be used to "stretch" entropy: kind of like stretching soup by adding water or milk. Adversaries can easily break your cryptosystem if you don't have sufficient entropy. It's that bad. What sources do you use? /dev/random and /dev/urandom are the Linux channel for entropy. There are various sources that can be pooled by the kernel: - timing of unpredictable event (e.g. user keystokes, disk seek timing, ethernet packet timing, ...). The only one I kind of trust is the keystrokes thing, and that doesn't work for servers. Others might be controlled by or predictable to foes. Keystrokes are not as good as one would like. For example, USB keyboards have keystroke timing quantized by the USB scanning rate. - Recent Intel CPUs have true RNGs. (Assuming that they were not subverted by the US Government or something else. Or just plain buggy, something that might not be detectable) - external entropy source. - Scott mentioned several. One DIY example: harvest the americium pellet from a smoke detector and place it directly on a camera sensor. This makes a kind of Geiger Counter and Geiger Generator (I made that second term up). Physicists think that radioactive emissions are unpredictable (except for chain reactions) and thus should be good entropy generators. - Chris mentioned a Kickstarter(?) project that has produced what they claim is an entropy generator on a USB stick.
On 11/12/2014 01:22, D. Hugh Redelmeier wrote:
[Scott asked that we post our questions from tonight's meeting]
Where do you get your entropy?
On remove VMs (regardless of the the fact that you control the host node or not), I like to use haveged to generate entropy. This is especially helpful on Xen PV VMs where I've had issues with openssl blocking on entropy. http://www.issihosts.com/haveged/ http://www.irisa.fr/caps/projects/hipsor/ -- staticsafe https://staticsafe.ca
I do believe that I might be doing it wrong , but I emailed photos of the whiteboard to this address ... and I don't see them. Anyone know why that might be? david On Wed, Nov 12, 2014 at 9:40 AM, staticsafe <me@staticsafe.ca> wrote:
On 11/12/2014 01:22, D. Hugh Redelmeier wrote:
[Scott asked that we post our questions from tonight's meeting]
Where do you get your entropy?
On remove VMs (regardless of the the fact that you control the host node or not), I like to use haveged to generate entropy. This is especially helpful on Xen PV VMs where I've had issues with openssl blocking on entropy.
http://www.issihosts.com/haveged/ http://www.irisa.fr/caps/projects/hipsor/
-- staticsafe https://staticsafe.ca
--- GTALUG Talk Mailing List - talk@gtalug.org http://gtalug.org/mailman/listinfo/talk
On 12 November 2014 01:22, D. Hugh Redelmeier <hugh@mimosa.com> wrote:
- Chris mentioned a Kickstarter(?) project that has produced what they claim is an entropy generator on a USB stick.
Not Kickstartered, from a UK-based company... http://www.entropykey.co.uk/tech/ "The Entropy Key uses P-N semiconductor junctions reverse biassed with a high enough voltage to bring them near to, but not beyond, breakdown in order to generate noise. In other words, it has a pair of devices that are wired up in such a way that as a high potential is applied across them, where electrons do not normally flow in this direction and would be blocked, the high voltage compresses the semiconduction gap sufficiently that the occasional stray electron will quantum tunnel through the P-N junction. (This is sometimes referred to as avalanche noise.) When this happens is unpredictable, and this is what the Entropy Key measures." Priced at 36 euros in small quantities. -- When confronted by a difficult problem, solve it by reducing it to the question, "How would the Lone Ranger handle this?"
On Nov 12, 2014 10:52 AM, "Christopher Browne" <cbbrowne@gmail.com> wrote:
Unfortunately, these are no longer available. If you check their shop, they say that the wait time is effectively indefinite. It looks well designed, but it all depends how paranoid you need to be. Certain ARM Cortex microcontrollers have thermal hardware RNGs built in. They can pump out a stream of noise at a huge rate. The Raspberry Pi's SoC has one too. It's not super-fast and closed, so you decide if it works for you. Most other artisanal solutions (Geiger counter timing, clock skew on microcontrollers, detuned radios, avalanche noise, intentionally mis-wired comparators) don't produce the volume of entropy you need. They're also open to tampering, and most folks don't have the knowledge to know what to look for in designing such a thing. I certainly know I don't ... I haven't checked if you still have to build a custom kernel to get RdRand support on x86. Given past messes over ssh entropy holes, the lack of support for RdRand because it might be tainted by the NSA was a pot/kettle situation. Cheers Stewart
If you guys don't mind soldering a lot, there's a hardware RNG here: http://hackaday.com/2014/10/31/dual-mode-avalanche-and-rf-random-number-gene... It says it can generate ~350kbits per second of entropy... I don't know if it's enough for you. Mauro http://mauro.limeiratem.com - registered Linux User: 294521 Scripture is both history, and a love letter from God. 2014-11-12 14:27 GMT-02:00 Stewart Russell <scruss@gmail.com>:
On Nov 12, 2014 10:52 AM, "Christopher Browne" <cbbrowne@gmail.com> wrote:
Unfortunately, these are no longer available. If you check their shop, they say that the wait time is effectively indefinite.
It looks well designed, but it all depends how paranoid you need to be. Certain ARM Cortex microcontrollers have thermal hardware RNGs built in. They can pump out a stream of noise at a huge rate.
The Raspberry Pi's SoC has one too. It's not super-fast and closed, so you decide if it works for you. Most other artisanal solutions (Geiger counter timing, clock skew on microcontrollers, detuned radios, avalanche noise, intentionally mis-wired comparators) don't produce the volume of entropy you need. They're also open to tampering, and most folks don't have the knowledge to know what to look for in designing such a thing. I certainly know I don't ...
I haven't checked if you still have to build a custom kernel to get RdRand support on x86. Given past messes over ssh entropy holes, the lack of support for RdRand because it might be tainted by the NSA was a pot/kettle situation.
Cheers Stewart
--- GTALUG Talk Mailing List - talk@gtalug.org http://gtalug.org/mailman/listinfo/talk
FYI, there's now a Kickstarter project for the OneRNG entropy generator. https://www.kickstarter.com/projects/moonbaseotago/onerng-an-open-source-ent... You can request quantity-of-one for $50 NZD (which is about $46 CDN), or get 5 for $200 NZD. $90 NZD premium for a hardware programmer. (It's consciously NOT programmable across the USB interface for safety sake.) Also quite worthwhile to visit the 'design' site <http://onerng.info/>, which points to both software and hardware 'source code' on GitHub and design materials
On 2015-01-12 01:23 PM, Christopher Browne wrote:
FYI, there's now a Kickstarter project for the OneRNG entropy generator.
Or, slightly cheaper, is Bill Cox's Infinite Noise <https://www.tindie.com/products/WaywardGeek/infinite-noise/> TRNG. The hardware is ridiculously simple (no microcontroller inside the case: if you feed the USART a byte, you get a few random bits back). It's not super fast, and it does need a driver to do the data whitening, but it's under $30. cheers, Stewart
Adversaries can easily break your cryptosystem if >you don't have sufficient entropy. It's that bad.
What sources do you use? /dev/random and >/dev/urandom are the Linux channel for entropy. There are various sources >that can be pooled by the kernel:
/dev/urandom does not generate entropy I think. It depends on /dev/random. The firmer just stretch the later entropy. The problem is more acute with servers though unfortunately as most run on virtualized environment these day and since there is no console, they gave little entropy during start up. William
| From: William Muriithi <william.muriithi@gmail.com> [Your MUA seems to muck up linebreaks in quoting. It also converted some of what I typed to non-ASCII. I've tried to fix that.] | >Adversaries can easily break your cryptosystem if | >you don't have sufficient entropy. It's that bad. | | >What sources do you use? /dev/random and | >/dev/urandom are the Linux | >channel for entropy. There are various sources | >that can be pooled by the kernel: | | | /dev/urandom does not generate entropy I think. It depends on | /dev/random. The firmer just stretch the later entropy. Neither generates entropy. That's why I described them as channels. I tried to be fairly careful in what I said. You are right that /dev/random only yields as many bytes as the kernel estimates there are bytes of entropy in the pool and that /dev/urandom will give as many bytes as you ask for, even if the entropy estimate says that there is none remaining. Entropy is a tricky topic. Maybe this talk next Monday will be enlightening: <http://www.fields.utoronto.ca/programs/scientific/fieldsmedalsym/14-15/Images/fms_po_final.pdf> I'm thinking of going. | The problem is more acute with servers though unfortunately as most run | on virtualized environment these day and since there is no console, they | gave little entropy during start up. Good point: virtual servers are even worse off than real servers.
participants (8)
-
Christopher Browne -
D. Hugh Redelmeier -
David Thornton -
Mauro Souza -
staticsafe -
Stewart C. Russell -
Stewart Russell
-
William Muriithi