This is the mail archive of the ecos-discuss@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Entropy gathering?


On 2008-04-03, Jay Foster <jay@systech.com> 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]