Ed25519 is defined over the 255 bit field GF(2^255-19) and thus has fixed size keys, so having key size recommendations for it is silly. (The underlying EdDSA can be generalized to other sizes).
256-bit ECDSA is fine, it offers the same theoretical security level as Ed25519. Its main problem is that historically implementations were fragile (relying on high quality randomness for signing) and not resistant to side-channel attacks.
Not that I'm discouraging people to use stronger security, by P-256 is perfectly safe. If you can wait an extra second or two for some connect operations, use P-521 or ED25519.
Honestly, I wish PGP was widely accepted. My "persistent" identity has a very long key, and I create "A" (auth) keys that expire. GPG has an SSH agent it's quite beautiful. SSH keys by themselves do all of this key management and rotation by hand and I find it quite silly.
It's the connect operations I was referring to. For me, depending on the system I'm connecting to, there can be 1s-2s longer connection delay depending on a lot of factors like network latency, bandwidth, and target system computational power
PGP is not widely accepted because keeping persistent keys is not a skill the average person in IT, let alone generally has. It is also very hard to fix errors.
Using subkeys without the certify key has always been a bit of a hack. GPG doesn't even have a nice command to pull out the C key from your keychain and save it somewhere else.
FIDO2 keys for SSH are much better for the average person.
>Using subkeys without the certify key has always been a bit of a hack.
I am not sure what is meant by this. Standalone subkeys are impossible. I think this might be a reference to the case where you store the private key for the certify key somewhere safer than the rest. Which, BTW, IMO, is something very few people need to do, although it seems to have become somewhat of a fad.
When I say key, I'm obviously talking about the private key.
It honestly seems like the only reason you'd want to rotate subkeys or have distinct ones for different devices. Otherwise you're going to be stuck with at least one perpetual key anyway. It makes GPG somewhat more usable after you're done issing subkeys on your super secure airgapped workstation, because now losing a key/machine isn't a death sentence to your perpetual forever-lived identity.
But then again, it's not like you can't reply to a PGP encrypted message with "sorry i lost my keys new fingerprint is x, please use that one" and most people will just do that.
The way I look at is is that the chance of a PGP key compromise over someone's lifetime is so close to zero as to not matter. Rebuilding your reputation is at the most just inconvenient. Redemption certificates actually work with PGP so you wouldn't have to worry about old identities hanging around.
i wonder what would happen if you made a site this that looked similar and asked people to upload their private ssh key to "check if it's safe". Sort of like the phishing sites that ask you to type your whole credit card number to "see if it's been compromised".
based on the number of people I've seen that totally don't understand the concept between the public and private portions of their key, I bet you'd collect a lot.
I 100% assumed that's what this would be until I clicked on it. I feel like a large portion of (especially beginner) SSH users don't really understand asymmetric encryption enough to understand the implications there.
15 comments
[ 1.8 ms ] story [ 43.4 ms ] thread256-bit ECDSA is fine, it offers the same theoretical security level as Ed25519. Its main problem is that historically implementations were fragile (relying on high quality randomness for signing) and not resistant to side-channel attacks.
This made him seem like a non expert. ED25519 is 256 bits always: https://ed25519.cr.yp.to/
Not that I'm discouraging people to use stronger security, by P-256 is perfectly safe. If you can wait an extra second or two for some connect operations, use P-521 or ED25519.
Honestly, I wish PGP was widely accepted. My "persistent" identity has a very long key, and I create "A" (auth) keys that expire. GPG has an SSH agent it's quite beautiful. SSH keys by themselves do all of this key management and rotation by hand and I find it quite silly.
Huh? I was under impression that any of those 3 take only a few milliseconds to compute, unlike classic RSA/DSA:
Using subkeys without the certify key has always been a bit of a hack. GPG doesn't even have a nice command to pull out the C key from your keychain and save it somewhere else.
FIDO2 keys for SSH are much better for the average person.
I am not sure what is meant by this. Standalone subkeys are impossible. I think this might be a reference to the case where you store the private key for the certify key somewhere safer than the rest. Which, BTW, IMO, is something very few people need to do, although it seems to have become somewhat of a fad.
It honestly seems like the only reason you'd want to rotate subkeys or have distinct ones for different devices. Otherwise you're going to be stuck with at least one perpetual key anyway. It makes GPG somewhat more usable after you're done issing subkeys on your super secure airgapped workstation, because now losing a key/machine isn't a death sentence to your perpetual forever-lived identity.
But then again, it's not like you can't reply to a PGP encrypted message with "sorry i lost my keys new fingerprint is x, please use that one" and most people will just do that.
I wish the opposite. I wish PGP would go away.
Web of trust model of keys simply doesn't work. One key forever doesn't work.
SSH keys work great without "all of this key management and rotation by hand" if you just use ssh certificates.
based on the number of people I've seen that totally don't understand the concept between the public and private portions of their key, I bet you'd collect a lot.