[cryptography] preventing protocol failings

Hill, Brad bhill at paypal-inc.com
Tue Jul 12 13:10:01 EDT 2011

Re: H3, "There is one mode and it is secure"

I have found that when H3 meets deployment and use, the reality too often becomes: "Something's gotta give."  We haven't yet found a way to hide enough of the complexity of security to make it free, and this inevitably causes conflicts with goals like adoption.

An alternate or possibly just auxiliary hypothesis I've been promoting on how to respond to these pressures is: 

"Build two protocols and incentivize."

That is:

   Recognize in advance that users will demand an insecure mode and give it to them.
   Make it a totally different protocol, not an option, mode or negotiation of the secure protocol.
   Encourage appropriate self-sorting between the secure and insecure protocols.

Making two completely different protocols means that neither has to pay the complexity cost of the other mode, (avoiding e.g. the state explosion Zooko described with ZRTP) eliminates or greatly reduces introduced attack classes around negotiation and downgrade, and makes the story around managing and eventually deprecating legacy clients simpler.  

The self-sorting is the tricky bit.  Google Checkout and SXIP are good examples of this.   Google Checkout allowed both signed and unsigned shopping carts.  Unsigned shopping carts were dead-easy to implement, but had a higher fee structure than the signed carts.  This meant that it was easy to join the ecosystem as a prototyper, hobbyist or small and unsophisticated business.  But it also meant that as soon as your transaction volume got large enough, it was worthwhile to move to the secure version.   SXIP built the incentive between protocols by having additional features / attributes that were only available to users of the secure protocol.

The other advantage of building two protocols is that if/when the insecure protocol actually becomes a target of attack, the secure version is ready to go, deployed, proven, ready for load, with libraries, sample code, the works needed for a smooth transition.

This is a bit like Ian's "Build one to throw away," except that I'd say, build them both at the same time, and maybe you won't need to throw away the insecure one.

Brad Hill

More information about the cryptography mailing list