[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: cprng_fast implementation benchmarks
> > No. There is a "strong" RNG, based on the NIST SP800-90 CTR_DRBG with
> > AES128 as the block transform.
> > There is also a "fast" RNG, based on RC4.
> > We are discussing the replacement of the "fast" RNG.
> Ok. But if that’s a non-strong RNG, why are we discussing security
> properties? And why are we considering algorithms this complex, rather
> than using a PRNG?
> In other words, this is being treated like it’s in between a PRNG and a
> strong RNG. I don’t understand why there can be a middle ground like
> that, and what its required properties would be.
There are cases when both security and performance matters. Consider
TCP ISN generation or UDP port number generation (i.e. randomisation).
There are known security issues if these numbers can be predicted, but
at the same time, high performance penalty is undesirable in the network
stack. However, the requirements are a bit different: the life time of
a packet or connection tends to be much smaller than of some encrypted
and permanently stored piece of information. Arguably, given a short
life time, a weaker (but faster) CPRNG is enough for making potential
attacks unpractical. Do you disagree?
Finally, if we make a weaker CPRNG really fast, why bother with a third
implementation of PRNG?
Main Index |
Thread Index |