[sneak]

This means that the time delay could be theoretically bypassed by someone other than you (as time delay access is not a cryptographic construction), which means that someone else has access today (likely Bitwarden the company), which means the end-to-end encryption has been circumvented to enable this feature, which means they could be issued a search warrant to yield all of your passwords to law enforcement immediately, prior to your being convicted of a crime.

Self host with Vaultwarden and do not use this feature.

[DavideNL]

How did you come to this conclusion?

I would assume that only the "trusted individual(s)" - a spouse or whatever - has the "private key" of the vault, so only that person can access it (not Bitwarden, and nothing can be circumvented.)

[ben-schaaf]

That just circumvents the other part of the feature; the timeout. It also means you have to trust that individual's security.

[Epa095]

Can't it be handled e.g by the spouse having "half" the key, bitwarden the other "half", which they only gives out after the timeout. Ok, bitwarden and your "trusted one" can collude to open it before, but they must both be in on it.

[nonameiguess]

The link to the feature provided here explains how it works. Your Bitwarden client has a master key that opens your vault. This is your own private key. Bitwarden the server doesn't have a copy of it. If you choose to designate a trusted successor in the case of your incapacitation, you send a request to that person. If they accept the request, Bitwarden the client will generate a public/private key pair for them. They keep the private key in their client. Bitwarden the server gets a copy of their public key and sends it to you. Now your Bitwarden client encrypts your private key with their public key and Bitwarden the server gets a copy of that. In the event of your incapacitation, they send a request to get a copy of that encrypted key. After the timeout period, Bitwarden the server will send your encrypted master key to them. Then their copy of Bitwarden the client, which has their private key, can decrypt it, and now they have a copy of your private key as well.

At no point does Bitwarden the server have a copy of anyone's private key. And no splitting of keys is necessary. This is just the normal way asymmetric encryption works.

This, of course, all breaks down if you don't trust Bitwarden the company, since they provide you the client. As far as I understand, US law enforcement doesn't have the legal ability to force a company to modify their own software to make it malicious (as opposed to doing something much simpler like forcing them to turn on IP logging on a VPN server). But if your threat model includes the possibility of US covert intelligence services MITM-ing Bitwarden the company and sending you their own malicious client, then yeah, keep your secrets in a physical vault guarded by people willing to die in a shootout with the FBI before betraying you. Make sure they'll answer to your successor if you die.

[sneak]

Ok then, so one search warrant to Bitwarden to get the encrypted key and your encrypted passwords, and another to the authorized party to get their private key.

It still comprises a break in the end-to-end crypto, and can still bypass the time delay and decrypt your passwords today without your involvement.

[sjeffh]

I agree. Wondering if such a warrant has ever been issued. This is the classic accessibility vs. security tradeoff.

[smaudet]

Better just not to encrypt anything like that.

If you have a house, which has windows, your locks do not provide security against someone smashing open the window. Key cutting schemes are a bit like this - no key offers security, only one of several access routes.

Having multiple access routes may be desirable and simultaneously a concern - a fireman smashing through your window to save your life is desirable, a burglar slitting your throat after smashing through your window is not.

Encryption is more like a lockbox or a safe room - having a burglar compromise your safe room is undesirable, and going into one during a fire is also undesirable. But you do want to use one in the event of a burglary.

A key cutting scheme may be useful in the case of mutli tenancy, but it is not a reasonable dead man switch - if your data needs to be re-encrypted either the keys themselves must be related (calling into question the security of the keys), or the encrypting party must multi encrypt the data, meaning whomever does the encrypting has full access to all the key data.

If e.g. you are yourself encrypting the data, you must multi encrypt - it would be faster just to share the key yourself, as you already have all the keys. If the third party is encrypting, this means they have side channeled your data such that they can decrypt at any point.

Again, even in the case there are e.g. two mathematically related keys, you cannot then enforce a timeout without first referencing and thus controlling the original key. You MUST distribute your keys yourself to your 3rd parties, or your data cannot be secure.

[danuker]

> A key cutting scheme may be useful in the case of mutli tenancy

No. Cutting a key in half doesn't halve its security, but it reduces it exponentially.

256 bits = 2^256 possibilities for bruteforcing

255 bits = 2^255 possibilities for bruteforcing, or half

128 bits = 2^128 possibilities, or 1/(2^128) the security

[vageli]

You can split up a key using something like https://en.m.wikipedia.org/wiki/Shamir%27s_Secret_Sharing

[kilotaras]

1. Key is 256 bits K

2. Half of K is a random 256 bit X

3. Other half is (K xor X), still 256 bit

Having half of key is still 256 bit bruteforcing.

[AgentME]

You could instead construct a key by appending two securely-long passphrases together (which will then go through a KDF in any good encryption software). Give each passphrase half to one person. Recombining them is as simple as typing both of them into the passphrase input in the decryption software.

[danuker]

Cutting a key in half doesn't halve its security, but it reduces it exponentially.

256 bits = 2^256 possibilities for bruteforcing

255 bits = 2^255 possibilities for bruteforcing, or half the security of 256 bits

128 bits = 2^128 possibilities, or 1/(2^128) the security

But you can have encryption schemes requiring N-of-M private keys to decrypt.

[chipsa]

You can cut a key in half without literally cutting it in half. Like: generate random 256bit number, xor with the key, and hand the random number to one party, and the xor'd value to the other party.

[wodenokoto]

This is the paradox. You want trusted parties to have access, only when you are unable to access it yourself, in cases such as your death, or Alzheimer.

But you _don't_ want trusted parties to be able to access this in case you are incapable due to being arrested, or choosing to simply elope.

[spurgu]

Yup. If I were to use it I'd set it to something like 4 weeks, to be sure to cover most scenarios where I'm still alive.

[pprotas]

But the wait time process only bypasses the manual approval step, not the private key step right? So you would still need a private key to initiate the time delay