Re: Python Random Number Generator for OTP
On Wed, Jul 24, 2013 at 7:27 PM, Andy Isaacson <adi@hexapodia.org> wrote:
My /dev/random generates a few hundred kilobytes a day. I exchange OTPs
A long time ago I bought a geiger counter for crypto exploration. Problem is, you can't buy rad sources strong enough to generate enough entropy (which is *still* subject to conditioning of course, despite the hype, and any way a GM tube will saturate..). Even if you take your smoke detector apart and use an alpha-windowed tube. But a detuned FM radio card seemed to do quite well. Admittedly, no white vans driving my amps. Are these sources not supported as entropy sources? (Pardon my linux randomness being out of date) Also, why u no trust Intel's RNG? :-) Physical otp key exchange can't be beaten... unless your correspondent is beaten.. silk burns clean, cyanide terminates the session "..trying to avoid sinning in the von Neumann sense.." I wish to God these calculations could be done by a steam engine," Babbage complained
Has anyone tried using an entropy broker (see https://lwn.net/Articles/546428/) for sharing entropy between devices on a physical network? https://we.riseup.net/debian/entropy#entropy-key seems to suggest that this is something that people do. On Wed, Jul 24, 2013 at 11:56 PM, David Honig <dahonig@cox.net> wrote:
On Wed, Jul 24, 2013 at 7:27 PM, Andy Isaacson <adi@hexapodia.org> wrote:
My /dev/random generates a few hundred kilobytes a day. I exchange OTPs
A long time ago I bought a geiger counter for crypto exploration. Problem is, you can't buy rad sources strong enough to generate enough entropy (which is *still* subject to conditioning of course, despite the hype, and any way a GM tube will saturate..). Even if you take your smoke detector apart and use an alpha-windowed tube.
But a detuned FM radio card seemed to do quite well. Admittedly, no white vans driving my amps. Are these sources not supported as entropy sources? (Pardon my linux randomness being out of date)
Also, why u no trust Intel's RNG? :-)
Physical otp key exchange can't be beaten... unless your correspondent is beaten.. silk burns clean, cyanide terminates the session
"..trying to avoid sinning in the von Neumann sense.."
**
** I wish to God these calculations could be done by a steam engine,” Babbage complained
-- Yan Zhu http://web.mit.edu/zyan/www/
On Jul 24, 2013, at 10:45 PM, Yan Zhu <yan@mit.edu> wrote:
Has anyone tried using an entropy broker (see https://lwn.net/Articles/546428/) for sharing entropy between devices on a physical network? https://we.riseup.net/debian/entropy#entropy-key seems to suggest that this is something that people do.
Some time ago, I ended up being a mentor in some coding thing. Vagueness is there to protect the guilty. The project in question was for some program to communicate using one-time pads. That the pad in a one-time-pad must be full-entropy is why it's relevant. The question came up of how you distribute the pads, because that's the key problem (nyuck, nyuck) in doing a one-time-pad system. The solution the person came up with was to encrypt them with PGP using a 4K-bit RSA key. I leave commentary on this system to the reader, and won't spoil the thought experiment with my own, at the moment. This entropy broker strikes me as exactly the same sort of understanding. Jon
It is easy to be a central source for randomness. The problem is that, for crypto, you want secret and private randomness. Whether it is reasonable to use randomness from an outside source to supplement the entropy on your own system depends on your threat model. If you absolutely require true randomness, and you are entropy constrained on the local device, and you are not concerned about compromise of the entropy server or the path between you and that server, then this might make sense. Lots of "ifs". -Lance -- Lance Cottrell loki@obscura.com On Jul 30, 2013, at 10:28 AM, Jon Callas <jon@callas.org> wrote:
On Jul 24, 2013, at 10:45 PM, Yan Zhu <yan@mit.edu> wrote:
Has anyone tried using an entropy broker (see https://lwn.net/Articles/546428/) for sharing entropy between devices on a physical network? https://we.riseup.net/debian/entropy#entropy-key seems to suggest that this is something that people do.
Some time ago, I ended up being a mentor in some coding thing. Vagueness is there to protect the guilty.
The project in question was for some program to communicate using one-time pads. That the pad in a one-time-pad must be full-entropy is why it's relevant. The question came up of how you distribute the pads, because that's the key problem (nyuck, nyuck) in doing a one-time-pad system.
The solution the person came up with was to encrypt them with PGP using a 4K-bit RSA key. I leave commentary on this system to the reader, and won't spoil the thought experiment with my own, at the moment.
This entropy broker strikes me as exactly the same sort of understanding.
Jon
On Tue, Jul 30, 2013 at 10:28:46AM -0700, Jon Callas wrote:
This entropy broker strikes me as exactly the same sort of understanding.
I don't see how one couldn't prime the kernel entropy pool from a high-quality high-rate entropy source on a trusted local, physical network. As long as multiple machines are guaranteed not to share the same entropy bits I don't see an attack angle there.
participants (5)
-
David Honig -
Eugen Leitl -
Jon Callas -
Lance Cottrell -
Yan Zhu