Some of the really important ideas can be summarised in one sentence. I'll coin the name "Bernstein principle" for the following:
Do not blame the (crypto) implementor for a mistake that the designer could have avoided in the first place.
Dan Bernstein gave a talk on several crypto horror stories including DSA and HTTPS which are often given as examples of "bad implementations of otherwise good crypto". Instead, we should see designs that have a tendency to be hard to implement or use simply as bad crypto. Nowadays, constant-time and side channel-resistant ciphers are state of the art; Bernstein told us how some of the problems were identified much earlier but ignored, with the inevitable mistakes being blamed on the implementations.
Another important point: a primitive design tends to get a lot of review (think AES competition) but a primitive implementation less so, a protocol design usually even less (reviewing security "proofs" is quite officially out of scope for most conference program committees these days) and once we get to a protocol implementation, there's very little interest around. Put another way, to take Bernstein's example, which of these got the least review: (a) discrete logarithms (b) ECDSA using discrete logarithms (c) Sony's ECDSA implementation for play station code-signing? And which one was horribly broken?
I would personally take the Bernstein principle further and say we should never, ever blame a crypto user for anything - yes, someone who reuses passwords, and picks weak ones in the first place, isn't going to get much security but take a deep breath - do we really expect the average person to memorise two dozen distinct high-security passwords (and change them every six months)? I'd argue that if any security-related design is widely misused be users, even in "stupid" ways, then that is enough evidence to call it a bad design.
Post a Comment