Inconsistent explanation about how private key is encrypted in White-paper

Samuellllll

Page 18: The resulting 32 bytes of material (derived from both your Master Password and your Secret Key) will be your Master Unlock Key (MUK) which is used to encrypt the key (your private key) that is used to decrypt the keys (vault keys) that are used to encrypt your data.

Page18: We organize the public/private key pairs together with the symmetric key that is used to encrypt the private key into Key Sets. Our Key Sets make extensive use of JSON Web Key (JWK) objects.

From two paragraph above, I am confused by the inconsistent explanation, In paragraph 1, it says privateKey is encrypted by MUK, while paragraph 2 says privateKey is encrypted by SymmetricKey.

I am clear that the latter one is correct which then lead to two following questions:

• what does paragraph 1 mean?
• what is the benefit of using SymmetricKey instead of encrypting privateKey with MUK directly?

---

1Password Version: Not Provided
Extension Version: Not Provided
OS Version: Not Provided
Sync Type: Not Provided

AGAlumB

@Samuellllll: I think you're (understandably) getting hung up on this because there are so many different encryption keys used, in a chain, to facilitate key exchange for sharing.. You would not want to share your MUK with someone else just to share some data with them. To answer your question, the encrypted symmetric key is itself encrypted with the Master Unlock Key, so the private key is encrypted by both of those (p.15, 26). It's going to be a bit confusing no matter what because of the complexity involved with allowing for secure sharing that does not require sharing secrets that could be used to compromise data that you do not want to share, but we're working on revising the white paper to clarify things where we can. I find it helps to read it more than once, much like I gain a better understanding of a deep book by doing so. But there's definitely room for improvement. Thanks for bringing this up! :)

jpgoldberg

The first paragraph does, indeed, leave out a layer of indirection. It should probably be corrected or at least annotated that there are a few shortcuts taken. The idea was to get more precise as the white paper continues.

what is the benefit of using SymmetricKey instead of encrypting privateKey with MUK directly?

There are a couple of things that come up here. One is to allow for Master Password changes to propagate in reasonably sane ways. Another has to do with how some clients manage multiple accounts. To keep things "simple" the white paper has ignored the extra layers in the chain of keys that we have on various clients. Partially, this is because things differ from client to client, making the explanation even more tedious. And some of those details are subject to change.

One of the uses of indirection and local clients is the various mechanisms to avoid having to derive the SRP x each time. When you first set up a new client, you need to go through the key derivation for the MUK and for the SRP x. That involves going through 100,000 rounds of PBKDF2 twice. But an attacker who captures your local data "only" has to go through that 100,000 once per guess. So clients are free to encrypt the SRP-x either with the MUK, or that with that mysterious symmetric key. This way, on all but first set up, the client only needs to go through the 100,000 PBKDF2 rounds ones.

Although we haven't made us of it, we also have the freedom to use a KDF that is tailored to the particular client platform and hardware for all but the first unlocking. So what you are seeing described in the white paper is the canonical unlocking when there is nothing local to work with. And in that situation, the symmetric key that is encrypted with the MUK is superfluous.

There is one more thing. This allows us consistency for all key pairs. We have keysets for groups and those have an encrypted symmetric key. It's simpler to use the same types of objects and decryption sequences in both cases.