In my experience, to generate any Trezor key you need there to not be a .gnupg/trezor directory. So here is what I would try as a workaround. If you're trying to add a Trezor subkey to a Trezor master key, I would first generate the master key, then export the public key + private key stub, then rename the trezor directory and import the public/private key into the .gnupg keyring by setting GPGHOME=.gnupg and running gpg --import, and then run the subkey command.

@syzygyzer Thanks, now I have the same problem as you in #340. If I get lucky to create the subkey in the first place, I end up in the "no secret key found" as you did. My goal here was to set up a dedicated key for encryption, another for signing and another one for authentication to use this similarly to how one would use Yubikey (see https://github.com/drduh/YubiKey-Guide), which ties in to #313 and presumably a lot of work and resources required.

@prusnak Have you guys considered putting this project under https://github.com/satoshilabs wing officially to make tighter integration part of the product offer? It would make it even more appealing for widespread adoption.

@prusnak Have you guys considered putting this project under https://github.com/satoshilabs wing officially to make tighter integration part of the product offer? It would make it even more appealing for widespread adoption.

We don't have resources to help Roman with the development at the moment, so this move does not make any sense. Also I feel Roman deserves full credit for his work on this, so it is only right if the repo stays here.

@syzygyzer Could you please clarify how exactly you export including the private key stubs?

Subkey generation is intended for when the master key is a non-Trezor key, located in a different home folder.

Having both a (manually created) subkey and a primary be Trezor keys does not make sense. The reason is that the keys themselves are derived from the user id, which will necessarily be the same for all keys. The implication is that even if you create a whole bunch of subkeys, they will all have the same key. If one of them leaks, revoking it with the master key would be useless, because you wouldn't be able to create a new subkey with a new key.

The only way this could be resolved is if there was an option to set a custom derivation path for a key that is different from the user id. Note that this has implications - the derivation path is what appears on the hardware device's screen when asked to confirm a signature.

Another option is to modify the --time parameter. However, this only changes the key's fingerprint, not its encryption keys. So if the private key somehow leaks, getting a new fingerprint with the same key is not going to be particularly helpful.

From the get-go, splitting keys like that is not particularly useful for a hardware device, where leaking just one key (without leaking the master recovery phrase) is a nigh-impossible scenario.