
A Las Vegas algorithm to solve the elliptic curve discrete logarithm problem [pdf] - aburan28
https://arxiv.org/abs/1703.07544
======
brohee
Interesting, but no more.

The commonly used curve P-256 has the prime order
115792089210356248762697446949407573529996955224135760342422259061068512044369.

From the paper "The largest group of elliptic group of prime order that we
tested is 129159847, in which a discrete logarithm problem was solved.".

~~~
dvdkhlng
The paper closes with

> However, we felt that computing the determinant for all possible sub
> matrices is a bottleneck for this algorithm and ways should be found to make
> this more efficient.

That last step is obviously of exponential complexity in the parameters r and
t. I wonder whether the algorithm's total run-time becomes more acceptable
when that last step is replaced by a polynomial-complexity computation.

To me it looks like an O(log(n)*n³) algorithm should be feasible, by replacing
the submatrix-determinants with operations on determinants on large matrices
that are generated in a way that ensures det=0 when any of the sub-matrices
has det=0.

Unfortunately I don't really understand enough about the remainder of the
paper to actually see how the useful the algorithm would be with that
"bottleneck" removed.

~~~
dvdkhlng
Too late to edit my comment, but for correctness' sake: the algorithm as
described is exponential in k (and thus n), not r and t.

------
hpsineqepsi
This algorithm is slower than existing approaches (Pollard's rho); the
ridiculously small "largest group" that the author considered can be easily
tackled in a split second with even inefficient general algorithms such as
Shank's. It's surprising that such a boring non-result made it to the front
page of HN.

~~~
brohee
As I understand it, their implementation is in Sage, which can't really be
considered optimized. Is their method inherently slower than Pollard's rho, or
is it an implementation issue?

------
19eightyfour
I think in general the technique of introducing some slack in the form of
partitions and then constraining those using some property of the specific
problem space, in this case linear relations of whether those points lie on
some curve, is very strong and has general applicability. Sort of like branch
and bound. It's nice to see that this author started with a general idea that
wasn't that fast, and then used a lot of clever details to improve the
implementation of that same idea over a number of years.

------
eximius
What is the estimated complexity of this attack? It is not clear to me how to
use the probability of success formula for an arbitrary keysize.

------
ecdh
Uh, wait a second. Is Elliptic Curve Diffie Hellman broken now? Does this work
on curves used in TLS?

~~~
brohee
Not remotely practical against curves in actual use...

------
sokoloff
We don't have to (and shouldn't, IMO) American-ize "Monte Carlo"

Edit: TIL that they are different. (Thanks for the explanations below! esp:
gmfawcett and 1001101)

~~~
1001101
Las Vegas = Always Correct, Probably Fast

Monte Carlo = Probably Correct, Always Fast

~~~
funkaster
Adding speed to the classification is misleading. It might be better to state:

    
    
      - Las Vegas: Correct, Time unbounded
      - Monte Carlo: Not always correct, Time bounded
    

edit: format

~~~
kccqzy
As pointed out already, a Las Vegas algorithm might have bounded but non-
deterministic time.

