The Animated Elliptic Curve
curves.xargs.org
curves.xargs.org
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.
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
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.
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!
> 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 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!
Edit: just looked it up and the base point for curve25519 is x=9 so no point in recovering it.
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.
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.
even for a short attention person like me, thr author got me hooked
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.