ed25519 VS crypto-numbers

Software engineers should be made aware of such pitfalls, but I don't think a whole course is necessary or useful. It's very easy to build encryption that you can't crack, especially because the "types of attacks" is a truly endless font.

It's probably more useful to have a module within a course to discuss the current state of the art and learning some history about how the methods were chosen (e.g. NIST's AES, SHA2/3, and PQC open processes. I think making it very obvious that there are extremely good, quality, free tools out there would reduce the likelihood of someone DIYing some crap.

That said, I once spec'd using Ed25519 asymmetric signatures for webhooks sent out to customers, and later on one of our Elixir developers was complaining that the throughput was garbage. I was confused because https://ed25519.cr.yp.to/ boasts signing rates of ~27k/sec/core on very old hardware. Turns out they were using some "pure Elixir" library which had shit (over 1000x worse) performance. There wasn't any real surface area for attacks here, but there are plenty of devs who will blindly search package-manager-of-choice for an otherwise good encryption and get screwed. Not sure who blame in that scenario.

From https://ed25519.cr.yp.to/:

> High security level. This system has a 2^128 security target; breaking it has similar difficulty to breaking NIST P-256, RSA with ~3000-bit keys, strong 128-bit block ciphers, etc.

The first step was to generate an ed25519 - ssh key for my Github account.

From the GitLab documentation, ED25519 keys are recommended, as they are more secure and performant than RSA keys, according to the book Practical Cryptography With Go.

Correction regarding Ed25519: The Edwards Digital Signature Algorithm (EdDSA) https://ed25519.cr.yp.to/ was developed by a team including Daniel J. Bernstein, Niels Duif, Tanja Lange, Peter Schwabe, and Bo-Yin Yang. The first paper came out in 2011.

Les concepteurs de l'algorithme estimation :

Ed25519

But you're approaching it from the wrong perspective: the idea isn't to use the crypto you implement yourself, the idea is to gain a better understanding of how the "magic" works. Of course my hand-rolled RSA/AES crypto is breakable, I know that because that's the default assumption.

It's akin to saying, "you're not allowed to build your own smoke detector because it will be unsafe!". Of course I know that, I want to understand the differences between a photoelectric and ionization smoke detector, how they work in practice, because reading some PDF schematics just doesn't cut it for me.

I honestly don't understand the line of reasoning of all this crypto gatekeeping.

Fun fact: while I was doing my crypto deep dive in 2015, my language of choice being Haskell, I found issues in several libraries, specifically around entropy, and even one library with modulo bias [1]. They were acknowledged and addressed. It was a super fun learning exercise, and seeing all these comments how it's supposedly almost illegal to do this misses the point of people exploring and learning in their own ways.

https://github.com/vincenthz/hs-crypto-numbers/commit/bceb54...