[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.
Dr. Markku-Juhani O. Saarinen <mjos%iki.fi@localhost> US +1 (424) 666 2713
On Fri, Apr 18, 2014 at 7:47 PM, Taylor R Campbell
> Date: Fri, 18 Apr 2014 12:38:38 -0400
> From: Thor Lancelot Simon <tls%panix.com@localhost>
> 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: <http://erikzenner.name/docs/2008_cache_sac.pdf>.
> 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
Main Index |
Thread Index |