Messages in this thread | | | From | David Lang <> | Date | Sun, 17 Aug 2003 23:55:24 -0700 (PDT) | Subject | Re: [RFC][PATCH] Make cryptoapi non-optional? |
| |
On Mon, 18 Aug 2003, Andreas Dilger wrote:
> Subject: Re: [RFC][PATCH] Make cryptoapi non-optional? > > On Aug 15, 2003 23:38 -0500, Matt Mackall wrote: > > a) extract_entropy (pool->lock) > > > > For nitpickers, there remains a vanishingly small possibility that > > two readers could get identical results from the pool by hitting a > > window immediately after reseeding, after accounting, _and_ after > > feedback mixing. > > It wasn't even vanishingly small... We had a problem in our code where > two readers got the same 64-bit value calling get_random_bytes(), and > we were depending on this 64-bit value being unique. This problem was > fixed by putting a spinlock around the call to get_random_bytes().
if the number is truely random then there should be a (small but finite) chance that any two reads will return the same data. counting on a random number to be unique is not a good idea.
now if you can repeatably get the same number then you probably have a bug in the random number code, but if you need uniqueness you need something else.
David Lang - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |