Comment by tptacek | Hacker News Reader

Comment by tptacek | Hacker News Reader

So far, the best single-page elliptic curve primer for generalist programmers I know of is Adam Langley's:

https://www.imperialviolet.org/2010/12/04/ecc.html

I understand the urge to try to get a high-level grok of curves without much math, but I spent years bouncing off the outermost surface of curve understanding by trying to start with the curve picture and the intuitive geometry of curve shape, and what finally made curves click for me (and quickly) was to simply take the curve equation --- which is itself high school math! --- and play with it a bit.

So if you're a programmer and you want a baseline understanding how curves work, do what you'd do with any other subject you're trying to understand: pop open an editor, take the Weierstrass curve equation, pick a y, solve for x; then do it in a finite field (ie, mod a prime). Then write an "add", then a "scalar mult". It's a couple hours of noodling, tops.

As always, but particularly with curves, remember that the basic understanding of what's going on is nowhere nearly enough to ever use them safely!

The common advice of, "You'll never know enough to use them safely so don't bother trying, just trust us." that has been going around has been proven itself to weaken encryption.

Just recently, an amateur programmer with very little background in cryptography discovered a flaw in libsodium in the Argon2 implementation and also in the reference implementation that everyone in the world was trusting without question. My advice is if you're an engineer, don't be afraid to write your own implementation of tried and trusted ciphers. This is how we find bugs and improve. This isn't the only trusted library or algorithm that has been shown flawed in recent times.

The strength of your cipher implementation can be tested and proven. We need to stop telling everyone these algorithms are absolutely trustworthy so don't try understanding them or implementing them. Nothing ever advances or improves that way. Buck the trends, create competing libraries, try new things.

The ancient ones were not all knowing, they were doing everything wrong. Their designs are full of flaws. Deny them. We need to code ourselves out of the coming cryptographic apocalypse. Do not hide your heads in the sand and hope the world doesn't come crashing down around you.

Edit: I found the blog/website of the man I mentioned in this comment who discovered the Argon2 flaw.

http://loup-vaillant.fr/articles/implemented-my-own-crypto

In his own words, "There's something worrying about this bug: I was the first to discover it, in January 2017. According to Khovratovich himself, it was two years old. Now I understand why the authors themselves didn't find it: unlike me, they didn't have a reference implementation to compare to.

What I don't understand is, how come nobody else discovered this bug? If you implement Argon2 from spec, you cannot miss it. Test vectors won't match, and searching for the cause will naturally lead to this bug. I can draw only one conclusion from this:

I'm the first to independently re-implement Argon2. This 'never implement your own crypto' business went a little too far."

Honestly, I'm not sure you want to get me started here.

Believe it or not, libsodium's implementation of Argon2 is an example of libsodium going off the rails. Libsodium began as a cross-platform easy-to-build repackaging of Nacl, a crypto library designed and written by cryptographers with carefully chosen primitives. Libsodium has gradually expanded it into a kitchen sink of shiny cryptography, and as a result now libsodium users have to worry about the pitfalls of AES-GCM. Why does libsodium implement Argon2? Hell if I know. As an interface, it's actually worse than JCE, which at least had the self-respect to pretend it had a "password based encryption" abstraction.

It gets worse though, if you really want to climb down this rabbit hole with me, because I'm not totally sure why Argon2 exists either. The "bug" he found in Argon2 has actually no practical impact, so much so that the reference implementation decided not to bother fixing it. But that's because very little in password hashes actually matter. Scrypt was the last important thing to happen to password hashes, and bcrypt still works just fine.

If we want to keep touring all the weird shit that happens because people pointlessly reimplement things many of which don't need to exist in the first place, we can keep doing it all the way back to unpadded RSA-512 off a broken browser RNG, which (a) existed and (b) got me gameover on a pentest once. Maybe I should be happy about that, but I mostly find it frustrating.

My point here, though, is that you aren't going to learn nearly enough from a tutorial of any sort to safely implement curves.

> the pitfalls of AES-GCM

Can you elaborate a little on this? I ask because Noise protocol standardizes on AES-GCM or ChaChaPoly, will apps using Noise with AES-GCM face "pitfalls"?

I found this discussion which is perhaps germane, about sensitivity to nonce repetition: https://www.imperialviolet.org/2017/05/14/aesgcmsiv.html

Reply on news.ycombinator.com