[stouset]

> anecdotally, generating 2048-bit or larger RSA keys for me tends to be a lot slower than ed25519

That’s not really anecdotal. Generating an ed25519 key is barely more than generating a random 256-bit value. Generating an RSA key is significantly more work.

[saghm]

I did say my understanding was probably naive; I didn't know the details to be able to assert anything beyond my own observation!

[stouset]

Yep, not faulting you at all! I too was surprised when I found out that it’s a straight 256-bit random value with a few bits masked.

[saghm]

I pretty quickly realized in college when learning about this stuff that the math was well over my head, and I shifted my focus more to understanding how to properly use cryptography rather than implement it (which turned out to be more important as a software engineer anyhow). In retrospect, I really appreciate how the professor I had in a security-focused course explicitly told us it was okay if we didn't understand the math and wouldn't be tested on it when going over how it worked.

[tptacek]

Counterpoint: it's not OK to skip the math with cryptography. You may not need to power through all of Silverman's curve book (though: I don't know for sure that's true, which is why I don't call myself a cryptography engineer), but you have to get as deep into the math as you can in order to safely use cryptographic algorithms.

If you're math-avoidant, stick with high-level abstractions like NaCL and TLS. There's nothing wrong with that!

A professor talking about and demonstrating cryptography at the level of individual algorithms is doing their class a disservice if they say "none of the math will be on the test". The algorithms are enough to put something together that seems like it works; the math is what you need to find out if your resulting system actually does work. It's where many of the fun bug classes live.

[saghm]

I'm not sure if you're reading more into what I said than I intended, but I'm not convinced by this argument. You might have missed that this course was on security in general, not cryptography; not everything in the course was cryptographic related.

That said, I'd argue that for the vast majority of software engineers the type of stuff they're dealing with can be dealt with without needing to know the math. For example, you don't need to understand the math to behind the algorithms to know that bcrypt is a reasonable password hashing algorithm and that sha1 and md5 are not, or that salts are used to mitigate issues when users reuse passwords. These are principles that you can understand at a high level without fully understanding the underlying details. If anything, I think that overemphasis on requiring people to learn and understand the math has the effect of over-focusing on simpler algorithms that aren't actually what people want to be using in practice due to the fact that they're easier to teach and often foundational in conveying concepts that would need to be learned to understand the more complicated algorithms.

If using cryptographic algorithms directly requires knowing the math, then I'd agree that most people shouldn't be using them directly, but I'd go further and say that a lack of libraries that are safe for people to use for software engineering without understanding the implementation is a failing of the ecosystem; as much as "regular" software engineering people (like myself!) can struggle with the math behind cryptography, I think that a lot of people developing cryptographic libraries struggle with building reasonable abstractions and making user-friendly APIs (which is a skill I think in general is not emphasized enough for most software engineers, to the detriment of everyone).

[tptacek]

Sure. It's a failing of the ecosystem. That observation, a cup of coffee, and 1-3 years will get you a Kenny Paterson paper stunt-breaking your system. I feel where you're coming from, but, respectfully: it does not matter.

My thing here is just: learn the math! Or do something else. I did! There is so much to do in our industry.

[syncsynchalt]

Learning X25519 isn't too hard! See https://curves.xargs.org for the basics and https://x25519.xargs.org for some refining details.