Re: Patch: cprng_fast performance - please review.

[Thor Lancelot Simon <tls%panix.com@localhost>]

Thank you for looking at this!

On Thu, Apr 17, 2014 at 09:33:28PM +0000, Taylor R Campbell wrote:
> 
> And the only performance constraint is that its single-threaded
> performance should not be worse than the existing arc4random-based
> cprng_fast.

This, I don't agree with, unless we're going to compare to the
existing arc4random-based cprng_fast *with the mutex removed* (which
makes it incorrect, but restores its performance to what it originally
was before we observed the correctness problem).

As I mentioned to you privately, I'm glad to run that and related tests
and see whether it's worth exposing cprng_fast's guts in the header
file or not.

> stream ciphers.  I'd never heard of hc128, so I'm nervous about it.
> Have you consulted any cryptographers about confidence in its
> security?

HC-128 is one of the eSTREAM software portfolio ciphers.  There's not
really a higher endorsement you can get for a stream cipher than that,
at the present time.  This might offer some useful context:

        http://lists.randombit.net/pipermail/cryptography/2013-July/004787.html

The other reason HC-128 is a nice fit here is that it has a short output,
which is slightly more convenient to work with (of course, RC4's 8-bit
output was even nicer that way).

> Have you done any side channel analysis of hc128?  A quick glance at
> it suggests it uses only addition, bitwise operations, constant
> rotation, and data-independent memory references, which is promising,
> but I haven't looked closely.  We ought to avoid adopting any new
> crypto that has known or predictable side channel attacks.

This looks like the latest word on side channel analysis of HC-128:

        
http://www.koreascience.or.kr/article/ArticleFullRecord.jsp?cn=SOJBB3_2012_v17n6_11

Unfortunately it is in Korean.  I don't know anyone who is familiar with
this paper but I will ask around.

Thor