From jas at extundo.com Thu Sep 2 21:18:25 2004 From: jas at extundo.com (Simon Josefsson) Date: Thu Sep 2 21:15:31 2004 Subject: [gnutls-dev] Re: Memory leeks? References: <1093562548.5633.65.camel@hlod.pustal.lan> <87isb55577.fsf@wheatstone.g10code.de> <1093625582.28863.92.camel@hlod.pustal.lan> <87fz681hvm.fsf@wheatstone.g10code.de> <87oeks1zln.fsf@wheatstone.g10code.de> Message-ID: Werner Koch writes: >> How to generate randomness should probably be orthogonal to the crypto >> back end used as well. So here's the plan: > > I don't think so. A RNG is a basic building from cryptographic and > actually the hardest thing to do. Not providing an easy API for this > will for sure lead to improper use of the other building blocks. We > have seen in the past forgotten RNG intialization in many applications > and thus Libgcrypt tries its best to provide random by default. Right. I didn't mean that the interface should be different, all calls should go through the same gc random functions: /* Randomness. */ extern int gc_nonce (char *data, size_t datalen); extern int gc_pseudo_random (char *data, size_t datalen); extern int gc_random (char *data, size_t datalen); What might be possible to change at configure time would be whether those calls will use Libgcrypt, /dev/*random or Yarrow seeded from a specific file. Btw, I'm not completely happy with those API names, perhaps the last function should be called gc_strong_random. The problem is that the function typically return pseudo randomness, since that's what Libgcrypt and /dev/*random have. So then it is a bit confusing in what way gc_random differ from gc_pseudo_random. Perhaps it is best to avoid giving the impression that any of them have "real" randomness, just various level of entropy... Thanks, Simon