[Cryptography] Why don't we protect passwords properly?

Jerry Leichter leichter at lrw.com
Wed Dec 25 10:05:01 EST 2013


On Dec 24, 2013, at 11:25 PM, Bill Frantz wrote:
> In general, protecting one VM from another VM running on the same hardware is a hard problem. As with many things in life, if it hurts, don't do it.
> 
> Probably the best approach is to provide virtual clocks to prevent timing attacks. Tough luck for timestamping and random number generation though. Probably you can allow timestamping accurate to the second if you don't use the secret too frequently. Random numbers can be provided through virtual hardware random number generators, but addressing all the justified paranoia in this area will require examining the whole system from hardware to final use.
> 
> EM attacks can be interesting practical attacks, but Tempest packaging prevents them. While we are worrying about this style of attack, lets consider the nanotech quadcopter the size of a dust mote which can look over our shoulders and monitor our key strokes. That device is probably not too many years in the future....
This discussion is wandering, and it's wandering for fundamental reason.

Back when RSA was first developed, and then differential cryptanalysis finally showed us an objective, mathematical approach to determining the strength of combinatorial ciphers ... *we knew what the problem was*.  Everything was about mathematics and reductions and building out of simple primitives.

Over the decades since, all the certainty has gone away.  The math is fine, but it doesn't describe the real world.  Mathematically strong primitives fail when used in inappropriate protocols.  Appropriate protocols are subject to side-channel attacks.  Even the underlying hardware is your enemy.

We're now into an even deeper quagmire.  Increasingly, our defenses have really significant tradeoffs.  Just in the last few weeks, we learned that some techniques adopted in one major implementation of RSA to block high-frequency side channels actually made the implementation more vulnerable to low-frequence acoustic analysis.  Passwords are increasingly vulnerable, but none of the proposed solutions has a good story for the "shopping on-line in my PJ's at 3:00 AM because I can't sleep" problem.  As just recently described here, scrypt may make off-line attacks slow at the expense of making side-channel attacks against on-line use easier.

Meanwhile, even the math we thought we had down pat has proved to be elusive. MD5, SHA-1, RC4 - failing primitives.  BEAST and related attacks - failing protocols.  We can no longer assume we can "get it right" forever - we have to design on the assumption that anything we build today will, within the fielded lifetimes of our systems, fail and need to be replaced.  Somehow.

It's now (and has, really, been for a while) a big-ass engineering problem.  And as I used to tell my OS classes, engineering is all about tradeoffs.  And tradeoffs are always made by someone, with a particular stake in one or another of the things being traded off.

So I expect to see many more discussions about security wandering, as we're no longer certain about what security means.  Yes, worthwhile security debates start with a definition of the attacks to be defended against; or, even better, of the risks and costs associated with different attacks and defenses.  But given the huge spectrum of entirely different classes of risks, and the very different likelihoods and costs different people will assign to them ... to accept agreement on what are, at base, the *goals* is increasingly folly.

                                                        -- Jerry



More information about the cryptography mailing list