ed25519 ssh public key is always 80 characters long?

Question

I am creating some ssh keys using ed25519, something like:

$ ssh-keygen -t ed25519
$ ssh-keygen -o -a 10 -t ed25519
$ ssh-keygen -o -a 100 -t ed25519
$ ssh-keygen -o -a 1000 -t ed25519

But I notice that the output of the public key is always the same size (80 characters):

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIB8Ht8Z3j6yDWPBHQtOp/R9rjWvfMYo3MSA/K6q8D86r
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAILYAIoV2OKRSh/DcM3TicD/NK/4TdqwwBPbKgFQKmGZ3
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAICpuH/fqCFLbAConChyVH6rZzSaxlnHSwQk6qvtPsf5E
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAICip4hl6WjuVHs60PeikVUs0sWE/kPhk2D0rRHWsIuyL

Is there an option/param like when creating RSA keys that may influence the length of the key, or by design will always be 80 (68 removing the ssh-ed25519) characters?

Answer 1

Is there an option/param like when creating RSA keys that may influence the length of the key, or by design will always be 80 (68 removing the ssh-ed25519) characters?

No, there can't be any such option.
First note that only the last 43 characters of your sample public keys are variable. As this is Base64-encoding, they can at most encode $43\cdot 6=258$ bits of information, which is enough to fit the 255-bit $y$-coordinate and 1-bit for the sign of the $x$-coordinate (this is called point compression).

Next note, that EdDSA (the signature scheme in use here), requires a group to work with and Ed25519 is the variant of EdDSA that fixes this group to the points on the Edwards-25519 curve (which operates on a 255-bit field). Now because your group is fixed and your public key is a point of the curve, it can only possibly have a maximal length of 256-bit (or 80 characters in SSH encoding).

Now there are "more secure" curves (eg Ed448-"Goldilocks") available than the one used by Ed25519 which have longer keys, but the signature scheme wouldn't be called Ed25519 anymore...

Answer 2

To add more context: 25519 stands for 2^255 - 19, the prime number that is the order of the finite field over which point coordinates are defined. As such, (compressed) keys will never be longer than 256 bits, as explained by SEJPM, and would not usually be much shorter assuming keys are randomly generated, as it should be for security anyway.

Therefore, there will never be a need for longer Ed25519 keys, just like there will never be a need for longer RSA-3072 keys (as opposed to RSA in general) since it would simply be a misnomer otherwise.

As to why this is: Unlike RSA, where each key has its own modulus, the Ed25519 modulus is hard-coded to allow particularly efficient calculations. RSA doesn't allow this, obviously, because it would not be secure. On the other hand, all asymmetric cryptosystems derived from Diffie-Hellman rsp. one of the ElGamal schemes support using shared parameters with only a theoretical degradation of security – for reasonable parameter lengths. For elliptic curves, it is in fact the norm to use well-known "named curves" because it isn't exactly easy to come up with good and trustworthy parameters (Ed25519 has been designed with "nothing up my sleeve"[1] principles in mind, which is highly needed given for example the Dual_EC_DRBG[2] controversy.). Some software (such as NaCl, the reference implementation of Ed25519), supports only a single (signature) curve. Others support a variety of named curves – for example, you can see which named curves are supported by OpenSSL using the terminal command:

openssl ecparam -list_curves

You'll notice that Ed25519 is not yet one of them. Note that some of the curves, notably the NIST curves, have faced similar trust issues because they contain parameters that "come out of nowhere" and may contain a hidden backdoor introduced by NSA or other potentially disingenuous actors.

Finally note that a well-designed 255-bit elliptic curve is estimated to be as secure as 3072-bit RSA, so any need for longer keys may, no offense, be more psychological than practical. The one exception is that ECC appears easier to defeat using quantum computers, but "easy" here still means hundreds (vs. thousands) of qubits, and the largest research quantum computers are to the best of my knowledge still in the lower double digits of qubits. A certain company boasts about its 5000 qubit processors, but if you read more closely, you'll see that – even if the claim is true – there is only 16x entanglement, so this is more like running several smaller quantum computers in parallel, which is not enough that it would pose a practical threat to Ed25519 or any widely used elliptic curve for that matter.

[1] https://en.wikipedia.org/wiki/Nothing_up_my_sleeve_number

[2] https://en.wikipedia.org/wiki/Dual_EC_DRBG