I also wrote an introduction to ECC using Python. It's longer, less gentle, more mathematical, and doesn't cover Edwards curves. But it ends with a program allowing you to play EC's over any finite field, and implements and explains some of the major protocols.
No disrespect to the extensive work you did there-- and this is a general complaint about basically all the "ECC explained" I've seen on the web, but I think that jumping into the mechanics of explaining at the blades-of-grass level how to implement point arithmetic without ever giving an clear intuition as to how a cyclic group with intractable discrete log is cryptographically useful does the reader a disservice.
E.g. after reading one of these tutorials, they might be able to go and _implement_ the cryptosystem, but they won't actually understand it except at a "Chinese Room" level, and as a result it won't actually be safe for them to implement any of it, since they'll be unlikely to ask the right questions. E.g. they'd make the Sony mistake.
Yours goes a little further, and for that I must give it credit: Many just explain the addition law and russian peasants algorithm, throw out an equation for ECDSA and call it a day. But if you do a revision, I'd encourage you to rearrange and explain the cryptographic algorithms abstractly, and in depth, first... before jumping into the mechanics of the machine implementation of a particular group law.
In writing them my main goal was to explain elliptic curves to my own satisfaction (i.e. derive things and not shy away from projective space and finite fields). To me they are interesting in their own right, as is realizing them in code. I view the crypto as sort of a bonus. I do see your point that I could have done everything with, say, multiplicative integers modulo a prime and the core algorithms wouldn't change. I think I will redo that when I get around to writing articles on abstract crypto (one-way functions, pseudorandom generators, and the like).
Particularly noteworthy is the part near the end regarding the selection process for curves when standards are written, and the caginess of the presenters in answering the audience question on the topic.
This is a good argument for software authors to really understand for themselves at all levels what is going on with the cryptography/ packages they are using.
There's a backstory here; the TLS working group asked the IETF crypto review board to recommend a standard for DJB's Curve25519. The effort seems to be running aground on bikeshedding concerns.
The jab about NSA continuing to influence CFRG is weird, though. Bernstein doesn't really believe that NSA influences Kenny Paterson.
This has also bugged me in the case of other cryptographic algorithms, for example SHA-1 has several magic input constants, whose choice is not obvious. When casually reading through the original papers I could not find a clear explanation of how those values were chosen. Pretty much everything in the design seems fairly arbitrary and amendable to variation.
In physics there are multiple case where you can do seemingly very hard calculations, if you do it in the wrong coordinate system and neglect symmetries that are present, that collapse to almost nothing (In the case of elliptic curves that was the fact that the curve points chosen by NSA were related by Q = P + e, where e was some point on the curve only known to the NSA)
Based on her response (at 53:40), I feel like she misunderstood the question. The first response "The nice thing about standards is there's so many to choose from" is probably because even if she proposes a curve with a flaw, people could just choose to use Curve25519 or whatever.
The subtext of BADA55 is that even curves that are seeded from mathematical constants or from other first-principals rationales still provide a malicious curve generator with leeway to pick from many potential curves, and to steer victims to the weakest of them.
That's true, but if the curve uses a well-studied underlying field where the curves that are vulnerable to cryptanalytic attacks can be avoided (prime fields lead the way here, last time I worked on an ECC implementation ~ 5 years ago), the risk from this threat isn't so great -I'd worry about other aspects of the resulting system first.
Slides: https://events.ccc.de/congress/2014/Fahrplan/system/attachme...
Sample code: http://ecchacks.cr.yp.to/