The main approach of the Zero knowledge is to derive a standard key from a password (using dedicated algo like PBKDF2).
With this approach, you can consider the following :
- The system does not need to keep an encrypted version of the key, as the key is regenerated, when needed, from the user password.
- The user does not need to have the key on a USB stick. As the key is derived from the password, only the password has to be stored (in the brain of the user).
All the beauty of the ZK model is about decrypting at the client side so the cleartext data are never located on the server side.
So, yes the user can access his data and No, the server does not have to know the data.
I didn't use the formulation "the server cannot know the data" because the ZK model is not perfect as the client side gets the code to execute from the server.
So, a compromised server could send malicious client side code crafted to send back cleartext data after they are decrypted by the user.
About the fact that we use a password instead of a key. You could think that is weak because, as the key is derived in a deterministic way from the password, the entropy of the key is finally the entropy of the password.
But, algorithms like PBKDF2 are designed to be robust against bruteforce (with many rounds of hash function). So, even if the password entropy is 80 bits (instead of 128 bits for a key), the attacker cannot test many passwords per second. But with a direct usage of a 128 bits key, he could try billion of keys per second.
This is why it is considered acceptable to use a password instead of a key as long as the password is not too easy to find.
Designing a architecture where the server does have zero knowledge but can let the user recover its data, if he lost his password, is difficult (at least).
Most of the solutions assume that your data are definitely lost if your forget your password and it is a assurance of security.
One possible solution is to give the user a recovery key when he sets its password and warn him to keep this key somewhere physically protected (but this key is not stored by the server as he never accesses it, only the client side).
Sharing data between users can be achieved by using an unique key which is dedicated to encrypt the data and then, this key is encrypted by the key of each user.
