Re: generic crypto

[Paul Eggert]

Simon Josefsson <address@hidden> writes:

> * Perhaps the /dev/*random reading should be separated into a separate
>   module?  It might be useful outside of the gc layer too.

Absolutely.  I've been meaning to do that for months (for a "shuffle"
program I want to add to coreutils), but hadn't gotten around to it.
It would have to be generalized a bit.  I'd like to have the file
descriptor cached, for example.

>   I'm also not sure about the names of those functions, they suggest
>   a more higher-level API than what is really offered (i.e., the
>   names "nonce" and "pseudo_random" and "random" imply certain
>   cryptographic properties).

Could you expand a bit more on that?  What is the relationship between
nonce/pseudorandom/random and the /dev/ values you are using?  For
example, why not use OpenBSD's /dev/arandom?

Here is one thought.  The user could specify a desired quality level
range, and the implementation then would supply random data that is at
least as good as the lower bound of the range.  I.e., ihe
implementation refuses to produce any random data if it can't generate
data that is at least as good as the lower end of the range.  The
upper bound of the range is advice from the user not to be any more
expensive than that, but the implementation can ignore the advice if
it doesn't have anything cheaper.

For a set of quality levels we could use OpenBSD's (since it is the
fanciest).

> Perhaps gc_dev_random and gc_dev_urandom?

To some extent.  I'd rather insulate the user from the details of
where the random numbers come from.  On the other hand we need to
provide a way for applications to specify a file that contains
random bits, so that people can override the defaults.