Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

In the past 5 years I've seen maybe a dozen "how elliptic curves work", but this is the first to actually illustrate how they work on a small field. I think that's key to understanding, seeing it in a small enough field that you can literally see all of the points. Nicely done.

If you want to keep going, as an advanced beginner I'd like to see:

Arbitrary bigint math - how do you do Exp/Sqrt with arbitrary sized ints? (I'm familiar with two crypto libs that do this, and MPIs & branches confuse me).

Second: why is C25519 faster than SecP256R1 or BrainPool? maybe some insight there? (Isn't Ed25519 the signature name? and X25519 the ECDH name?)

Greedy of me, but thanks!



> this is the first to actually illustrate how they work on a small field

That means a lot, thanks! That was my design goal with the page: figuring out the best way to get the idea across _without_ the user having to read a lot of text and stare at the wall until they got it.

I've been casting around for the next idea to do a visualization of, adding yours to the list.

(as for a partial answer your second question: the answer is going to be that Montgomery curves like Curve25519 have a method [Montgomery ladder] to quickly and timing-safely calculate only the x values of point multiplication. Faster _and_ more likely to be implemented securely than NIST curves, by design. Unfortunately I don't know the details of BrainPool, yet?)

Yes, Curve25519 is the curve itself (and associate params), Ed25519 is the signature system implemented on top of C25519, and X25519 is the ECDHE mechanism implemented on top of C25519. This page talks mostly about the C and a little of the X, and doesn't go into Ed.


I'll agree with GP - this is the best I've seen, too.

If I may offer a critique: the final example with Alice and Bob went too fast. I watched it 5 times and I'm a bit lost. I'll rewatch it again later


That’s good feedback. There’s a lot of steps, where should I slow it down? (“All” is an acceptable answer):

- Alice computes A

- Bob computes B

- there’s a 3? second delay

- Alice and Bob simultaneously compute the shared secret by multiplying their private key by the others’ public key


I noticed this problem with other images too. Sometimes animations change too fast, you see points moving, you look at them, but at the same time the formula changes, and you miss it. Especially bad when the formula is written under the image, far away from moving points.

Basically, you should not have several things changing in different places at the same time because human can only focus at one point. Maybe it would be better to add pauses in the sequence, animate one thing, wait a little, then animate other thing. Let the user stop and think a bit about what he/she have seen.

For example, in the image "Repeated addition of a point P" the points and lines are constantly moving, and I don't have time to look at the formula. I see that it is changing, but I cannot read it while looking at the animation. Maybe it would be better if the points stopped moving for a while, then the formula would change, then you give some time to read and comprehend it and then points continue moving.

Or maybe you could write all the formulas on the side, and have a box or selection moving over them. This way the viewer can see how the formulas are related to each other and doesn't have to remember previous ones.

Also, in the image "Point addition is associative and commutative" formulas seem to be random and do not illustrate anything. For example, I see 5P + P = 6P, then 2P + P = 3P, then 6P + P = 7P. So what it should mean?

Maybe a better way to illustrate these laws would be to have two images that produce the same result, for example P + 6P = 7P and 3P + 4P = 7P. It is easier to compare images side-by-side.

Instead of percent sign it might be better to use "mod" as percent sign is understood only by programmers but not by people familiar with mathematical notation.

To illustrate addition you might use a circle (or an ellipse, or even a square, why not) instead of a straight line. This way the wrapping behaviour would be more obvious. To illustrate multiplication, you could draw several sequential arcs (so that the multiplication is represented as several additions). And for negation, two arcs extending in the opposite direction from zero.

I don't understand how to illustrate inverse numbers though. Maybe several arcs that start at zero, end at 1 and number of them is the inverse value?

For the last illustration it definitely would help if it had some key points on the side, showing what we have done and what we are doing now.


Amazing work.

For me, I think breaking it up after the Public Keys are generated would have helped.

I lost track the first time after the public keys are computed and exchanged. The exchange is what I think I missed.


I can imagine that play/pause/step buttons could help a lot (for all of the animations), so each reader could "slow it down" manually and take all the time they need.

PS: Great work, thank you! :)


Ah, hmm. Every animation on the page does have a play/pause _except_ the exchange demo (laugh). I’ll play around with having it pause itself at key points and/or giving it a step button.


> Arbitrary bigint math - how do you do Exp/Sqrt with arbitrary sized ints? (I'm familiar with two crypto libs that do this, and MPIs & branches confuse me).

I solve that problem by using Common Lisp. Because arbitrary bigints are built-in, that's a big chunk of the problem you don't need to worry about. You still need to write a Montgomery multiplier (because otherwise you'd fill available RAM or the divisions would slow everything to a crawl) but that's straightforward. Common Lisp makes exploring crypto algorithms easy.


Note that it's not usually safe to use a language's built-in bigint for crypto like this because it's not time constant - for performance reasons smaller numbers will compute more quickly than larger numbers.

Instead you'll need a fixed-size bigint lib with constant time guarantees.


Completely agree. For deployment I'd strongly prefer a well-tested library with good side-channel protection rather than rolling my own. I use Common Lisp for researching and understanding algorithms.

Very nice page BTW. I've written C25519 code and I now understand my own code better because of your logical, step-by-step presentation.


^^^ This person cryptos. ;-)


Great, but that's not an explanation that adds knowledge to the discussion. I mean, Python and JavaScript both have BigInt libraries and are trivial to use.

I want to know HOW they work, especially in C, since that's what the majority of popular crypto libraries are written in.


I've cobbled together a few. It's half interesting, and half boring.

The boring half is all carry-the-one manual operations that are very much like the addition, multi-digit multiplication, and long division that you learned at a classroom chalkboard.

The more interesting is things like modular exponentiation: there's a trick to computing n^e%p for large values, https://en.wikipedia.org/wiki/Modular_exponentiation goes into some detail. It's an operation used in both RSA and public curve cryptography.


> It's half interesting, and half boring.

I once emailed Grant from 3b1b and asked if he could explain convolution. Not neural-net convolution, but transfer convolution you learn in linear systems: e.g. f * g where you flip and slide g over f.

His short response: "That's too boring." I was a little miffed. Well, yeah, ECC is boring too, until someone like you makes cool graphics.

Anyway, thanks again!


Exponentiation is done through repeated squaring, e.g.

    x^21 = x^16 * x^4 * x
    ...   = (((x^2)^2)^2)^2 * (x^2)^2 * x
Integer square roots can be done using binary search, which is O(n) for an n-bit number, but Newton's method can be used and it's usually much faster.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: