Documentation of FIDO2 supported crypto algorithms

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

Hi!

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.

cc: @jan

Thank you for the response.

The use case would be actually secure ECC crypto
https://safecurves.cr.yp.to/

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.

1 Like

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?
https://www.openssh.com/txt/release-8.2

In OpenSSH FIDO devices are supported by new public
key types “ecdsa-sk” and “ed25519-sk”, along with corresponding
certificate types.

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.

Sorry to dig this up but I would very much encourage the implementation for ed25519 as a preferred alternative (which should probably be preferred by default with secp256r1 as fallback)

The OP has made a very valid point and given the significant criticism from the crypto community regarding secp256r1, it makes sense to support a safe alternative.

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.

These “safety attributes” have a direct impact on the resulting security of the overall system they are protecting. They are not unrelated even if those unsafe curves are not proven to be “broken”.

I’m not aware of any reputable cryptographer who seriously recommends to avoid NIST curves because they could be back-doored.

Im not aware of any reputable cryptographer who does NOT recommend to avoid NIST curves because they could be back-doored.

e.g.
https://www.schneier.com/blog/archives/2013/09/the_nsa_is_brea.html/#comment-202922

safecurves.cr.yp.to adds plenty of additional reasons why to avoid those curves when possible.

Nitrokey has the option to implement ed25519 for Fido2 and would thereby support the use of this algorithm by server side implementation as well.
Referring to a lack of serverside support will not help here as they will just point back to nitrokey saying its not supported on this side either.

I do not see how it would make sense for me to buy a Nitrokey Fido2 device and then use suspicious NSA crypto on them when there is an alternative curve that can be used with an increasing number of services (e.g. OpenSSH)
(This is especially relevant considering alternative Fido2 vendors already support ed25519)

Im not a developer, so I cant just go and write a patch for you guys to integrate, but I would offer any help with testing this feature.

Please reconsider implementing ed25519 !

2 Likes

Nitrokey FIDO2 makes signatures only with the secp256r1 curve at this moment. We have no plans to change that.

Is there any chance this will change?

We are also looking for Fido2 hardware which supports safe ecc curves, as it is future security requirement by our company.

I would very much like to propose Nitrokey for this internally since I personally like the open hardware concept but without alternative ecc curves that wont be possible.