Re: [Cfrg] Status of DragonFly

["Dan Harkins" <[e-mail]>]

  Hi Kevin,

On Mon, December 17, 2012 1:10 pm, Igoe, Kevin M. wrote:
> OK folks, we are still on the hook to provide the TLS WG with our analysis
> of DragonFly as it currently exists.  Here's what I see:
>
> 1)      The confidentiality provided by DragonFly is at least as good as
> Diffie-Hallmann.
>
> 2)      Impersonation is a different matter. The nefarious Eve can run
> through a list
> of likely passwords, attempting to run the DragonFly protocol once for
> each
> guess until she hits one where the DragonFly protocol runs to completion,
> meaning Eve has almost certainly found the correct password.  Proper
> monitoring of the error logs should detect such an attack.
>
> In the EC case, the situation is a bit muddier.  The use of the nonces in
> the
> generation of PE leads to a timing attack.   Assuming the observer can
> determine
> precisely how many passes have been made through the  while-loop, each
> observed
> instance of the DragonFly protocol between Alice and Bob provides 2 bits
> of information
> about their common password.  If the adversary has a list of 2^M passwords
> which is
> likely to contain the password in use, passively observing about M+8 or so
> DragonFly
> exchanges betwixt Alice and Bob provides enough information to uniquely
> identify the
> password (if it is on the list) with high probability.  This is not
> without cost to the
> attacker, they need to test the putative passwords one at a time until
> they find one
> that generates the observed pattern of number of passes through the while
> loop. It
> all comes down to how well the passwords are chosen, and we all know how
> good users are at picking passwords.
>
> Scott Fluhrer proposed an elegant change to DragonFly that fixes this.  In
> the EC case, replace
>  the while-loop with a for-loop, say "for t = 1,,,,40".  On each pass
> through this for-loop generate
> a possible x- coorodinate as in DragonFly,  saving off the first x value
> which corresponds to a
> point on the curve.  The only thing that can go wrong here is doing all
> 40-iterations without
> finding a good x-coordinate.  This is quite unlikely to occur (~ 10^-12),
> but when it does occur
> it gives 40 bits of information about the password.  In some VERY high
> volume applications it
> might be prudent to choose a value larger than 40.

  This technique is already used in draft-harkins-tls-pwd-03. There is an
additional security parameter, k, that is used to ensure that k iterations
of the loop are performed. There are no interoperability issues with any
particular value of k and I do not recommend a value. But I do make
this statement in the Security Considerations:

      "The probability that a password will require more than k
       iterations is roughly (q/2p)^k so it is possible to mitigate a side
       channel attack at the expense of a constant cost per connection
       attempt."

where q is the order of the group formed by the generator and p is the
prime. Is that statement correct and is it adequate?

  regards,

  Dan.