[Cryptography] recommending ChaCha20 instead of RC4 (RC4 again)

Jerry Leichter leichter at lrw.com
Thu Mar 13 06:52:30 EDT 2014

On Mar 13, 2014, at 12:14 AM, Peter Gutmann <pgut001 at cs.auckland.ac.nz> wrote:
>> [M]any times I've had some prospective customer say something like "10% performance hit for security? That's a deal breaker!"
>> My answer: "Well, 10% is 2.5 months' worth of Moore's Law..."
> Unless it's the embedded world (which makes the PC and phone and whatnot
> market seem trivial by comparison), in which performance stays constant and cost goes down.  Ten years ago your code had to run on a Cortex-M.  Ten years from now your code will need to run on more or less the same Cortex-M, only it'll be cheaper and have more integrated peripherals.
As software developers, we've lived through a couple of decades of engineering heaven, during which we could always excuse our excesses by saying the hardware would catch up "soon" because of the magic of Moore.  No matter what resource we squandered.

Well, that game was, as you point out, never valid in the embedded world to begin with, and isn't one to rely on *anywhere* any more.  CPU speeds are still increasing, but that curve flattened considerably several years back when clock rates more or less stopped increasing because we could no longer cool the damned chips.  The easy single-threaded speedups vanished; now if you want greater speed, you either eke out a couple of percent by dint of hard work on architecture, go parallel, or make use of specialized hardware.  The big increases in speed for AES in the last couple of years are due to moving the implementations into hardware.  Great where you have that hardware; not so great if you don't.  And all that talk about crypto algorithm agility?  Forget it.  If switching algorithms makes all your hardware suddenly 10 times slower, no one will do it.

Meanwhile, in many domains the hardware replacement cycles have gotten much longer.  Desktops used to be replaced every couple of years, at least at the technologically hip places - the latest generation of software needed the new hardware.  But desktops long ago passed the "good enough for everything you want to do" point and get replaced if they break - which they basically don't any more.  Laptops are almost at the same point.  Data center machines?  When you're talking about replacement at the level of thousands of machines minimum, no one's in a rush to write off capital investment that fast unless the gains are really significant.  I doubt you could justify replacing a data center CPU for less than a factor of 3 performance gain.  (You might buy some newer machines to add to your fleet, but you're going to keep the older ones in production, too.)  Now tell me where I can buy a CPU that's 3 times "better" on useful measures than last year's.  Or even 2011's.

The only place you can rely on consistent year-over-year performance increases these days is in mobile, though there power constraints are probably going to dominate until mobile devices, too, pass the "good enough for everything I need" point.

That's not to say there won't be individual gains.  Maybe ARM in the data center will greatly improve the watts/cycle ratio - though that won't give you more single-stream cycles/second, just more total cycles (and we're already having trouble making good use of parallel cycles for crypto).  Same for general-purpose computing on GPU's.  Crypto in the hardware - yes, that gives you big gains, but at the loss of flexibility.

Yes, performance matters.  It always has:  A system that's secure only as long as it operates below the data rates necessary to get the job it's paid to do done isn't secure in any meaningful sense.  We've been lulled by years of being able to make raw single-stream performance (and ever-increasing memory usage, and ever-growing disk usage) Someone Else's Problem, which miraculously Someone Else has solved for us.  Those days are over.  It's *our* problem now.
                                                        -- Jerry

More information about the cryptography mailing list