> Also of note, is Ed25519 does not harden itself with additional "bits" in the normal RSA sense, it relies on "rounds" of KDF to apply more brute-force protection to the passphrase

That doesn't make sense. Key stretching your pass phrase, and the number of bits your key pair is, is totally separate. The reason people dont talk about number of bits in Ed25519, is that the security margins are higher and many of the more efficient algos for cryptoanalyzing this stuff dont work on elliptic curves, so you dont have to be constantly changing the key strength to keep up with better computers, its just always 256 bits.

Exactly, I was trying to point this out, that they were seperate. I only mention increasing the rounds of your passphrase in the same sentence because you do this when generating the key to increase security, and if you don't specify it, it gets overlooked. You don't have to specify any additional bits in the key strength, but you should specify additional rounds in the passphrase. Agreed they are unrelated reasons internally, but its a good way to add an additional level of protection.

Except Ed25519 only has 128 bits of security, not 256

I was under the impression the key size was 256 bits but the security level was 128 bits.

But IANA cryptographer.

Can you please provide a citation for 2048-bit RSA not being enough? That is counter to apparently reliable advice elsewhere.

I didnt say it wasn't enough. I said you should upgrade to elliptic curve crypto, or if you have to stay on RSA, re-generate with 4096 because it's better. A 2048 bit RSA key only provides 112 bits of security - claimed to be suitable until the year 2030. RSA-2048 is still techncially ALLOWED by NIST, but that is the literal cutoff mark, below which is disallowed. The spec dates back to 2012 with "NIST Special Publication 800-57 Part1". This specification is up to Revision 5 now, the most recent of which is named "NIST Special Publication 800-57 Part 1 rev 5" published May 2020. https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.S... . There is no new news regarding the 2048 length since 2012. This estimate also does not factor in CLASSIFIED quantum cryptography thats hidden from the public. I personally don't trust them after the Snowden documents either. Plenty of sites are still using 2048 for compatibility and speed, but if you are re-generating your key now, its advised to upgrade to elliptic curve, or if you must stick on RSA, 3072 or 4096, because 2048 is the literal cutoff point. This document also describes the migration process. NIST SP 800-131A Rev. 2 - Transitioning the Use of Cryptographic Algorithms and Key Lengths https://csrc.nist.gov/publications/detail/sp/800-131a/rev-2/...

The GPG documentation specifically says that 4096 is not "better".

https://www.gnupg.org/faq/gnupg-faq.html#no_default_of_rsa40...

4096 _does_ take a lot of extra CPU resources, and it _is_ diminishing returns. But anyone who prioritizes this above all else is arguing either from a vantage point of distributed scaling across servers that cost money to handle millions of extra cycles per key times millions of keys, or from a place of defending the status quo just for the sake of defending their past choices, which I hate. Their motives for defending it have to be questioned. The page says you gain very little, because by this point we are moving away from RSA to elliptic curves, from which you gain A LOT. Section 11.5 states: "If you need more security than RSA-2048 offers, the way to go would be to switch to elliptical curve cryptography — not to continue using RSA." This is the entire point of this HN Thread. A lot of smartcard and hardware vendors have a vested interest in the status quo 2048-bit RSA because they are stingy with embedded CPU resources or monetary resources in the cost of switching algos. And theres specifically an issue with GNUPG and Elliptic Curves and license compatibility https://www.yubico.com/blog/big-debate-2048-4096-yubicos-sta... If you are an end-user with personal keys only, and fast computers, switching to a 3072 or 4096 bit key is a no brainer. The largest overhead of additional CPU cycles is only consumed on generation, not on verification. Interoperability is nearly always ensured, and you gain some 16% percent security (which is NOT "almost nothing"). Beyond that, you should switch to Ed25519 (which uses less CPU resources anyway). Continuing to argue this point is beyond the scope of this discussion. You can research yourself why RSA-2048 is being deprecated, and everyone who can switch is switching Ed25519. Or maybe the OP will write another blog post better than I can, since nobody listens to me anyway. The point was to get you to switch away from RSA, not continue using it with 4096.

> Also of note, is Ed25519 does not harden itself with additional "bits" in the normal RSA sense

Yes, it does, it is just not Ed25519 anymore, check out Curve448 and EdDSA-Ed448, same Edwards curve construction, more bits, more security. It's just that Ed25519 is plenty strong for many use cases.

Also, don't confuse the strength of the KDF with the strength of the curve itself as others have noted - Ed25519 is the same strength whether you hash your passphrase 1 or 50000 times. But with the 1 round your key might be easier to brute force if you have a weak passphrase.

I havent confused them. Its phrased like that to alert people they can't change the key strength by bit-ness, but they can change the KDF password-strength, on GENERATION, which is peoples first gateway into Ed25519. And X448 opens another can of worms, ssh-keygen still does not support that algo. OpenSSL 1.1.1 does, with: openssl genpkey -algorithm Ed448 but that doesn't relate to this discussion of use for SSH public keys. The support is very bare bones and only allows C code access meant for use in TLS servers, not SSH command line tools. They recently added EVP_PKEY_get_raw_public_key() relating to Ed25519/Ed448 but that doesnt help in actually running a command to generate these X448 algo Curve keys yourself for use in SSH keys.

So if you know how to use X448/Ed448 public/private keypairs with SSH, do tell.