[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [avr-libc-dev] rand(3) in avr-libc
From: |
E. Weddington |
Subject: |
Re: [avr-libc-dev] rand(3) in avr-libc |
Date: |
Tue, 10 Sep 2002 09:45:30 -0600 |
On 10 Sep 2002 at 12:44, Joerg Wunsch wrote:
> As Joerg Wunsch wrote:
>
> OK, here it goes.
>
> It fixes the remaining problems with using long constants in the
> source code (that silently got truncated to 16 bits before), it uses
> the newer algorithm by default to produce better randomness, and IMHO
> we also need to pass an unsigned long * (as opposed to an unsigned *)
> in rand_r() since we'd otherwise truncate the temporary storage which
> defeats the entire algorithm. Even the old algorigthm (that's used if
> USE_WEAK_SEEDING is defined) required a `long' for temporary storage.
>
> As for supplying an additional set of functions returning long instead
> of the standards-mandated int, there are two options i would see:
>
> 1 We copy over the existing rand.c into a random.c, and just replace
> the result type (and the type passed to srandom()) from `int' to
> `long', including of course using RANDOM_MAX == 0x7fffffff for
> limiting the result. The advantage is that the resulting file will
> still be relatively small (~ 300 bytes of ROM).
>
> 2 We port over the full-fledged random.c from BSD. This would offer a
> more sophisticated pseudo-random number generator that while using
> the same algorithm that's now in the proposed rand.c file, can use a
> lot more of temporary storage for state information (up to 256
> bytes) to increase the period. To quote the BSD man page:
>
> With 256 bytes of state information, the period of the random
> number generator is greater than 2**69 which should be sufficient
> for most purposes.
>
> However, porting this file would make it consume about 2 KB of flash
> ROM when linked into the binary, for the added value of providing a
> PRNG that could even be used for cryptographic purposes provided it
> is getting seeded with a value that is unpredictable enough (which
> is outside the scope of the library implementation, of course).
>
> What would people prefer?
I'm always one for having standard ways of doing things as a base,
then additional things that add value.
Adding functions for a 32-bit PRNG (item #1 above) seem like it would
be useful. Especially for the smaller devices.
I would also think that item #2 would be something desirable and adds
value as well. I don't necessarily like the idea of not including
functionality just because it doesn't fit the least common
denominator, i.e. the smallest devices. That's why there is a variety
of devices to begin with. However, if #2 is implemented, it seems
that 3 things should stem from that: 1. document the limitation of
the library, i.e. for use in larger devices. 2. add a (small?) crypto
package to take advantage of the new PRNG. 3. document different
possible ways of generating seed values.
It would be kinda cool to say that, yes, avr-gcc / avr-libc offers a
crypto library. I don't see any other AVR toolset that offers such a
thing.
Eric
- [avr-libc-dev] rand(3) in avr-libc, Joerg Wunsch, 2002/09/09
- Re: [avr-libc-dev] rand(3) in avr-libc, Joerg Wunsch, 2002/09/09
- Re: [avr-libc-dev] rand(3) in avr-libc, Theodore A. Roth, 2002/09/09
- Re: [avr-libc-dev] rand(3) in avr-libc, Joerg Wunsch, 2002/09/09
- Re: [avr-libc-dev] rand(3) in avr-libc, Joerg Wunsch, 2002/09/10
- Re: [avr-libc-dev] rand(3) in avr-libc, Joerg Wunsch, 2002/09/10
- Re: [avr-libc-dev] rand(3) in avr-libc,
E. Weddington <=
- Re: [avr-libc-dev] rand(3) in avr-libc, Joerg Wunsch, 2002/09/10
- Re: [avr-libc-dev] rand(3) in avr-libc, Theodore A. Roth, 2002/09/10
- Re: [avr-libc-dev] rand(3) in avr-libc, E. Weddington, 2002/09/10
- Re: [avr-libc-dev] rand(3) in avr-libc, Theodore A. Roth, 2002/09/10
- Re: [avr-libc-dev] rand(3) in avr-libc, E. Weddington, 2002/09/10
- Re: [avr-libc-dev] rand(3) in avr-libc, Joerg Wunsch, 2002/09/10
- Re: [avr-libc-dev] rand(3) in avr-libc, Joerg Wunsch, 2002/09/10
- Re: [avr-libc-dev] rand(3) in avr-libc, ken restivo, 2002/09/10