Is there a way for ssh ed25519 keys?

[fbettag]

Currently i am only able to use ecdsa keys, which isn’t optimal, as apparently one leaked byte from the nonce results in breaking the encryption

[nickray]

Yeah that's crazy! One bit even!

No Ed25519 so far, someone would need to rewrite the storage layer, which currently assumes only one key type, P256. Note that this new attack luckily isn't applicable if you have PIN protection...

For the crypto implementation itself, I wrote salty, which is optimized for Cortex-M4 and has C bindings: https://github.com/ycrypto/salty/blob/main/c-api/example/example.c

[fbettag]

So technically Firefox‘s use of FIDO U2F as documented here would make this a security issue, right?

[wpeckr]

This isn't a surprising property of ECDSA, it's been well known that single-bit biases in the nonce selection (or the private key for that matter) result in complete breakage of the cryptography. This property is identical in edDSA, despite common misconception due to their marketing. Implementing any cryptography poorly will cause you to have issues.

This is not a cause for alarm and is partially mitigated by RFC6979 (also used in ed25519 for the same reason), which creates the nonce using a HMAC-like construction combining the message and the private key. We assume that this produces sufficiently unique output to avoid creating colliding nonces (which instantly reveal the private key), and reduces the chance that biases in the RNG output might result in the private key being solvable.

Note that exposure of private key material using this sort of leakage requires a considerable number of signatures in order to be reasonable used in a lattice solver, much more than is likely to be produced by a U2F key. It is a concern however that Solo does not use deterministic nonce generation, though the underlying library supports it. Fortunately it's a single change of function call to use it correctly.

[wpeckr]

There is some concern about the way the RNG is being called when producing private keys, but I don't really consider it to be a strong security issue at present. The safer way of handling the RNG output of the microcontroller would be to take a lot more time whitening its output.

I would personally suggest accumulating a large amount of bytes from it into a cryptographic hash rather than using the output verbatim, as the chips manufacturer is fairly close lipped about how it actually functions. There's comments about it being the output of disjoint ring oscillators but the implementation is anybodies guess.

The simplest implementation of this would be to use SHA256 and read 64 byte chunks from the RNG, run the compression function, and loop. This requires no significant memory usage and can be run for thousands of rounds without adding significant delay on private key creation.

[nickray]

This isn't a surprising property of ECDSA, it's been well known that single-bit biases in the nonce selection (or the private key for that matter) result in complete breakage of the cryptography. This property is identical in edDSA, despite common misconception due to their marketing. Implementing any cryptography poorly will cause you to have issues.

Calling this marketing is misleading. Objectively, it's much harder to implement ECDSA non-"poorly" than Ed25519.

[wpeckr]

It is marketing. The description of ed25519 being deterministic is simply due to their default implementation using RFC6979, for example. The way it is worded means that people believe it is a single show signature, and have implemented crypto systems based on this misinformation that rely on a non-existing property.

[wpeckr]

Functionally, there’s little difference in implementation risks between ECDSA and ed25529. There’s the same pitfalls in terms of the random number generation, same risks in timing and branching side channels which are especially relevant in embedded hardware.

[olmari]

Just pinged to say that ed25519 keys is requirement for me to even consider Solokey, or any "FIDO2 key" for that matter. While I represent myself in this situation, I bet plenty nerds feel the same, they just don't feel bothered to say it anywhere where Solokey devs would hear em :)

[nickray]

Well :) Sign up at https://solokeys.com/v2 for our new key, which will launch with Ed255 support (the new extensible architecture in Rust makes additions like these easier); meanwhile there is https://github.com/solokeys/solo/pull/478 open which will hopefully merge, but seems usable with a hacker key already today.

[aripollak]

Looks like this is supported with the latest firmware now that #478 is done!

[maweil]

I can confirm this is working with the current firmware.

[ghost]

Also tested it with SSH (ed25519-sk) and it works like a charm, even with "resident keys". Thanks so much!

$ solo key version
4.1.2 locked