Simon Josefsson <[EMAIL PROTECTED]> 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. _______________________________________________ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
