Sorry if I missed to find that information, but I would like to know if the FIDO2 stick supports only ECDSA credentials or also ED25519? Or anything else?
As defined in FIDO2 specification, it is secp256r1.
Relevant links to specification for completeness:
I would also like to know what algorithms the “Nitrokey Fido2” supports.
Pointing to the specification is not a definitive answer to this question, since the specs only specify the algorithms that MUST be implemented and not if there are any optional algorithmy implemented in this product.
@Nitrokey Support: Please list the algorithms that re supported by the Nitrokey FIDO2 Hardware.
e.g. is Curve25519 supported or only the NIST Curves from the NSA …
The FIDO2 stick is also not yet listed here: https://www.nitrokey.com/documentation/frequently-asked-questions-faq#which-algorithms-and-maximum-key-length-are-supported
Nitrokey FIDO2 makes signatures only with the
secp256r1 curve at this moment. We have no plans to change that. Do you have a custom use case?
Implementation side other curves are available in the used cryptographic libraries codebase, including Curve25519, but are not used.
Linked summary was thought more for the smart card features of our products. I think better place for this information would be in the product’s fact sheet.
Thank you for the response.
The use case would be actually secure ECC crypto
I personally do not see a target audience for an open source hardware token that only uses ECC Crypto from the NSA…
Using save curves like Curve25519 has more benefit then using a hardware token or even an open source hardware token. Having a token that does not support save crypto does not make sense to me.
Building the Fido token with the default curves to implement the specifications is fine, but having save curves as an alternative should be a minimal requirement for trusted crypto tokens.
I would appreciate it if nitrokey were to offer not only trustworty hardware tokes but also trusted crypto algorithms in the future.
You mix up “safe” and “secure” which are two different things. The website’s name is “safecurves” not “securecurves” for a reason: At safecurves.cr.yp.to curves are primarily evaluated with focus on complexity and implementation considerations. There “unsafe” means that the implementation needs to be performed carefully and may be more complex and error-prone than for other curves. I’m not aware of any reputable cryptographer who seriously recommends to avoid NIST curves because they could be back-doored.
But in context of FIDO2 this discussion is pointless because FIDO2 requires
secp256r1 and we can’t change that. Any other curve implemented in our device would be useless because it couldn’t be used with any application.
In other words, the algorithm has to be implemented as well on the server side, so the signature could be validated, otherwise it will be rejected. I do not know any FIDO2 compliant server implementation, which would support
curve25519. In the linked documentation the identificators for known algorithms are listed.
Edit: It does not mean it is impossible to support it, but the API (ids, algorithms) has to be common between server (webservice) and client (device/browser) to make it work.
Is OpenSSH an example of such client/server?
In OpenSSH FIDO devices are supported by new public
key types “ecdsa-sk” and “ed25519-sk”, along with corresponding
Note: FIDO/U2F tokens are required to implement the ECDSA-P256
“ecdsa-sk” key type, but hardware support for Ed25519 “ed25519-sk” is
less common. Similarly, not all hardware tokens support some of the
optional features such as resident keys.
Yes, that’s an example of the usage indeed.