[Cryptography] asymmetric attacks on crypto-protocols - the rough consensus attack

[John Kelsey]

Rule of thumb:  Suppose you have two systems.  One runs along perfectly nearly all the time.  The other just barely works in the best of times and often breaks down under its own weight.  It's pretty easy to tell when the first system has been sabotaged, but really hard to tell when the second one has been sabotaged.  

Most of our mechanisms for developing crypto standards are more like the second system than the first.

--John



> On Aug 1, 2015, at 11:27 PM, ianG <iang at iang.org> wrote:
> 
> There's a group working on a new crypto protocol.  I don't need to name them because it's a general issue, but we're talking about one of those "rough consensus and working code" rooms where dedicated engineers do what they most want to do - create new Internet systems.
> 
> This new crypto protocol will take a hitherto totally open treasure trove of data and hide it.  Not particularly well but well enough to make the attacker work at it.  The attacker will have to actually do something, instead of just hoovering.
> 
> Doing something will be dangerous - because those packets could be spotted - so it will be reserved for those moments and targets where it's worthwhile.  It's not as if the attacker cares that much about being spotted, but embarrassment is best avoided.
> 
> So this could be kind of a big deal - we go from 100% open on this huge data set, down to 99% closed, over some time and some deployment curve.
> 
> 
> 
> Now, let's assume the attacker is pissed at this.  And takes it's attitudinal inspiration from Hollywood, or other enlightened sources like NYT on how to retaliate in cyberwar (OPM, anyone?) [0].  Which is to say, it decides to fight back.  Game on.
> 
> How to fight back seems easy to say:  Stop the group from launching its protocol.  How?
> 
> It turns out that there is a really nice attack.  If the group has a protocol in mind, then all the attacker has to do is:
> 
>  a) suggest a new alternate protocol.
>  b) balance the group so that there is disagreement, roughly evenly balanced between the original and the challenger.
> 
> Suggesting an alternate is really easy - as we know there are dozens of prototypes out there, just gotta pick one that's sufficiently different.  In this case I can think of 3 others without trying, and 6 people on this group could design 1 in a month.
> 
> Balancing the group is just a matter of phone calls and resources.  Call in favours.  So many people out there who would love to pop in and utter an opinion.  So many friends of friends, willing to strut their stuff.
> 
> 
> 
> Because of the rules of rough consensus, if a rough balance is preserved, then it stops all forward movement.  This is a beautiful attack.  If the original side gets disgusted and walks, the attacker can simply come up with a new challenger.  If the original team quietens down, the challenger can quieten down too - it doesn't want to win, it wants to preserve the conflict.
> 
> The attack can't even be called, because all contributors are doing is uttering an opinion as they would if asked.  The attack simply uses the time-tested rules which the project is convinced are the only way to do these things.
> 
> 
> 
> The only defence I can see is to drop rough consensus.  By offering rough consensus, it's almost a gilt-edged invitation to the attacker. The attacker isn't so stupid as to not use it.
> 
> Can anyone suggest a way to get around this?  I think this really puts a marker on the map - you simply can't do a security/crypto protocol under rough consensus in open committee, when there is an attacker out there willing to put in the resources to stop it.
> 
> Thoughts?
> 
> 
> 
> iang
> 
> 
> 
> [0] you just can't make this stuff up...
> http://mobile.nytimes.com/2015/08/01/world/asia/us-decides-to-retaliate-against-chinas-hacking.html
> _______________________________________________
> The cryptography mailing list
> cryptography at metzdowd.com
> http://www.metzdowd.com/mailman/listinfo/cryptography