Re: cprng_fast implementation benchmarks

On Fri, Apr 25, 2014 at 08:58:54PM +0000, [email protected] wrote:
> 
> But what X are we talking about?  Security analysis does not come from
> generalities, it comes from the point by point analysis of specific
> questions.  You correctly point out that some attacks may not be
> relevant.  Which attacks are not relevant, and which ones are, and why?

I feel like you keep moving the goal posts.  I have a limited amount of
time to respond -- I wish I had more.  But this is going to be my last
message on this topic.

If you want a rigorous, numerical analysis of threat and risk, I can't give
you one.  I offered a number of examples and pointed out what seemed like
commonalities to me.  Perhaps they don't seem that way to you.

This, I can say: you started out by objecting (as far as I can tell) to what
you perceived as a weakening of the kernel strong cprng.  That is not the
case.  Then -- it seems to me -- you changed over to arguing that there was
no point to having both strong and fast cryptograpnic prngs in the kernel.

Then -- inexplicably to me -- you seemed to change tack to arguing that
the proposed fast cprng might not be strong enough.  I suppose you are
entitled to change your mind.  God knows I do often enough.

Here is the bottom line for me; perhaps I did not get it across clearly
enough last time:

	* There are certain cases in our kernel for which:

		* We cannot use the strong CPRNG without causing
		  undue performance impact, but

		* Where in these exact or closely analogous cases
		  real security issues have resulted from the use
		  of non-cryptographic PRNGs such as LCGs.

	* Fortunately for many of these cases the cost per try for
	  an attack on the PRNG is high, which suggests -- though we
	  cannot give a precise numerical estimate -- that a PRNG
	  considerably weaker than the strong CPRNG is acceptable.

	* Even better, in many of these cases the PRNG need resist
	  attack only for a limited lifetime such as that of a
	  single network connection or a single process.

	* For these cases we would like something that we can only
	  rather vaguely describe as "somewhat stronger than the
	  non-cryptographic generators but much faster than the
	  strong CPRNG".

	* The rough consensus of the developers is that ChaCha8, which
	  is much faster than the CTR_DRBG *or* the previous cprng_fast
	  implementation, and much stronger than old implementation,
	  is a very good match for these -- admittedly informal --
	  requirements.

As an aside, a stream cipher from the Salsa/ChaCha family was the
recommendation of two different cryptographers independently consulted
by Taylor and myself for this application.  I am not comfortable dialing
back the number of rounds further to get more speed, nor do I think we
need more rounds to get more security.  But since this cipher is never
used to key anything that persists, we can adjust this in the future if
at that time, it seems wise.

Thor