Cryptographer Tanja Lange shares papers, slides, and tools on elliptic curve cryptography, with work by Daniel Bernstein.
HN links it in arguments over whether the NIST curves can be trusted and on RSA security, citing talks like Facthacks.
Sage is wonderful. It has a huge number of uses but I mostly use it for cryptography. Sage has the best (certainly open source) support I know of for a myriad of things like group theory and elliptic curves. Here's a short example for how easy it is to play around with a tiny elliptic curve:
sage: p = 19; p.is_prime()
True
sage: K = GF(p); K
Finite Field of size 19
sage: E = EllipticCurve(K, [5, 9]); E
Elliptic Curve defined by y^2 = x^3 + 5*x + 9 over Finite Field of size 19
sage: E.count_points(), E.order(), E.gens()
(19, 19, [(4 : 6 : 1)])
There are far too many things to name that sage can do, but the CLI has a great autocomplete. Here's an example: let's say you have ECDH with point compression, and you specify only an x coordinate. Point compression limits the effectiveness of invalid curve attacks, where an attacker gives you a maliciously picked Diffie-Hellman value that isn't actually on the curve you're supposed to be on. However, if the x coordinate doesn't map to a point on the curve, it's necessarily on its "nontrivial quadratic twist". Sage makes this easy to play with because sage makes pretty much everything easy to play with:
sage: E.lift_x(6, all=True)
[]
sage: E.quadratic_twist()
Elliptic Curve defined by y^2 = x^3 + 6*x + 13 over Finite Field of size 19
sage: E.quadratic_twist().lift_x(6, all=True)
[(6 : 6 : 1), (6 : 13 : 1)]
If you want to do a full-on invalid curve attack, the easiest way to do that…
It seems they are now bringing additional allegations[1] to other Wikileaks Associates _and_ people who gave talks at CCC between 2013-2015. Namely Jake Appelabaum who is currently (doing a PhD[1] with T. Lange & DJB).
The US seems to have a hard-on also for members of the "Rosa-Luxembourg Stiftung" who insulted the empire by giving talks about their illegal drone wars[2][3] and shed light on how German engineers were working as sub-contractors for US airbases in Germany (as data scientist and software engineers).
EU countries, especially Germany, France (I have less hope for Eastern-EU or Sweden) need to stop extraditions to US of A stat. Also these US terrorists dressed up as politicians need to be sanctioned (I understand this is a pipe dream) and prosecuted at the ICC (another pipe dream).
---
[0] (in German) https://www.heise.de/tp/features/USA-spaehten-fuer-Assange-Anklage-Veranstaltungen-in-Deutschland-aus-4909851.html
[1] https://hyperelliptic.org/tanja/students.html
[2] https://media.ccc.de/v/32c3-7259-graphs_drones_phones
[3] https://www.rosalux.de/dokumentation/id/14090/drone-warfare-origins-consequences-and-the-worldwide-resistance-to-it
'tptacek commented 17 days ago about EC crypto (https://news.ycombinator.com/item?id=6608163):
You should never, ever, never, nevern, nervenvarn build your own production ECC code. ECC is particularly tricky to get right. But if you want to play with the concepts, a great place to start is the Explicit Formulas Database at http://www.hyperelliptic.org/EFD/ ; the fast routines for point multiplication are mercifully complicated, so copying them from the EFD is a fine way to start, instead of working them out from first principles.
He went on to say that only Adam Langley or Daniel Bernstein should be implementing ECC. Probably because there are so many ways to slip up; few others would have the experience necessary to avoid all the pitfalls.
'theboss agreed:
I've implemented ECC and you are 100% correct. Nobody should implement ECC unless you really really know what you're doing.
Mapping points to the curve, multiplying points, point addition, there is too much math stuff to mess up on.
Just don't do it. If you read one thing tptacek says, read the last paragraph.
> "However, they gave no evidence of a back door, and in the two decades since that time no one has found a way that a back door could be inserted in DSA (or ECDSA)."
ElGamal/DSA is fragile and difficult to implement securely in a way that doesn't reveal secret k. ECC (and somewhat particularly NIST curves[1]) is also very difficult to implement securely from side channel attacks[2].
Consideration of "backdoors" should be broader than just mathematical equations on paper. "backdoors" could also include deliberate choice of algorithm or parameters that are fragile and difficult to implement in a secure way to minimise risk of side channel leakage of secrets. This is especially important in a whole variety of applications such as passports, payment cards and TPMs.
[1] https://www.hyperelliptic.org/tanja/vortraege/20130531.pdf#page=23
[2] Specifically, implementation of: https://en.wikipedia.org/wiki/Elliptic_curve_point_multiplication
> No cryptographers believe the NIST curves are backdoored.
That's not true. For an example, see Schneier's comment here:
https://www.schneier.com/blog/archives/2013/09/the_nsa_is_brea.html#c1675929
Or Bernstein and Lange's comments here:
https://www.hyperelliptic.org/tanja/vortraege/20130531.pdf
(specifically the: Jerry Solinas at NSA used this to generate the NIST curves (or so he says))
I believe Matthew Green may have also made a similar statement, though I can't find it, so perhaps I'm not recalling correctly. In any case, I don't think you can outright say "No cryptographers believe the NIST curves are backdoored". You can at best say "No cryptographers have proven the NIST curves are backdoored", which is true.
However, those cryptographers have also raised concerns (including concerns about backdoors) and I just hope we move to safer alternatives quicker.
If you want a good (IMHO) example of how Lisp can be made to "meet the problem" so to speak, take a look at this:
http://www.flownet.com/ron/lisp/djbec.lisp
and take a look at the functions xpt-add and xpt-double. The details don't really matter. What matters is that what is going on here is a whole bunch of modular arithmetic. The details are described here:
http://www.hyperelliptic.org/EFD/g1p/auto-twisted-extended-1.html
Notice how the Lisp code is virtually cut-and-pasted from that page, despite the fact that it's not Lispy syntax, and the mathematical operators are NOT traditional addition, multiplication, etc. These are operations on modular integers and elliptic curve points. And yet the code looks just like the source material from which it was derived.
To make all this magic happen required less than 500 LOC.