> On confirmation, the grantor’s Master Key is encrypted using the grantee’s public key and stored once encrypted. Grantee is notified of confirmation.
> When the request is approved or the wait time lapses, the public-key-encrypted Master Key is delivered to grantee for decryption with grantee’s private key.
I'm not quite sure how I feel about the way they're doing this. Whilst this is a feature a lot of people desire, the way that they're doing it makes it feel like it would be impossible to verify that they're not storing your Master Key, or transmitting it to someone else - i.e. backdoor.
At least, not with the level of detail I can find. [0]
I'm under the impression that the "encrypt master key with the receiver's public key" step is done on-client, so you could verify that the master key isn't being stored the same way you can very they're not sending the master key when logging into the web ui: looking at devtools and seeing everything that leaves the network.
It's a little too much to sort through on mobile, but I believe this is a reasonable place to start looking (this is the web app, the server might be worth a look too). As far as I can figure out, it's not part of the cli client.
So keys aren't verified at all. That seems like something that needs more than a single sentence that comes _after_ they explain the confirmation process.
> When the request is approved or the wait time lapses, the public-key-encrypted Master Key is delivered to grantee for decryption with grantee’s private key.
I'm not quite sure how I feel about the way they're doing this. Whilst this is a feature a lot of people desire, the way that they're doing it makes it feel like it would be impossible to verify that they're not storing your Master Key, or transmitting it to someone else - i.e. backdoor.
At least, not with the level of detail I can find. [0]
[0] https://bitwarden.com/help/article/emergency-access/