Does anyone on the list have some Python source code for an OTP-focused random number generator they'd be willing to share? I'm interested in seeing how different people would approach it?
On Mon, Jul 22, 2013 at 04:50:55PM -0400, Tom wrote:
Does anyone on the list have some Python source code for an OTP-focused random number generator they'd be willing to share? I'm interested in seeing how different people would approach it?
Why not simply use /dev/urandom (after ensuring you have enough entropy, etc, etc). If you don't have systemic entropy collection, Python is not going to be able to help. Of course any entropy pool measurement is merely computationally feasible randomness; you'll need to measure a physically nondeterministic process directly if you want true information theoretic entropy. Something like an entropykey should do the trick, if you trust their design and that they haven't included backdoors. -andy
On Mon, Jul 22, 2013 at 11:46 PM, Andy Isaacson <adi@hexapodia.org> wrote:
On Mon, Jul 22, 2013 at 04:50:55PM -0400, Tom wrote:
Does anyone on the list have some Python source code for an OTP-focused random number generator they'd be willing to share? I'm interested in seeing how different people would approach it?
Why not simply use /dev/urandom (after ensuring you have enough entropy, etc, etc). If you don't have systemic entropy collection, Python is not going to be able to help.
Of course any entropy pool measurement is merely computationally feasible randomness; you'll need to measure a physically nondeterministic process directly if you want true information theoretic entropy. Something like an entropykey should do the trick, if you trust their design and that they haven't included backdoors.
Andy, maybe you or someone else has some insight into something I've wondered about: Is there a secure way to timeshare a single entropy source such as an entropy key? High-quality entropy sources are often fragile, expensive, or difficult to manufacture and maintain. If Alice has a friggin' amazing entropy source, and Bob wants to use it from afar, what would be the best way for Alice to let Bob retrieve data from the entropy source when she wasn't using it? -Yan
-andy
-- Yan Zhu http://web.mit.edu/zyan/www/
On Tue, Jul 23, 2013 at 08:31:16AM +0200, Yan Zhu wrote:
Is there a secure way to timeshare a single entropy source such as an entropy key? High-quality entropy sources are often fragile, expensive, or difficult to manufacture and maintain. If Alice has a friggin' amazing entropy source, and Bob wants to use it from afar, what would be the best way for Alice to let Bob retrieve data from the entropy source when she wasn't using it?
If Bob requires *really* *great* entropy, why would he trust a network link (secured with a non information theoretically secure cipher such as AES) to transmit his entropy securely? If Bob is willing to trust merely computationally secure methods such as private key cryptography, he should gather "less high quality" entropy locally, using a pool implementation with good mixing, and trust that. In short -- asking someone else to generate your random numbers is, of course, a state of sin. -andy
________________________________ On Tue, Jul 23, 2013 at 08:31:16AM +0200, Yan Zhu wrote:
Is there a secure way to timeshare a single entropy source such as an entropy key? High-quality entropy sources are often fragile, expensive, or difficult to manufacture and maintain. If Alice has a friggin' amazing entropy source, and Bob wants to use it from afar, what would be the best way for Alice to let Bob retrieve data from the entropy source when she wasn't using it?
On Tuesday, 23 July 2013, 8:34:54, Andy Isaacson replied
If Bob requires *really* *great* entropy, why would he trust a network l>ink (secured with a non information theoretically secure cipher such as AES) to transmit his entropy securely?
Since the network seeks to compress data at every turn, I think we can say it knows entropy when it sees it. ...
In short -- asking someone else to generate your random numbers is, of course, a state of sin.
God told me to tell you to stop submitting the query https://duckduckgo.com/?q=random+number+between+0+and+100
On Tue, 23 Jul 2013 08:31:16 +0200 Yan Zhu <yan@mit.edu> wrote:
On Mon, Jul 22, 2013 at 11:46 PM, Andy Isaacson <adi@hexapodia.org> wrote: Is there a secure way to timeshare a single entropy source such as an entropy key? High-quality entropy sources are often fragile, expensive, or difficult to manufacture and maintain. If Alice has a friggin' amazing entropy source, and Bob wants to use it from afar, what would be the best way for Alice to let Bob retrieve data from the entropy source when she wasn't using it?
Reasonably good hardware RNGs are widely available. Just get yourself a RaspberryPI and use it for RN and keygen and crypto and airgapped computing and....
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA384 On 22/07/2013 23:46, Andy Isaacson wrote:
Why not simply use /dev/urandom (after ensuring you have enough entropy, etc, etc).
Why not use /dev/random, instead of "ensuring you have entropy" (how would you do that?)? /dev/random blocks if there's not enough entropy - whereas /dev/urandom will produce some pseudo-random bits. hannes -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) iQIcBAEBCQAGBQJR7jGJAAoJELyJZYjffCjuOZ8P/33PdQ7NklZbFHUiox/Oznn9 jFU+HUiW8qe/yVcOXuan91vD5F+fsM18uMmum7HCTBc6gbE/75UHuyitePQfZABm Ffe4CnkbQBA9aJw6ZyDgJiqc39JQjK9jTOrVVGLaYAKIQgwpKwz2Pb5IZ3u5W9lH z6eOlwRec3hfACjsfdLRBJ+DOjbR3y+2wCFUE4HyJjE8SjYF0go9qD95EGrWxQcW gNba4yFqLO0H5HcD/YY4sKAfo/HQUloer2f9bKkqd9GLlA+ZD9M37k3UJilOiF3u wpRo61jbgFc5IrmJS1TDuHBS71VR48S4GjHBLNmkTCJMBkwhJ1AGlNv2fTLKwaN9 Z5Pk5q3q+2l11BXdIwo8qfJb5Av9/ILXkeWtOlno/IvdDHCNMgFkPwZfswb83LDe bS4yeYGZ15MBbgBlC9aTmSI2esAdtU/29jSda7I8xTVL9i4o/KTZcsqDfKubdyrV 5g11R4rw1DN0UlMqokShTmLojk2ebU7MKgVCnL/nVbF0l4laa6rnUazaFGppOXhf gUrAw6K4GDsqs0Y2u9jHAaMk2t54zSv7I9KYFwdzVc08PFOFZp03x0qUSoRsE6qc 2yuQ8PJfRAAUAQAQulf1RLt+as++ROv8RxsbAtPGMK546aoa4Anp5b9mB5S5LVo+ /oDGKVtKZosxGBHhgfs6 =LFao -----END PGP SIGNATURE-----
Why not use /dev/random, instead of "ensuring you have entropy"
/dev/random limits the output size to the estimated entropy. So it has abysmal performance unless there are high performance entropy sources available. After the initial seeding this gains very little security in practice. /dev/urandom unblocks before it has sufficient entropy on some systems. So it's not guaranteed to be secure and sometimes fails in practice. What you normally want is a source that blocks after boot until it has accumulated enough initial entropy (say 256 bits), and then never blocks again. It's not like a good PRNG gets weaker as more data is read from it when your adversaries are computationally bounded.
Tom <ticom@sinister.com> writes:
Does anyone on the list have some Python source code for an OTP-focused random number generator they'd be willing to share? I'm interested in seeing how different people would approach it?
#! /usr/bin/python # SYNOPSIS # random-bytes <n> # DESCRIPTION # Writes n cryptographically strong random bytes to stdout. # Test with, e.g., random-bytes 16 | hd From os import urandom import sys sys.stdout.write(urandom(int(sys.argv[1]))) -- -- StealthMonger <StealthMonger@nym.mixmin.net> Long, random latency is part of the price of Internet anonymity. anonget: Is this anonymous browsing, or what? http://groups.google.ws/group/alt.privacy.anon-server/msg/073f34abb668df33?dmode=source&output=gplain stealthmail: Hide whether you're doing email, or when, or with whom. mailto:stealthsuite@nym.mixmin.net?subject=send%20index.html Key: mailto:stealthsuite@nym.mixmin.net?subject=send%20stealthmonger-key
At 01:50 PM 7/22/2013, Tom wrote:
Does anyone on the list have some Python source code for an OTP-focused random number generator they'd be willing to share? I'm interested in seeing how different people would approach it?
You can use Python or other languages to access your machine's hardware random number generator and mash them together with your plaintext. But your question sounds like you want to generate the random numbers themselves with Python software? print "You can't generate true random numbers in software. And you can't use pseudo-random numbers for OTP.\n %d", 1/0 ; (My python's a bit rusty, so the syntax may be wrong, but if so, that's a feature; the divide-by-zero is there just for insurance.)
2013-07-22 16:50:55 -0400 Tom <ticom@sinister.com>: | Does anyone on the list have some Python source code for an OTP-focused | random number generator they'd be willing to share? I'm interested in | seeing how different people would approach it? A sound card in your box then can deliver random numbers. You may wish to look into this: http://www.guyrutenberg.com/2010/05/14/audio-based-true-random-number-genera... This may also interest you; http://www.volkerschatz.com/science/audiorng.html
On Tue, Jul 23, 2013 at 10:04 AM, KPJ <kpj@sics.se> wrote:
A sound card in your box then can deliver random numbers.
You may wish to look into this:
http://www.guyrutenberg.com/2010/05/14/audio-based-true-random-number-genera...
This may also interest you;
For Debian-based Linux distros, e.g. Ubuntu, this is automated by the "randomsound" package: http://packages.debian.org/wheezy/randomsound sudo apt-get install randomsound There's also audio-entropyd, but I haven't used that: http://www.vanheusden.com/aed/ He has links to other entropy generators.
If you want to use a sound card as an entropy source, look at turbid, a solid design with well-documented analysis of its randomness: http://www.av8n.com/turbid/paper/turbid.htm For a timing-based source, look at haveged which is in Debian: http://www.issihosts.com/haveged/ but consider this critique: http://jakob.engbloms.se/archives/1374 For a cheap simple RNG that needs more analysis before it is seriously trusted, see my timing-based demon: ftp://ftp.cs.sjtu.edu.cn:990/sandy/maxwell/ Documentation there discusses several alternatives,
You can also build an apparently pretty decent white noise source by amplifying avalance noise in a reverse-biased diode. http://web.jfet.org/hw-rng.html As is the case with most random noise sources, you obviously want to whiten the output before adding it to your entropy pool. http://en.wikipedia.org/wiki/Hardware_random_number_generator#Software_white... -=rsw
As is the case with most random noise sources, you obviously want to whiten the output before adding it to your entropy pool.
Actually, you want to whiten it before output, not before input. Whitening before input is a problem, because you can't run an estimator on the input -- because it's been whitened. If you want to know the unbiased entropy of a source, you want the raw inputs. If you don't care about the unbiased entropy, then you don't. Jon
Exactly. Thanks for clarification Jon. --Michael Am 23.07.2013 um 20:39 schrieb Jon Callas <jon@callas.org>:
As is the case with most random noise sources, you obviously want to whiten the output before adding it to your entropy pool.
Actually, you want to whiten it before output, not before input. Whitening before input is a problem, because you can't run an estimator on the input -- because it's been whitened.
If you want to know the unbiased entropy of a source, you want the raw inputs. If you don't care about the unbiased entropy, then you don't.
Jon
Jon Callas <jon@callas.org> wrote:
If you want to know the unbiased entropy of a source, you want the raw inputs. If you don't care about the unbiased entropy, then you don't.
A fair point. I suppose what I should have said was that you want to whiten it before you actually try to *use* it :) -=rsw
participants (15)
-
Andy Isaacson -
Bill St. Clair -
Bill Stewart -
CodesInChaos -
Dabby Kish -
Hannes Mehnert -
jd.cypherpunks＠gmail.com -
Jon Callas -
KPJ -
Riad S. Wahby -
Ron Perry -
Sandy Harris -
StealthMonger -
Tom -
Yan Zhu