Re: [avr-libc-dev] rand(3) in avr-libc

[E. Weddington]

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