From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22546 invoked by alias); 3 Apr 2008 21:49:29 -0000 Received: (qmail 22534 invoked by uid 22791); 3 Apr 2008 21:49:28 -0000 X-Spam-Check-By: sourceware.org Received: from main.gmane.org (HELO ciao.gmane.org) (80.91.229.2) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 03 Apr 2008 21:49:02 +0000 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1JhXIm-0004f8-PK for ecos-discuss@sources.redhat.com; Thu, 03 Apr 2008 21:48:56 +0000 Received: from 64.251.14.41 ([64.251.14.41]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 03 Apr 2008 21:48:56 +0000 Received: from grante by 64.251.14.41 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 03 Apr 2008 21:48:56 +0000 To: ecos-discuss@sources.redhat.com From: Grant Edwards Date: Thu, 03 Apr 2008 22:29:00 -0000 Message-ID: References: <74C9525D67A5FF4791614FDB06593BB10429A50C@mail.systech.com> User-Agent: slrn/0.9.8.1pl1 (Linux) X-IsSubscribed: yes Mailing-List: contact ecos-discuss-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@ecos.sourceware.org Subject: [ECOS] Re: Entropy gathering? X-SW-Source: 2008-04/txt/msg00059.txt.bz2 On 2008-04-03, Jay Foster wrote: >> A colleague implemented something like this by creating a >> function that could be called from various places at random >> times, such as the ethernet driver (ether_input()), serial >> port modem signal changes, etc. The function would read the >> HAL microsecond clock value and write the lower 16-bits to >> /dev/random. After a pre-determined number of such events, >> this function would stop writing to /dev/random and simply >> return. > > Where's the source for /dev/random? > > I hadn't realized that this was also implemented by a > colleague and is not part of the public eCos. Never mind. For my application, something that doesn't rely on the FILEIO or POSIX packages would be best. Perhaps just a package that provides a simple API with two calls: one to add some "random" bits to the pool, and another to retreive a block of random bytes from the pool. I've been googling to find some source material on practical aspects of maintaining an entropy pool, but so far haven't found much of anything. Assume that we have an N-bit counter (let's say 8 <= N <= 16). Also assume that we have some interrupt sources that are uncorrelated with the counter and occur at a rate a couple orders of magnitude slower than the N-bit counter clock, how does one implement an entropy pool? Can one just capture counter values in ISRs and save them in a circular buffer, then run the buffer through some sort of hashing algorithm to try to remove any bias? What do you do when you "run out" of random bits in the circular buffer? Would mixing the "random" bits from the ISRs into the existing RC4 stream state be sufficient[1]? Would calling arc4_random() to read one byte of random data inside some ISRs would be a good idea? Or would that take too much time to be done in an ISR? And what about Naomi? [1] The existing arc4_random routine currently mixes in some bits from the N-bit counter but it only happens when the arc4_random function is called to read some data. I'm concerned that those calls are happening in eCos tasks, and the times that eCos tasks get woken up might be correlated with the counter values. Maybe I'm just paranoid... -- Grant Edwards grante Yow! I'm having a at quadrophonic sensation visi.com of two winos alone in a steel mill! -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss