Okay, I didn't express myself very well the first time I tried to say this. But as I see it, we're still basing the design of crypto algorithms on considerations that had the importance we're treating them as having about twelve years ago.
To make an analogy, it's like making tires when you need to have a ten thousand mile warranty. When rubber is terribly expensive and the cars are fairly slow, you make a tire that probably won't be good for twelve thousand miles. But it's now years later. Rubber has gotten cheap and the cars are moving a lot faster and the cost of repairing or replacing crashed vehicles is now dominating the cost of rubber. Even if tire failure accounts for only a small fraction of that cost, why shouldn't we be a lot more conservative in the design of our tires? A little more rubber is cheap and it would be nice to know that the tires will be okay even if the road turns out to be gravel. This is where I see crypto designers. Compute power is cheaper than it's ever been but we're still treating it as though its importance hasn't changed. More is riding on the cost of failures and we've seen how failures tend to happen. Most of the attacks we've seen wouldn't have worked on the same ciphers if the ciphers had been implemented in a more conservative way. A few more rounds of a block cipher or a wider hidden state for a PRNG, or longer RSA keys, even though we didn't know at the time what we were protecting from, would have kept most of these things safe for years after the attacks or improved factoring methods were discovered. Engineering is about achieving the desired results using a minimal amount of resources. When compute power was precious that meant minimizing compute power. But the cost now is mostly in redeploying and upgrading extant infrastructure. And in a lot of cases we're having to do that because the crypto is now seen to be too weak. When we try to minimize our use of resources, we need to value them accurately. To me that means making systems that won't need to be replaced as often. And just committing more of the increasingly cheap resource of compute power would have achieved that given most of the breaks we've seen in the past few years. To return to our road safety metaphor, we're now asking ourselves if we're still confident in that ten thousand mile warranty now that we've discovered that the company that puts up road signs has also been contaminating our rubber formula, sneakily cutting brake lines, and scattering nails on the road. Damn, it's enough to make you wish you'd overdesigned, isn't it? -------- Original message -------- From: John Kelsey <crypto....@gmail.com> Date: 09/30/2013 17:24 (GMT-08:00) To: "cryptography@metzdowd.com List" <cryptography@metzdowd.com> Subject: [Cryptography] Sha3 If you want to understand what's going on wrt SHA3, you might want to look at the nist website, where we have all the slide presentations we have been giving over the last six months detailing our plans. There is a lively discussion going on at the hash forum on the topic. This doesn't make as good a story as the new sha3 being some hell spawn cooked up in a basement at Fort Meade, but it does have the advantage that it has some connection to reality. You might also want to look at what the Keccak designers said about what the capacities should be, to us (they put their slides up) and later to various crypto conferences. Or not. --John _______________________________________________ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
_______________________________________________ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
