Hacker News Reader

Comment by pvg | Hacker News Reader

Beside compatibility, is there any reason not to use Ed25519 keys for everything?

Nope! Ed25519 is great and honestly I think the compatibility concerns are overblown. It was introduced in 2014. If you are running four year old SSH you have other problems, like probably RHEL or some nonsense.

That said: Ed25519 is a local optimum: the bigger win is to not have long-held credentials at all, and instead use an SSH CA or something like Gravitational Teleport. Doesn't work for GitHub though.

RHEL 7 (and derivatives) do support Ed25519 keys.

In a world where you don’t have long held credentials - how do you get the short term credentials?

If I understand correctly: with long-held credentials.

Basically, you use long-held credentials to generate short-term credentials, and then use the short-term credentials themselves to access whatever server or service you need.

We do this:

Master user records in an identity/SSO system. We use ADFS.

Use a protocol which provides a portable “signed”, temporary credential. We use SAML but OIDC also works.

Have a command-line client which auths to the SSO and then relays an identity proof to a trusted component (lambda, cloud function, dedicated instance, whatever your policy says is ok). The identity proof is just a saml assertion or oidc token.

Have trusted component validate the identity proof from SSO and generate time limited credentials (we issue ssh, kube and iam). Our client then auto-xfers those creds up to jumpbox but you could drop them on workstation instead if your policy allows.

This is roughly what I'm talking about when I bring up SSH CA short-lived credential workflows.

I currently work in academic environments and I don't have much faith in the SSO systems. I thought about this, but often the SSO credentials are also the email password – the one password that gets entered and stored just about everywhere for the average user. I'm not willing to bet the security on a user's main login/email password, which seems to be a common setup. With that password or even just access to a user's main mailbox, a smart attacker might get through multiple layers of security by simply convincing services or staff to reset credentials.

Though it might work with a second, more limited (not-so-)SSO system for specific users and environments.

You're right that shitty systems train users to be phishable -- by typing their password all over the place -- all the time, not even counting the poor default password hygiene most users have. This is one of the reasons U2F/WebAuthn is so incredibly valuable.

I love SAML (not the XML part), it gives me one place where I can concentrate. My SSO first tries kerberos (if they've logged into their Windows machine using AD), x509 for smartcards, and if all that fails, username+password+totp. Password login is blocked without a TOTP token provisioned. Also it's one place I can stick fail2ban rules.

Agree, SSO failures train people to type their domain password everywhere. Also used for proxy login, sent out via SMBv1 etc.

A jumpbox with 2FA might be workable. Servers only accept logins from the jumpboxes, but you don't have to get 2FA working on them. Essentially it's an internal VPN gateway. (Be on the lookout for the knobheads in IT that set up parallel login mechanisms without 2FA, like mounting the file share, virtual desktop logins from the hypervisor, Kerberos auth.)

You could have a key rotation process where you use the old key to install the new key and delete the old key. But it seems sketchy because if you don't rotate in time the old key expires and you're locked out. I think in practice you'll always end up with a super-duper secret, rarely used, long term key. Or have some other backdoor like root password, LDAP/Kerberos, ADFS, etc.

The only thing I can think of is that no smartcard/usb-key that I know of support them. Please if someone knows of any, let me know.

I think some OpenPGP smartcards like the GnuK might support it, but no PIV mode cards AFAIK. And I don't know if the components higher up the stack (gpg-agent, ssh-agent, PKCS#11 drivers, etc) can make use of those keys. Each new key type requires protocol support up and down the stack.

The OpenPGP 3.3 card has ECC but not Ed25519 :(

FYI it supports [0]: ansix9p256r1, ansix9p384r1, ansix9p521r1 and brainpoolP256r1, brainpoolP384r1, brainpoolP512r1

[0] https://gnupg.org/ftp/specs/OpenPGP-smart-card-application-3...

Yes, Ed25519/Curve25519 has weird cryptographic choices that make it difficult to do certain things. I wouldn't use it for anything other than the specific use case it was designed for: key agreement and single signature authorization/verification.

Elaborate? I thought Ed25519 was a general deterministic signature scheme, and Curve25519 a general key agreement scheme.

And yet people have used it for ring signature authorization schemes (CryptoNote/Monero) which has directly led to inflation bugs (permitted double-spends) and an inability to have key derivation for secure long lived wallets.

That’s due to Curve25519 having a non-unit co factor. There’s a half dozen other weird properties of the curve chosen for smal efficiency gains or whatnot which also might lead to security holes in any application which is not the single signer or 2 party key agreement use case.

No, you should use Ed25519 keys wherever you can.

Reply on news.ycombinator.com