Hi, 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. Cheers, - markku Dr. Markku-Juhani O. Saarinen <m...@iki.fi> US +1 (424) 666 2713 On Fri, Apr 18, 2014 at 7:47 PM, Taylor R Campbell <campbell+netbsd-tech-k...@mumble.net> wrote: > Date: Fri, 18 Apr 2014 12:38:38 -0400 > From: Thor Lancelot Simon <t...@panix.com> > > 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 > worthwhile.
