Links

Ben Laurie blathering


Crypto Craft Knowledge

From time to time I bemoan the fact that much of good practice in cryptography is craft knowledge that is not written down anywhere, so it was with interest that I read a post by Michael Roe about hidden assumptions in crypto. Of particular interest is this

When we specify abstract protocols, it’s generally understood that the concrete encoding that gets signed or MAC’d contains enough information to unambigously identify the field boundaries: it contains length fields, a closing XML tag, or whatever. A signed message {Payee, Amount} K_A should not allow a payment of $3 to Bob12 to be mutated by the attacker into a payment of $23 to Bob1. But ISO 9798 (and a bunch of others) don’t say that. There’s nothing that says a conforming implementation can’t send the length field without authentication.

No of course, an implementor probably wouldn’t do that. But they might.

Actually, in my extensive experience of reviewing security-critical code, this particular error is extremely common. Why does Michael assume that they probably wouldn’t? Because he is steeped in the craft knowledge around crypto. But most developers aren’t. Most developers don’t even have the right mindset for secure coding, let alone correct cryptographic coding. So, why on Earth do we expect them to follow our unwritten rules, many of which are far from obvious even if you understand the crypto?

6 Comments

  1. “Clearly everybody knows… “

    Comment by Cat — 11 Feb 2009 @ 20:52

  2. Hi Ben,

    The obvious question here is, why don’t you start such an effort and/or encourage the appropriate colleagues to do so? These types of things are exactly the kinds of public resources we need.

    Comment by Dan Halperin — 12 Feb 2009 @ 3:46

  3. The age old problem of how you teach a skill mixed with experience and common sense.
    Bit like a book on combat training, very useful but not much good without actual experience. There are books on how to drive a car, but humans learn best by trial and error. Writing down the rules certainly helps, but I don’t think in practice it makes or breaks it.

    In the grand scheme of things most developers never understand the hardware they run on, the libraries they use or even how the software they write will actually be deployed and used, so I agree. So it’s not that they probably wouldn’t, it’s that they probably wouldn’t on purpose but they probably will 🙂

    I just don’t know how you beat that painful, hard won extensive experience.

    Comment by Robert Nice — 12 Feb 2009 @ 20:21

  4. And you can start with Facebook Connect (http://wiki.developers.facebook.com/index.php/How_Facebook_Authenticates_Your_Application), which has at least four flaws which would fall into the “don’t do this” category.

    1) No ability to quote or otherwise deal with strange data (binary) in the value
    2) No identification of field boundaries
    3) Simple concatenation of key, rather than HMAC structure
    4) Use of MD5

    Unfortunately, this seems to indicate that protocol designers don’t even make the first attempt to learn enough. I’m not sure a public would help very much if nobody bothers to look for it.

    Having said that, I would appreciate such a site, since I’m far from confident that I remember everthing about secure protocol design that I should.

    Comment by Terry Hayes — 13 Feb 2009 @ 20:58

  5. Ferguson and Schneier wrote about this issue in “Practical Cryptography” (2003). They declare the Horton principle: “Authenticate what is being meant, not what is being said”, and then go on to explain it with an example of variable length fields in an authenticated message.

    So this particular rule is written somewhere. Sadly, only the developers who already care about security are going to read a book like that.

    Comment by Alexander Konovalenko — 14 Feb 2009 @ 20:05

  6. Ferguson and Schneier wrote about this issue in “Practical Cryptography” (2003). They declare the Horton principle: “Authenticate what is being meant, not what is being said”, and then go on to explain it with an example of an authenticated message with variable length fields.

    So this particular rule is written somewhere. Sadly, only the developers who already care about security are going to read a book like that.

    Comment by Alexander Konovalenko — 15 Feb 2009 @ 20:52

RSS feed for comments on this post.

Sorry, the comment form is closed at this time.

Powered by WordPress