[2013-07-18, William Allen Simpson] >On 7/17/13 4:29 AM, Tor Erling Bjørstad wrote: >>Regarding ESTREAM, disregard the hardware ciphers in the final >> portfolio. That limits the number of algorithms to four. Of these, >> I think Salsa20 is the only one that has obtained significant >> adoption. However, if I were to pick another, I'd be partial >> to HC-128 due to its simple (somewhat RC4-like) design and very >> impressive software performance. >> >> [1] http://nacl.cr.yp.to/stream.html >> >And there's HC-256, according to wikipedia. But what about >independent analysis? And is it really faster? > >Salsa20: 414 cycles per byte > >HC-256: 4 cycles per byte. >HC-128: 3 cycles per byte. > >But HC-* has a huge per packet setup penalty!?!?
There was a fair amount of attention on HC from the international research community during the ESTREAM competition (2005-2008). Most of it didn't lead very far, and probably remains unpublished or lost [1]. The findings that have been made public are all pretty minor. Certainly the two HC variants haven't received the kind of attention that the SHA-3 finalists (or Salsa20, for that matter) has, but it is also clear that researchers have been spending a not insignificant amount of brainpower trying to break it. Whether that's "sufficient" analysis for some particular use-case is hard to quantify. What makes HC-* interesting to me is that it's pretty much as fast as one gets it, for a strong pure software cipher encrypting long streams of data. If one has a limited number of data streams that are pushing a huge number of bits over the wire, HC-* seems pretty appealing. If the use-case instead involves a zillion independent short packets that all need to be encrypted with a unique key/IV combo, then HC's performance will indeed suck. Cheers, Tor [1] I spent some time on cryptanalysis of HC at one point, and I also remember working on it in a larger group at some of the meetings in Leuven. The only notable result coming our of those efforts, was that all our ideas were totally busted [2]. [2] This is, of course, the default outcome from cryptanalysis. _______________________________________________ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
