tech-crypto archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Patch: cprng_fast performance - please review.


If you want to get rid of RC4, use AES in CTR mode. It is standard,
compact, clean, and really fast solution. May sound boring, but gives
me a feel of solid security engineering.

Note that majority of systems now have the AES-NI instructions which
speed up AES implementations by an order of magnitude. The
implementations have a really small code + ram footprint. And it is a
freaking military standard: NSA "Suite B", classified up to top secret

Note that eSTREAM is not a standard. It was basically an EU-funded
academic exercise for the PhD factories in EU that do cryptography. I
was there; I was one of those crypto PhD students; and I did break
some of the other proposals. I would not call HC ciphers as robust,
well studied ciphers.

- markku

Dr. Markku-Juhani O. Saarinen <>  US +1 (424) 666 2713

On Fri, Apr 18, 2014 at 7:47 PM, Taylor R Campbell
<> wrote:
>    Date: Fri, 18 Apr 2014 12:38:38 -0400
>    From: Thor Lancelot Simon <>
>            3) If the algorithm's use of state-dependent array indices
>               presents a real weakness in practice, why aren't there any
>               published results on this and why was it chosen as, and
>               does it still remain in, the eSTREAM software portfolio?
> Hardly anyone uses HC-128, so there's no glory in publishing a
> practical timing attack on it.  It has been clear since 1996, and it
> has become abundantly clear in the past year with multiple practical
> timing attacks on OpenSSL and GnuPG, that timing side channels are a
> serious issue.  It would be irresponsible of us to make new choices
> that invite timing side channels, and secret-dependent array indices
> do precisely that.
> For what it's worth, there has been some work on cache-timing attacks
> on HC-128/256: <>.
>            4) If you've got a better suggestion of a stream cipher to use
>               for this purpose, please make it.  I looked at all the eSTREAM
>               ciphers and this one really looks like the best suited to me.
> I would still suggest Salsa20 or ChaCha.  My measurements with naive C
> code suggest that, if you buffer the output for short outputs, these
> take on average 40-50 Ivy Bridge cycles per request.  (If you don't
> buffer the output, it's 300 cycles.)  Long requests get ~4 cpb.  In
> contrast, libc random(3) takes on average 50-60 Ivy Bridge cycles per
> request, and long requests get ~13 cpb.
> There's high public confidence in Salsa20 and ChaCha, we don't have to
> worry about cache-timing side channels, we don't have to worry about
> hurting the cache, and we don't have to worry about using an obscure
> algorithm even if eSTREAM did select it.
>    Here's what I don't want to do: adjust the bookkeeping and leave us
>    using RC-4.  It is dangerously broken.  I am very hesitant to commit
>    any changes to HEAD which overhaul this code in any way but leave RC-4
>    in use.
> We certainly need to get rid of RC4.  We don't need to get rid of it
> in one single commit, though.  A commit that makes it easier to get
> rid of RC4 by separating the algorithm from the bookkeeping is still
> worthwhile.

Home | Main Index | Thread Index | Old Index