Path: csiph.com!usenet.pasdenom.info!weretis.net!feeder1.news.weretis.net!feeder.erje.net!eu.feeder.erje.net!xlned.com!feeder1.xlned.com!news2.euro.net!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail Return-Path: X-Original-To: python-list@python.org Delivered-To: python-list@mail.python.org X-Spam-Status: OK 0.045 X-Spam-Evidence: '*H*': 0.91; '*S*': 0.00; 'output': 0.05; 'sufficient': 0.05; 'correct.': 0.07; 'removes': 0.07; 'quiet': 0.09; 'subject:script': 0.09; 'random': 0.14; "wouldn't": 0.14; '(modulo': 0.16; '10:05': 0.16; 'attached,': 0.16; 'benjamin': 0.16; 'buffer.': 0.16; 'components.': 0.16; 'considers': 0.16; 'does,': 0.16; 'from:addr:rosuav': 0.16; 'from:name:chris angelico': 0.16; 'https': 0.16; 'kern': 0.16; 'sources,': 0.16; 'storing': 0.16; 'subject:random': 0.16; 'wrote:': 0.18; 'drawing': 0.19; 'pointed': 0.19; 'server,': 0.19; 'thu,': 0.19; 'bytes': 0.24; 'driver': 0.24; 'instance,': 0.24; 'mathematical': 0.24; 'typical': 0.24; '(or': 0.24; 'source': 0.25; 'header:In- Reply-To:1': 0.27; 'external': 0.29; 'nature': 0.30; 'robert': 0.30; 'message-id:@mail.gmail.com': 0.30; "i'm": 0.30; '(which': 0.31; '(on': 0.31; 'asks': 0.31; 'block,': 0.31; 'container': 0.31; 'continually': 0.31; "d'aprano": 0.31; 'maintains': 0.31; 'steven': 0.31; 'critical': 0.32; 'maintaining': 0.32; 'run': 0.32; 'says': 0.33; 'sources': 0.33; 'device': 0.34; 'sense': 0.34; "i'd": 0.34; 'could': 0.34; 'problem': 0.35; 'but': 0.35; 'received:google.com': 0.35; 'add': 0.35; 'really': 0.36; 'accessible': 0.36; 'described': 0.36; 'disk': 0.36; 'doing': 0.36; "i'll": 0.36; 'too': 0.37; 'operating': 0.37; 'being': 0.38; 'server': 0.38; 'filled': 0.38; 'machines': 0.38; 'to:addr:python- list': 0.38; 'pm,': 0.38; 'moving': 0.39; 'to:addr:python.org': 0.39; 'called': 0.40; 'even': 0.60; 'flat': 0.60; 'referred': 0.60; 'serving': 0.60; 'slowly': 0.60; 'worry': 0.60; 'most': 0.60; 'helps': 0.61; "you're": 0.61; 'times': 0.62; 'high': 0.63; 'skip:n 10': 0.64; 'grab': 0.64; 'provide': 0.64; 'details': 0.65; 'computers': 0.72; 'electrical': 0.74; 'special': 0.74; 'guaranteed': 0.75; 'air,': 0.84; 'cautious': 0.84; 'cylinder': 0.84; 'drive.': 0.84; 'noise': 0.84; 'oscar': 0.84; 'shutdown': 0.84; 'subject:long': 0.84; 'thermal': 0.84; 'subject:very': 0.91; 'delivers': 0.93; '2013': 0.98 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=odIBA45Arnu1xdj8EGRjDPVdsQg9NkrUJ/vHKXi4BfQ=; b=qnBb1/pyqXRNMCXSsjJ4N93zxDd2YaNLQKTv5aZEO/heiUVCOx7dr7qNe7Zb+Rq+cu IASM1gqJC0XaYgYgdskkf/DNs6TXgLIdzXJQah+F6wefk3g5F5rkM5x1XNIdIV7YQ018 cHu1iiDxYUqWc0Bp+CDy6lSNXIdbeSxB2pXCRdx7SMuky5zGXRcGL9MBE80cZ1sdtQAA E6Smcx/TntKbnLBV55qBYJJ/j+SfdDQJW3UPfWEz9ZblKNOrpWJ34pVAJwPH4Q5sabZP KDBXYvQL4BNEWty2tT9LsZUrmMBwX1I37zEex2z4hMjZY2+Pb/dbw9n32AweN2hjc6pg sa+A== MIME-Version: 1.0 X-Received: by 10.58.75.46 with SMTP id z14mr4987253vev.52.1365688587404; Thu, 11 Apr 2013 06:56:27 -0700 (PDT) In-Reply-To: References: <24dc619b-7abd-4be3-aa92-f858eb4ab85f@n4g2000yqj.googlegroups.com> <51666aae$0$29977$c3e8da3$5496439d@news.astraweb.com> <51669576$0$29977$c3e8da3$5496439d@news.astraweb.com> Date: Thu, 11 Apr 2013 23:56:27 +1000 Subject: Re: performance of script to write very long lines of random chars From: Chris Angelico To: python-list@python.org Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: python-list@python.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion list for the Python programming language List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Newsgroups: comp.lang.python Message-ID: Lines: 50 NNTP-Posting-Host: 2001:888:2000:d::a6 X-Trace: 1365688589 news.xs4all.nl 2680 [2001:888:2000:d::a6]:59298 X-Complaints-To: abuse@xs4all.nl Xref: csiph.com comp.lang.python:43370 On Thu, Apr 11, 2013 at 10:05 PM, Oscar Benjamin wrote: > On 11 April 2013 11:50, Steven D'Aprano > wrote: >> Some (most?) modern operating systems provide a cryptographically strong >> source of non-deterministic randomness. The non-deterministic part comes >> from external "stuff", which is called "entropy". Typical sources of >> entropy include network events, user key-presses, moving the mouse, and >> (presumably in machines with special hardware), even thermal noise in >> electrical components. > >> Entropy is used and discarded, so urandom needs the OS to continually >> replenish the amount of entropy. Under normal circumstances, this it >> does, but if you grab lots of urandom output on a system which is >> otherwise quiet and not doing anything, it could run out. > > Okay, so I understand what entropy is in the thermodynamic sense and > also in the mathematical (Shannon) sense but I'm still confused about > what it means that the OS is somehow storing entropy. Do you mean that > it is always maintaining a buffer of what it considers to be random > bytes that it slowly builds up from noise that is made accessible to > the OS from the hardware? Correct. And Steven's right about most of what he says (modulo the urandom vs random distinction, as Robert Kern pointed out - urandom won't block, but it's not guaranteed to be cryptographically secure); I'll just add that one of the best sources of entropy is a solid cylinder, rotated at high velocity in a sealed container filled with a fluid, and entropy is found in the eddies. Many computers have a device of this nature - the solid cylinder is thin and flat and referred to as a "disk", the fluid it's in is air, and the sealed container is your hard disk drive. The details will vary, but broadly speaking, the /dev/random driver (or its equivalent) maintains an ever-increasing buffer of entropic bits, accumulated as they arrive from the various sources, and often saved to disk on shutdown to permit faster boot (which helps to avoid the problem Steven described of 70-minute boot times - on an all-SSD computer with no human being attached, entropy really can be very hard to obtain); whenever a program asks for bytes from it, it delivers them and removes that much "recorded entropy" from its buffer. For many purposes, it's sufficient to take 4 or 8 bytes of /dev/random entropy and use that to seed a PRNG, but if you're using /dev/urandom and it's not a critical server, I wouldn't worry too much about drawing too much off it. (On a web server that's constantly serving HTTPS requests, for instance, I'd be cautious about reading too much from /dev/urandom as it might cause the web server to block waiting for /dev/random. Might kill your TPS for a while.) ChrisA