[ECOS] Entropy gathering?

[ECOS] Entropy gathering?

[Grant Edwards]

I'm working on adding some secure protocol support (ssl/ssh) to
an eCos app, and the libraries implmenting the protocols need a
source of cryptologically secure random bits.  I've been
searching through the eCos source tree, and there don't appear
to be any sort entropy gathering hooks anywhere.

The BSD stacks appear to use an aRC4 keystream for "random"
data. The stream uses a constant seed and then mixes in the
system clock value.  It could be worse, but it's not great
either.

Has any thought been given to providing a mechanism to gather
some entropy from the timing of interrupts generated externally
(network, serial ports, etc.)?

-- 
Grant Edwards                   grante             Yow! If I pull this SWITCH
                                  at               I'll be RITA HAYWORTH!!
                               visi.com            Or a SCIENTOLOGIST!


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[ECOS] Re: Entropy gathering?

[Grant Edwards]

On 2008-04-03, Grant Edwards <grante@visi.com> wrote:

> The BSD stacks appear to use an aRC4 keystream for "random"
> data. The stream uses a constant seed and then mixes in the
> system clock value.  It could be worse, but it's not great
> either.

Upon reading the above statement, I think I should clarify that
the "system time" that's mixed in is the HAL's hardware counter
value and not the system tick count time.  The hardware counter
is changing much faster (a good thing), but it provides
relatively few bits (on my targets, it ranges from 14-18).

-- 
Grant Edwards                   grante             Yow! My mind is making
                                  at               ashtrays in Dayton ...
                               visi.com            


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

RE: [ECOS] Re: Entropy gathering?

[Jay Foster]

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.

Jay

-----Original Message-----
From: Grant Edwards [mailto:grante@visi.com]
Sent: Thursday, April 03, 2008 12:18 PM
To: ecos-discuss@sources.redhat.com
Subject: [ECOS] Re: Entropy gathering?


On 2008-04-03, Grant Edwards <grante@visi.com> wrote:

> The BSD stacks appear to use an aRC4 keystream for "random"
> data. The stream uses a constant seed and then mixes in the
> system clock value.  It could be worse, but it's not great
> either.

Upon reading the above statement, I think I should clarify that
the "system time" that's mixed in is the HAL's hardware counter
value and not the system tick count time.  The hardware counter
is changing much faster (a good thing), but it provides
relatively few bits (on my targets, it ranges from 14-18).

-- 
Grant Edwards                   grante             Yow! My mind is making
                                  at               ashtrays in Dayton ...
                               visi.com            


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[ECOS] Re: Entropy gathering?

[Grant Edwards]

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 spent quite a while searching through the source tree for
random-number resources yesterday and never found it.  I just
grepped through ecos.db and through all the filenames in the
source tree and didn't get any hits on the string 'random' or
'RANDOM'.  I also grepped through all of the c/c++ files and
never found the string '/dev/random'.  It seems to be well
hidden...

-- 
Grant Edwards                   grante             Yow! I'm having a RELIGIOUS
                                  at               EXPERIENCE ... and I don't
                               visi.com            take any DRUGS


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

RE: [ECOS] Re: Entropy gathering?

[Jay Foster]

I hadn't realized that this was also implemented by a colleague and is not
part of the public eCos.  Never mind.
Jay

-----Original Message-----
From: Grant Edwards [mailto:grante@visi.com]
Sent: Thursday, April 03, 2008 12:53 PM
To: ecos-discuss@sources.redhat.com
Subject: [ECOS] 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 spent quite a while searching through the source tree for
random-number resources yesterday and never found it.  I just
grepped through ecos.db and through all the filenames in the
source tree and didn't get any hits on the string 'random' or
'RANDOM'.  I also grepped through all of the c/c++ files and
never found the string '/dev/random'.  It seems to be well
hidden...

-- 
Grant Edwards                   grante             Yow! I'm having a
RELIGIOUS
                                  at               EXPERIENCE ... and I
don't
                               visi.com            take any DRUGS


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[ECOS] Re: Entropy gathering?

[Grant Edwards]

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

Re: [ECOS] Re: Entropy gathering?

[Markus Schaber]

Hi, Grant,

Grant Edwards <grante@visi.com> wrote:

> 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.

Maybe you can ask in the UseNet Newsgroup sci.crypt (after assuring that
their FAQ doesn't contain some useful pointers).

Also, libtomcrypt or the CryptoPP lib may contain entropy code.
OpenSSL / GnuTLS definitely have, but they both are rather heavyweight.

And "Applied Cryptography" by Bruce Schneier, and "Cryptograpyh for
developers" by Tom St. Denis may be worth a look.

There are also some recent articles analyzing the entropy pools from
Linux, BSDish Systems and Windows, where some weaknesses showed up.


Cryptography is a field of mines, and most ad-hoc implementations by
non-experts turn out to be severely broken some time after deployment.


Regards,
Markus

-- 
Markus Schaber | Logical Tracking&Tracing International AG
Dipl. Inf.     | Software Development GIS

Fight against software patents in Europe! www.ffii.org
www.nosoftwarepatents.org

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[ECOS] Re: Entropy gathering?

[Grant Edwards]

On 2008-04-04, Markus Schaber <schabi@logix-tt.com> wrote:

>> 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.
>
> Maybe you can ask in the UseNet Newsgroup sci.crypt (after
> assuring that their FAQ doesn't contain some useful pointers).

Thanks, I'll check the sci.crypt FAQ.  I should have thought of
that. I also found that googling for "entropy pool" found some
useful stuff.  I had been googling for entropy gathering and
entropy extraction without much luck.

> Also, libtomcrypt or the CryptoPP lib may contain entropy
> code. OpenSSL / GnuTLS definitely have, but they both are
> rather heavyweight.

Yup.  We porting OpenSSL (and looked at some of the other
ports) before deciding on a different SSL library (which
requires an external entropy source).

> And "Applied Cryptography" by Bruce Schneier, and
> "Cryptograpyh for developers" by Tom St. Denis may be worth a
> look.

I've got Schneier, Kelsy, and Ferguson's Yarrow paper, and that
looks like a good starting point.  I really ought to buy
Schneier's book. [Funny thing: it turns out that Bruce Schneier
lives about six blocks from me (and I drive past his house
regularly).  And he used to live about 2 miles from my sister's
house which is 400+ miles away from here.]

> There are also some recent articles analyzing the entropy
> pools from Linux, BSDish Systems and Windows, where some
> weaknesses showed up.
>
> Cryptography is a field of mines, and most ad-hoc
> implementations by non-experts turn out to be severely broken
> some time after deployment.

I know.  That's why I'm a bit worried about using eCos's
arc4_random() as an entropy source for crypto purposes.

-- 
Grant Edwards                   grante             Yow! Thousands of days of
                                  at               civilians ... have produced
                               visi.com            a ... feeling for the
                                                   aesthetic modules --


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[ECOS] Re: Entropy gathering?

[Daniel Néri]

Grant Edwards <grante@visi.com> writes:

>  I really ought to buy Schneier's book.

It's available for free download:

  http://www.cacr.math.uwaterloo.ca/hac/


Regards,
-- 
Daniel Néri <daniel.neri@sigicom.com>
Sigicom AB, Stockholm, Sweden


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Re: Entropy gathering?

[Markus Schaber]

Hi, Daniel,

daniel.neri@sigicom.com (Daniel Néri) wrote:

> Grant Edwards <grante@visi.com> writes:
> 
> >  I really ought to buy Schneier's book.
> 
> It's available for free download:
> 
>   http://www.cacr.math.uwaterloo.ca/hac/

But it doesn't hurt to buy it either:

- Some always prefer a physical book for handling reasons.

- Bruce Schneier deserves to earn some bucks for his great work.


Regards,
Markus

-- 
Markus Schaber | Logical Tracking&Tracing International AG
Dipl. Inf.     | Software Development GIS

Fight against software patents in Europe! www.ffii.org
www.nosoftwarepatents.org

--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss