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