Hacker News new | past | comments | ask | show | jobs | submit login
The Animated Elliptic Curve (xargs.org)
230 points by syncsynchalt on July 3, 2023 | hide | past | favorite | 19 comments



Elliptic curves over finite fields have immediate applications to cryptography, but elliptic curves over the complex numbers are cool too. Just like the sine and cosine parametrize the circle, elliptic functions parametrize elliptic curves.

Whereas trig functions are singly periodic with period 2pi, elliptic functions are doubly periodic functions, meaning that there are fixed complex numbers z and w such that f(x+z) = f(x+w) = f(x). You can prove that for a given period lattice, the field of such functions is generated by two such fundamental functions—-the Weierstrass elliptic function and its derivative. The addition law for elliptic curves over C can be derived from something like the equivalent of the addition law for sine and cosine.

Elliptic functions have applications to physics and are also interesting in their own right. This all leads to the study of fractional linear transformations, modular forms and even Fermat’s Last Theorem. It’s all quite lovely.


This is wonderful. As part of a cryptography course in undergrad, I spent a fair number of hours adding/multiplying points on small curves by hand and eventually computationally, and seeing these animations represents the "feel" of that process better than any resource I have seen.

It seems that elliptic curves are used quite shrewdly in public key exchanges, used as a sort of off-the-shelf arithmetic system that renders some benefits (harder to solve the elliptic curve discrete log problem) and drawbacks (more expensive to compute, because of these point ops) compared to key exchanges relying on the integer discrete log problem. There is generally much energy spent on explaining the point operations but not much on explaining this context: this is an alternate arithmetic inserted into the Diffie Helman scheme that is secure and not so hard to work with.

The finite fields in application (e.g. in X25519) are so large compared to the toy examples that the technical details matter more for understanding the performance of the algorithms than the actual cryptographic method. Understanding (and convincing yourself of) the core behavior of the key exchange itself is perhaps best done with the number theory and group theory lens. There was a discussion here on HN a couple days ago which largely bashed the theoretical approach in favor of simply cargo culting the tools, which was appalling. I hope they all enjoy this link!

Anyhow, the application of elliptic curves to cryptography is clever and I would recommend everyone with an interest (and a little background in algebra) read Koblitz's paper[1] and Miller's earlier description [2] if they are looking for more context for OP's wonderful presentation.

1: Koblitz: Elliptic Curve Cryptosystems https://www.ams.org/journals/mcom/1987-48-177/S0025-5718-198...

2: Miller: Use of Elliptic Curves in Cryptography https://link.springer.com/chapter/10.1007/3-540-39799-X_31


What a super resource. I (a civilian with some maths skills - roughly undergrad) can actually start to appreciate how these things work.

I generally pick Group 31 when setting up IPSEC tunnels. I use that for Phase 1 DH group and Phase 2 PFS key group. My choice is somewhat biased by this bloke: https://cr.yp.to/ecdh.html I do not have the skills to decide what is actually secure, so I have to rely on reputation. Dan B (Ok DJB) has a very decent reputation in this field.

----------------------------------

I did have to hit Ctrl+ to get it to 200% for comfort - the kids will eventually discover the joys of what happens to your eyes aged around 40-50 or so. Hint: long sightedness. Combine that with a history of short sightedness and a dash of astigmatism, for extra fun. A screen is 100% wide, why use only 30% of it? OK I have a pretty instant fix with scaling and modern typefaces etc generally work OK but bitmaps generally don't. You do have to zoom quite a lot to get the graphs to start to pixelate.


Author here. I’m 46 and just staring to lose my close vision, so I understand.

I did my best to collapse margins on small screens, though there’s still a thin bit of margin around the animations. I think I constrained the max width to keep the text from being harder to read, that’s probably what you’re running into.

As for pixelation, I did all the animations in canvas with 2x subsampling (for retina support) so it should hold up well to zooming as you found.

Glad you found it helpful!


This page is a great piece of work overall. I want to nitpick on two things:

> I did all the animations in canvas with 2x subsampling (for retina support) so it should hold up well to zooming

I think a better fit is to do your animations in SVG. It is definitely possible, for example: https://www.nayuki.io/page/animated-floating-graph-nodes , https://www.nayuki.io/page/smallest-enclosing-circle .

> I did have to hit Ctrl+ to get it to 200% for comfort

I think the best thing to do is that the user configures the default font size in their browser, the author uses it as the body text size, and scales headings relative to it (e.g. 200% for <h1>). It looks like the author did well here, setting "--bs-body-font-size: 1rem;" instead of something like 16px or 12pt.


It's funny. A few years ago I gave a short talk/lesson at my workplace on the mathematics behind ECDSA and coded a visualization of the procedure very similar to this. An interesting fact about the finite field curve is that, because the plane loops around on both axes, given an addition A + B = C, there's many straight lines that pass through A, B, and -C. When animating the line to find the sum, I had to optimize the path taken to not fill the screen with lines, because the most straightforward line has a slope comparable to the height of the screen (i.e. it's nearly vertical), so rendering it is almost equivalent to a rectangle fill.


There’s an interesting (to me) implementation detail in the A+B=-C lines on this page.

It's possible to show the true lines with the toy curve, but the X25519 animation at the top of the page is a cheat: it uses the correct slope IIRC, draws the dot following that slope for five wraparounds, but then cheats and jumps to the needed height and does only the last line to its destination.

If I'd done the actual number of wraparounds used in a typical X25519 point addition it'd be like TV snow, or would take hours!


An important point to note, that is not very obvious from the text, is that it is (very, very) difficult to retrieve ka from A=ka.P and kb from B=kb.P. For an attacker who has A and B, it's close to impossible to recover P and ka.kb.P


Isn't P always the same? Or is it shared before the exchange?

Edit: just looked it up and the base point for curve25519 is x=9 so no point in recovering it.


In modern curves P is set in stone head of time.

In the early days of EC you were able to pick a custom base point, and then it was found that this could leak information in various ways. It’s not allowed in modern curves or implementations.


Sorry, I wrote that comment too quickly. It is close to impossible to recover ka, kb and ka.kb.P, even given A=ka.P, B=kb.P and P.


Previous discussion from last year: https://news.ycombinator.com/item?id=31769059


Nice!

One thing I think this doesn’t explain or mention is that, if you draw a line between two of those points derived from the finite field and find the curve intersection, then negate the point's y-value, the resulting point also is a point derived from the finite field. The computation of λ involves a division, so it isn’t obvious to me that x3 is an integer.


This was quite lovely. Cryptography was something I missed in my mathematics education (well, I did cover RSA) and this gave me the gist of what all these elliptic curves are about!


amazing work, so readble and fun to watch the animation woth clear text explanation.

even for a short attention person like me, thr author got me hooked


given a curve, how do you find the corresponding finite field? The article seems to pull it out of thin air (?)


The details of the curve, the finite field, and point P are chosen ahead of time (at least with modern curves… you used to be able to choose a custom P and it led to security flaws). When we refer to something like “X25519” or “NIST P256” it means the combined set of all three things.

In TLS terms the client connects and says “is X25519 good? I can also do these other curves” and the server either agrees or chooses another curve in its response.


I’ve just reread my reply and could have been clearer: the curve, finite field, and base point are chosen ahead of time _by the standards body_. When two endpoints agree to use e.g. the NIST P-256 curve, then they are agreeing on the curve equation, the finite field, and the base point, all together as a set of items.


No worries your initial response was clear to me. My question was under the assumption that you couldn’t mathematically pick an arbitrary pair of curve and finite field, but I guess any choice is fine as long as the parties agree ahead of time.




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

Search: