HN Theater @HNTheaterMonth

Also check out https://events.ccc.de/congress/2014/Fahrplan/events/6369.htm...

Video of the talk: http://media.ccc.de/browse/congress/2014/31c3_-_6369_-_en_-_...

⬐ ufo

Really liked this version. All the time I was wondering when they would transition from the "toy" clock curve that is easy to understand to the complicated y^3 curves that are mentioned in the OP but it turns out that the easy to understand curve was just as good all along and much easier to implement correctly.

djb gave a good overview of general ECC curves as part of his and Tanja's talk at 31C3: http://media.ccc.de/browse/congress/2014/31c3_-_6369_-_en_-_... I'd highly recommend watching it, it was very educational.

⬐ j2kun

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/

⬐ None

None

⬐ nullc

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.

⬐ j2kun

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).

⬐ pervycreeper

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.

⬐ orbifold

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)

⬐ tptacek

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.

⬐ orbifold

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

⬐ fryguy

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

⬐ tptacek

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.

⬐ None

None

⬐ nullc

BADA55 curves are not "from mathematical constants or from other first-principals rationales", they're a demonstration that the spec "provably random" construction used for some other curves can be ground to produce very rare characteristics. They all have unjustified high entropy random "seeds", like P-256, which were the product of a computationally expensive search to find curves meeting the BADA55 characteristic.

An example of a curve "from mathematical constants or from other first-principals rationales" would be to set parameters to 'trivial values' like 0 or 2^255 and increment until you get the first curve that matches a security test. Some curves, like the curve25519 curve or secp256k1 were constructed this way and this method could not be "BADA55" in the way that P-256 could be.

⬐ jeff_marshall

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.

⬐ tptacek

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.

⬐ jestinjoy1

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

⬐ agwa

This video is excellent.

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

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

⬐ idfivud

How are the slides created?

⬐ agwa

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

⬐ hartem_

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

⬐ askldjkladj

Ah, it's quite simple using pdfpages.

⬐ yuhong

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

⬐ officialjunk

what is the issue with CAcert?

⬐ tedunangst

Approximately 0% of the installed browser base trusts them.

⬐ cnvogel

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

⬐ nullc

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

⬐ agwa

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...

⬐ tedunangst

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.