Published on: 2015-03-08T08:20:31+00:00
Pavol Rusnak, in an email thread, discussed his implementation of a SignIdentity message for TREZOR, which would be used for HTTPS/SSH logins. He proposed deriving the BIP32 path from the HTTPS/SSH URI and using it to derive the private key. This scheme could also be applicable to GPG keys. Another member in the thread mentioned FIDO's U2F protocol, which prevents credential phishing by tying into the browser SSL session. Yubico's FIDO U2F security key was also mentioned, as it generates a unique keypair for each service to enhance privacy. However, using the device alone does not allow easy identification across services for individuals with multiple pseudonyms.A user named Mem Wallet shared their approach to managing a GPG identity for encryption and signing with zero bytes of permanent storage. Pavol Rusnak, as the author of BIP44, suggested allocating a new BIP number instead of using BIP44 for this purpose. He proposed creating a GPG key hierarchy per device/master seed rather than per Bitcoin account. In addition, Pavol Rusnak mentioned that he was working on implementing a SignIdentity message for TREZOR, specifically for HTTPS/SSH/etc. logins. He shared a proof of concept (PoC) on Github, where the BIP32 path would be derived from the HTTPS/SSH URI to obtain the private key. The same scheme might also work for GPG keys by utilizing "gpg://user@host.com" as the URI.Furthermore, there is a javascript implementation available on http://memwallet.info/bip44ext/test.html that demonstrates the use of a bip44 Wallet to generate deterministic GPG identities. This allows users to manage a GPG identity for encryption and signing without requiring any permanent storage, such as on Tails. The paper detailing this implementation can be found on https://github.com/taelfrinn/bip44extention/blob/master/README.md. A minor correction has been made to the implementation, specifying that the smallest S value should be used to prevent non-canonical/identical outputs caused by different ecdsa implementations. Feedback and comments on this approach are welcome.
Updated on: 2023-08-01T11:59:54.500939+00:00