A gentle introduction to elliptic-curve cryptography [video] | Hacker News Reader

A gentle introduction to elliptic-curve cryptography [video]

media.ccc.de

102 points0x006A24 comments

Open articleView on HN

This video is excellent.

Slides: https://events.ccc.de/congress/2014/Fahrplan/system/attachme...

Sample code: http://ecchacks.cr.yp.to/

The first https uses CAcert. I'd suggest using http instead.

Thanks for pointing that out. TIL that my browser trusts the CAcert root, which is not something I remember doing.

Too late to edit my comment. Here is a non-HTTPS link: http://events.ccc.de/congress/2014/Fahrplan/system/attachmen...

You may not be trusting the CAcert root, but just the ccc.de cert. I know I added an exception for it, but not CAcert generally.

what is the issue with CAcert?

Approximately 0% of the installed browser base trusts them.

So, what's the deal with just clicking away the warning, then? Still provides secrecy against a passive listener, better than plain http...

Clicking away the warning is a bad reflex, you're human too. It's not a reflex you want.

How are the slides created?

Looks like they used LaTeX/Beamer http://en.wikibooks.org/wiki/LaTeX/Presentations

Ah, it's quite simple using pdfpages.

I have no idea, but considering they are from DJB, they were probably created in a very unusual way ;-)

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.

http://jeremykun.com/2014/02/08/introducing-elliptic-curves/

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)

Regarding the SHA-1 constants:

http://crypto.stackexchange.com/questions/10829/why-initiali...

Your latter example seems to be about the Dual-EC RNG, which is not an ECC encryption algorithm.

Ah that is good to know. Yes the latter example was not exactly on point, just meant as a general illustration of possible vulnerabilties.

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.

I feel like they've already addressed the question with their "bada55 curves" page: http://safecurves.cr.yp.to/bada55.html

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.

A quick google search shows DJB and Tanja Lange have some nice analysis of existing curves here: http://safecurves.cr.yp.to/index.html

Of course, if the cryptographers generating the curve aren't sharing their knowledge of some new class of weak curves, all bets are off.

I found this introductory explanation worth reading. http://crypto.stackexchange.com/questions/653/basic-explanat...

Reply on news.ycombinator.com