[Never been 100% sure about the etiquette of sending my own blog posts
to this list, but in this case I am doing so at Perry's request. For
future reference if anyone else ever feels it's appropriate, do feel free]

>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[1]. 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.

Now 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?



"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to

Reply via email to