But is that a problem though? I generated my own HSM/U2F keys throwing dice and the seed is basically just one 256 bit numbers. I did have, indeed, to compute a matching checksum (for the scheme I used represented the 256 bit numbers as a list of 24 words, out of a dictionary of 2048 words, where some bits of the last number acts as a checksum).

This only needs to be done once. For example by booting an old computer with no wifi capabilities and no hard disk from a Linux Live CD.

> You'll need to generate the key on a less secure host to do that, though, which partially defeats the purpose of a hardware key in the first place.

I kinda disagree with that. I generated my key by throwing physical dice. No random number generator to trust here. I only needed an offline/airgapped computer to compute the checksum and that program cannot lie: I know the first 256 bits out of the 264 bits so the program computing the checksum cannot lie to me, it's only giving me 8 bits of checksum.

Then I only need to trust the specs, not the HSM vendor.

Now, sure, my old Pentium III without any hard disk and without any WiFi, without any physical ethernet port, may be somehow compromised and exfiltrate data through its fans or PSU or something but what are the odds here? Especially: what are the odds compared to the odds of having a rogue HSM vendor selling you U2F keys for which it fully knows the secret?

I'd argue this requires less trust than the trust required in buying a pre-initialized HSM device.

> booting an old computer with no wifi capabilities and no hard disk from a Linux Live CD.

By doing that, you are increasing your trusted code base by several orders of magnitudes doing that. This might be fine for your purposes, but in a corporate environment, it might very much not be.

> Then I only need to trust the specs, not the HSM vendor.

You do trust the HSM (vendor) no matter how you use it. Ironically, the more modern a cryptographic protocol is, the more opportunity for surreptitious key exfiltration there is. This could be in the form of predictable (using a shared secret) initialization vectors, wrapped keys and much more.

You also trust an HSM to be more tamper-resistant and/or more hardened against logical attacks than a regular computer, or there would not really be a point in using one in the first place.

You can generate the keys inside the yubikey. Then just have two keys instead of a shared key. That’s actually better IMHO since that allows you to revoke one of you lose it instead of having a compromised backup.

Ah, sure, if your use case allows registering multiple keys that is indeed a good way to solve it. Unfortunately that's not always the case (as pointed out in other threads).

Yeah, for the paranoid you’d have an air-gapped box with your PGP tools on it that you’d plug the hardware key into for setup.