In new designs or like, SSH keys?

For new designs: basically just use libsodium.

For SSH: Ed25519 or 2048 bit RSA.

We can get into the weeds about which specific cryptographic primitives are fine in isolation, but that misses the point — the ones that were fine 5-10 years ago are still more or less fine — the problems for developers and end-users generally stem from accidental misuse of cryptographic primitives in designing systems incorporating cryptographic primitives as a component. Sure, don't use DES, DSA, or MD5/SHA1; strong primitives are only necessary, not sufficient.

>For new designs: basically just use libsodium.

Check out libhydrogen from the same author. The API contains less footguns (like nonces).

The appeal of libsodium is that it is (or was) mostly an easy to consume NaCl. Correct me if I'm wrong, but I don't think libhydrogen is related to NaCl or the NaCl authors.

Finally, read this: "If You’re Typing the Letters A-E-S Into Your Code You’re Doing It Wrong"

https://www.nccgroup.trust/us/about-us/newsroom-and-events/b...

Now that's a deep cut even for a Dan Harmon fan.

For anyone else wondering what the Dan Harmon reference was:

https://en.wikipedia.org/wiki/Heat_Vision_and_Jack

What's wrong with using AES in CBC mode?

See my original comment about attack surface. Given the correct set of circumstances, transmitting the IV in the clear with CBC could possibly open you up to chosen ciphertext/plaintext attacks. And you better be doing encrypt-then-prepend-IV-then-MAC with CBC. Just a lot of gotchas that may or may not be relevant, depending on your environment.

At minimum, for asymmetric, at the time of the writing:

* ECDSA with secp-256 or ed25519 curves

* RSA >= 2048 bits. Performance takes a steep dive at 4096bits unfortunately

What people don't understand is that your implementation needs to be selected against your attack surface. If your attack surface includes hardening against side channels, your implementation selection needs to take that into account.

I don't think curve25519 is used in any ECDSA implementations. ed25519 is part of EdDSA.

You're correct. ed25519 is a separate scheme.

Start from cryptographic right answers:

https://latacora.singles/2018/04/03/cryptographic-right-answ...

On a glance none of those recommendations have become invalid in the passing 18 months or so.