PGP might not be very usable but it also had mechanisms to do this.
if you are scared of people copying the vault before they lose access to the storage: you’ll be very sad to know that this is already possible with the SaaS solutions.
if you're worried about people breaking the vault if they have access: then its even more of a reason to control the access.
My point exactly - 1password.com addresses those problems (e.g. by adding a random key to the master password, and via Secure Remote Password auth), while using just a master password (sans random key) in a dumbly file-hosted vault does not.
me and my friend can have private keys to a ”vault” (or, file) that are solely our keys, even if they decrypt the same secret.
No need for a “master password” to unseal the vault.
Here is the gpg docs for it: https://www.gnupg.org/gph/en/manual.html#AEN111
section 5.1 of RFC 2440 explains how it works: https://www.ietf.org/rfc/rfc2440.txt
With 1P, it works roughly like this:
- Every vault item is encrypted with the vault’s key (randomly generated number w/ 256 bit, AES)
- For every user that has access to the vault, the user‘s public key is used to encrypt the vault key. I think this is what you meant by multi-key? Adding a team member to a vault means encrypting the vault key with the member‘s public key.
- The user‘s private key in turn is encrypted with the „Account unlock key“, which is made up of: Master password + random secret [1] + salt. Neither of those is ever sent to the servers in plaintext, made possible by zero knowledge proofs.
If you stored your ciphertext on a dumb file hoster: Sure you can increase entropy in the master password to match 1P‘s random secret. Or you can use a 256bit key as master password. But where do you store that safely? The macOS/iOS secure enclave would be appropriate, and that’s what 1P is doing. Otherwise, that key would have to be encrypted again, right, in order to allow secure backup? Aren’t we entering recursion there? At some point you need to have either a password you can commit to memory, or one that’s stored in sthg like a secure enclave.
You can also use a high entropy password and print it out, like 1P is suggesting for the secret key. But exposure of the printed secret key in the case of 1P doesn’t mean a breach because it’s just a salt in addition to the master password.
1: Random secret is stored on your device, and they ask you to print it out upon signup. It’s never shared in plaintext with the 1P server, same as the master password.