Python Random Number Generator for OTP

[Lance Cottrell]

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 at obscura.com



On Jul 30, 2013, at 10:28 AM, Jon Callas <jon at callas.org> wrote:

> 
> On Jul 24, 2013, at 10:45 PM, Yan Zhu <yan at 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
> 
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/html
Size: 3491 bytes
Desc: not available
URL: <http://lists.cpunks.org/pipermail/cypherpunks/attachments/20130730/85b89ec4/attachment-0001.txt>