Open ddworken opened 9 years ago
This could be a good medium for those who are too weary of simply TripleSec between the users private key and Keybase.
This is the first time I'm seeing the suggestion, but that doesn't meant that it's not been suggested before. It's a really good one though!
Any news on this issue? I could help with hacking but I'm not sure where to start.
I couldn't imagine better integration that KB with the Trezor (or similar key harware device management) seed. Some could please update the state/aims of the project in this direction?
If there is anyone from @keybase who wants to work on integration, please contact me via email (stick@satoshilabs.com) - send me your postal address and your phone number (for DHL) - and we'll send you free Trezor devices to work with.
@maxtaco we use PGP with our registered keybase IDs to sign Bitcoin-Payable invoices, and we are integrating the trezorconnect software to let our users login/2FA with the Trezor hardware.
Client-side security is a big concern for us, and our users are not necessarily savvy enough to use complicated PGP software. We want to recommend keybase to them, but some browser security concerns relating to keybase have been raised in the crypto community.
It's actually very easy to provide additional client-side security that eases our concerns. Trezor integration is very straightforward and we also would be willing to help. FYI we use trezor for non-bitcoin stuff internally, particularly SSH and generating PGP keys offline.
Keybase has migrated to a NaCl based device key model, and does not use PGP in any of it's normal feature set. (Besides the grandfathered in old keybase pgp
commands... which are no longer available unless you explicitly generate/import a PGP key. (The app no longer automatically attempts to generate a PGP key for you))
As for browser security:
Trezor could have been implemented into 2015 Keybase easily. (Since it was all PGP)
But for now it would be extremely specialized. Requiring a lot of work to support on both SatoshiLabs and Keybase side.
That said. I would like to see this happen :-D
We support Ed25519 curve on Trezor and are able to perform ECDH, EdDSA and other algorithm with this curve. I don't think there is a lot of changes required on Trezor side of things.
I'd also be interested in helping out with this. In my case I have a trezor, but also use smartcards. I use smartcards for PGP, SSH etc in a similar way as the trezor, but for different usecases. I can see two approaches: 1) use a hardware device for key storage, similar to a keyring; in this case the private keys would be exposed after extraction. 2) use the external device for decryption and signing such that the private key cannot be accessed without using the device. Obviously 2) is more secure, but might be too onerous depending on how often these types of operations need to be performed using the private key, rather than an ephemeral symmetric key.
Could someone from keybase comment on the difficulty of 1) and 2), and perhaps pointers to the relevant areas of code?
@ghrl Approach 1) is not applicable for Trezor - in Trezor, by design, we generate all the keys on the fly from the master secret, so you cannot import your key into the device (this also gives some extra guarantees, such as the key used via Trezor is not weak). 2) is the only option (and the correct one) for Trezor
@prusnak Approach 1) certainly is applicable to Trezor. That's how the password managers work. It's just encrypting/decrypting a value using the private key on the Trezor. Once it's decrypted it's exposed to the host.
@ghrl This of course works, but then you have to store the encrypted key somewhere outside of the hw wallet. You wrote "use a hardware device for key storage" - that's what I reacted to. I guess we are on the same page, but I wanted to clarify that part.
Trezor support seems difficult, as the number of encrypt/decrypt operations and the size of the data being decrypted/encrypted is large... I have a fast multi-core CPU with plenty of RAM and even my PC has trouble lagging sometimes (bottleneck is crypto operations)
Keybase today has so many new features that can deal with large amounts of data, and it's allllll e2ee... so keybase process is constantly doing something.
Especially with kbfs.
Perhaps there could be a limited use case where a certain function is delegated to Trezor. (like explicit keybase decrypt
and keybase sign
commands from the terminal)
I would love to see Trezor support, but Keybase as it is currently doesn't seem to be geared towards smart cards etc.
@prusnak Sorry if I was unclear.I did mean using Trezor or a Smartcard as a wallet where the wallet value was encrypted using the private key of the device, but wholly revealed to the host when "unlocked". It is a fairly common mode of operation, although it's only secure when offline. Obviously we'd prefer to have private key operations performed on the device. I just don't know how difficult that would be for keybase. I'd hope not to be pressing the Trezor ok button every 10s!
@junderw Do you have any idea how many of these operations are using symmetric keys, which wouldn't involve the external device like Trezor? Typically with crypto involving public/private keys, ephemeral session keys are generated for the bulk of the crypto operations. I don't know if that is the case with keybase.
They are not ephemeral.
only exploding messages are ephemeral
Has any research been done as to the feasibility of supporting the Trezor? For example, the trezor could be used to log the user into keybase.io. Or even better, trezor could be used to manage the user's private key (trezor has a encrypt/decrypt function). That way the user has almost complete security since the private key remains on the device the whole time.