-
Notifications
You must be signed in to change notification settings - Fork 43
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support for ed25519 keys #82
Comments
Neat, I had not heard of That said, I would not recommend doing this. Properly securing ssh keys is beyond the scope of discussing in a GitHub issue, but in short this tool does not provide additional security for your ssh keys. On your machine, there seems to not be a keychain so this program is falling back to storing secrets in If you had a compatible keychain program (e.g. Gnome Keyring), this tool would store keys in the keychain which is arguably better. But I think that is pointless because Gnome Keyring can directly act as an ssh agent instead of this extra step of using I don't know why |
Thanks for prompt response! I'm not planning to use softu2f as an additional security feature, as I fully understand it doesn't add anything to ordinary ssh keys security-wise. My rationale for using softu2f is testing and development -- I'm trying to implement I'll try to look into this a bit deeper. As far as I can see from rust-u2f code, it mentions ecdsa only in attestation code, where it uses hardcoded ecdsa certs. Is this a place where ecdsa support (and lack of ed25519 support) might be coming from? Or should I look elsewhere? |
Development and testing are exactly the intended use cases! Sorry to be brusque, had issues with people incorrectly using this tool in the past and complaining so I try to be upfront about limitations. Looked a bit closer since you have such a cool use case, but unfortunately U2F definitely only supports I'm not exactly sure what it would take to support FIDO2, but it's a fair bit more than new certs. It'd be a rewrite of the Sorry to not be of more help, good luck on your project. Findings(documenting for posterity) This verbose keygen outputs shows the virtual device is found, but there is an invalid argument error that comes from a line in the u2f_register function of the fido2 lib that checks for ecdsa. This is done for backwards compatibility. You can use the fido2 library to talk to U2F keys, but the library will check the options you are using are actually supported by the older U2F keys/protocol: https://github.com/Yubico/libfido2/blob/980654105d2123932e895c7f7cd740f6a7909e08/src/u2f.c#L657
The relevant part of the U2F spec is the register messages. The request message has no way to select a key type and the response specifies the key/signature is to be ECDSA: https://fidoalliance.org/specs/fido-u2f-v1.2-ps-20170411/fido-u2f-raw-message-formats-v1.2-ps-20170411.html#registration-request-message---u2f_register Also a note that I had to update to libfido2 version 1.8.0 before I could use even the |
Great write-up, thanks! It seems that the task is indeed much bigger than I initially thought. I wonder if it would be possible to use OpenSK project's code as a template/inspiration for implementing CTAP2 protocol. |
I've successfully created ecdsa-sk key with ssh-keygen -t ecdsa-sk command using softu2f service. Approval notification appears and key is successfully generated
But when I try to create key ed25519-sk key with ssh-keygen -t ed25519-sk, ssh-keygen returns Key enrollment failed: invalid format error, and no notification appears.
Is it because ed25519 keys are not supported, or I'm doing something wrong?
Logs:
The text was updated successfully, but these errors were encountered: