Re: [Cfrg] I-D Action: draft-irtf-cfrg-dragonfly-03.txt

[Mike Hamburg <[e-mail]>]

Hello CFRG,

Let's see if I can provide a less controversial, or at least less theoretical, defense of the notion of cryptographic proof.

If this protocol is widely deployed, and people actually use it, there will be an incentive for various organizations to break it.  For example, NSA might ask Don Coppersmith to lead a team of similarly-clever cryptographers to spend a month trying to break it.  They would have access to classified techniques and massive computing power.  I am almost certain that the NSA and their contractors would put in this kind of effort and more into a new widely-deployed symmetric or asymmetric cipher.  This is why they hire more mathematicians than anyone else.  I suspect that a new protocol would attract a similar effort unless they have a better reason than I do to believe it's secure.

Likewise, other nations would mount attacks.  Outside researchers would too, but at least in that case we'd know if they broke it and could switch to something else.

When deploying a new protocol, I want a good reason to believe that it's better than the other alternatives.  "Better" could mean that it takes less work to implement, or is faster, or has fewer IPR concerns, or is easier to use correctly, or that it takes less bandwidth, or has more features, or it enables new security systems (like a PAKE).  But "better" also means that there is less risk that the NSA or the Chinese or the French or Adi Shamir will break it a month or a year down the road.  Risk is all we can talk about here, because of course someone might build a quantum computer or solve the discrete log problem.

There are two ways to convince me that the risk is low.  One is to have teams of elite cryptographers work for months trying to attack the system.  This is what happened with AES and SHA-3, but it really isn't scalable to every new cipher and protocol.

The other way to convince me is a proof of security.  There are better and worse models for this (RO vs standard model, gap assumptions vs CDH, whatever), but in the end, a proof is much better than no proof.  It means that as long as you haven't messed up the proof and I haven't messed up checking it, the adversary will need to pass a certain very high bar of cleverness (breaking the model and/or assumptions) in order to attack the system.  The more conservative and standard and commonly-used the model and assumptions are, the higher the bar will be and the more convincing the proof will be.  This doesn't guarantee that the adversary will fail, but at least it gives good evidence in that direction.

The argument given for Dragonfly is that we've patched all the security problems which people have found already, and since then they haven't found more.  And also, it looks like it ought to be secure.  These arguments are not very convincing.  I don't know who's been looking for attacks and how long, but I suspect it hasn't been a monthlong effort with a team of elite cryptographers.

I don't have an attack against Dragonfly.  I worked on attacking it for maybe an hour, and I'm no Coppersmith.  It looks to me like it ought to be secure.  But there have historically been plenty of protocols which looked secure and turned out not to be.

What's more, there isn't a formal security definition of Dragonfly.  This increases the risk that it will be deployed incorrectly, because it makes it harder to analyze the security properties of such a deployment.

Despite these problems, Dragonfly would still be the "best" PAKE protocol out there, and even worth deploying, if there weren't other good options.  But in fact there are SPAKE2 and "SPAKE2 Elligator Edition", which are also IPR-clean, similarly fast and simple, take less bandwidth, and have formal security models and proofs.  Furthermore, they (optionally) support an augmented/asymmetric PAKE interaction, which Dragonfly does not.  This may not matter to Dan Harkins, but it will matter to some people.

The advantage that Dragonfly has over these protocols is momentum: it's written up in an RFC, and SPAKE2 EE isn't even written up in a white paper.  But I, and several other people on this list, don't find that to be enough to outweigh its disadvantages.

In sum, saying "if you don't think it's secure, where's your attack against it?" isn't productive.  I think that Dragonfly is probably secure.  But I want to be much more certain than I am now.  There's not even any point in me spending a month trying and failing to break it, since I could spend that month writing an RFC and an implementation and a paper for SPAKE2 EE instead.

Cheers,
-- Mike Hamburg