Why so many encryption / mac keys

johannesauer
johannesauer
Community Member
edited October 2018 in Lounge

Hi,

i studied the OPVault format and I have a question:

Why are there so many encryption keys? An attacker would never try to brute force an AES key, since this is infeasible - he would always try to crack the password by brute force or dictionary attacks. And if you have to password, you have access to everything. So the additional keys (besides the password derived AES/MAC keys) seem useless to me.

Thanks for your help,
Johannes


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

Comments

  • AGAlumB
    AGAlumB
    1Password Alumni
    edited November 2018

    @johannesauer: If you think that's a lot of encryption keys, wait til you see 1Password.com. ;)

    I apologize as I'm not really sure how to answer without sounding a bit snarky, but I mean this sincerely: "Why are there so many encryption keys?" Because that's how many we need to secure the data efficiently! :lol: They're chained together in such a way as to maintain security and efficiency. And with 1Password.com, even more encryption keys are needed to allow for sharing, since each user needs to encrypt their own data with keys only they have access to, but also use "public" keys to encrypt shared data so that both they and others can access said shared data.

    I think maybe a helpful, concrete example might be Master Password changes. If every bit of the data were encrypted with the Master Password directly (instead of a chain of encryption keys), then all of the data would need to be re-encrypted when the Master Password is changed. We all accumulate more and more data over time, so someone changing their Master Password after having added hundreds (or thousands) of items over the course of years would suffer a huge penalty and have to wait a long time for such a process. It would feel very punitive for a long-time 1Password user to change their Master Password in that case!

    Also, syncing: currently, an OPVault Master Password change is relatively quick to propagate across devices: you just need to unlock using the "old" Master Password, and as soon as the (relatively tiny) encryption keys sync (which are encrypted using the Master Password), the new Master Password can be used to unlock. Contrast that with needing to re-sync your entire vault if we didn't do things this way. Otherwise a long-time 1Password users syncing data between devices would suffer a second (and third, or fourth, etc., if they have many devices) penalty for changing their Master Password.

    Again, I apologize for perhaps not having a completely satisfying answer for such a broad question, but hopefully this helps to give you a sense of it. :)

  • jpgoldberg
    jpgoldberg
    1Password Alumni

    There are a couple of things I would like to add to @brenty's answer.

    Intuitively it feels like everything should just be encrypted with a key derived from the Master Password. And that is the way it looks to people. In what is presented to the user, we hide the enormous complexity of the chain of keys. As @brenty correctly pointed out, a lot of this has to do with synching and managing changes. If the whole thing is just one big blog of encrypted data, making a change to any one part would mean re-encrypting all the masses of 1Password data and then having to re-transimit all of that for synching.

    Our data formats have to be designed with synching in mind, and for speedy usage on a wide variety of platforms.

    Extra keys are not extra layers of defense

    The separate keys are not layers of defenses. You, @johannesauer, are absolutely correct that the weakest point is the Master Password and not some randomly chosen 256-bit key. But there is value in isolating that weakest part, so that is why the first part of the key derivation is there. The derived key is only used to encrypt a randomly generated key. This way the inherent weakness of the derived key (as being not really stronger than the user's master password) is contained in a way that makes it much easier to reason about the security properties of other parts of the system.

    So you are correct that the extra keys don't provide that kind of defense, but that isn't their purpose.

    Note that for 1Password.com service, we've done more to help contain that "weakest part of the system".

    Overview keys

    Having distinct overview keys from the item keys is what allowed us to encrypt things like URLs and Titles. That sort of data needs to be quickly available to 1Password do look up items or present them in a list for you. So the idea was there would be times when locally the overview data is decrypted while the other information isn't.

    This doesn't really matter that much on the desktops, which have the computing power to decrypt everything fairly quickly on unlock, but on lower powered devices (and we had to consider the lowest powered devices we were supporting at the time), decrypting everything on unlock would take time and battery. Now that most devices have hardware support for AES, this isn't such an issue, but it was at the time.

    Indeed, this big change in how overview data was treated between Agile Keychain Format and OPVault had a lot to do with changes in computing power between the times when they were designed. When the Agile Keychain Format was first deployed, we were still 1Password for Mac OS X 10.4 (Tiger), and so our data format had to be usable on the Dual USB iBook, with its 500 Mhz single core processor.

    Individual items keys

    Having separate keys for each item was in anticipation of something we never did with OPVault. We were looking at having a secure item sharing mechanism between users. Instead, we have done this with our service at the vault level. So now each vault has a key for encrypting the item details and a key for encrypting the item overviews, and vaults are the entities that people share.

    But now that we have real sharing in place, we have even more keys that are using for encrypting other keys. You have a personal keyset, which includes and RSA public/private key pair, and the public key is used only for encrypting other keys (typically vault keys). You also have a signing key pair, so far has limited use, but will become necessary if we build sharing between teams and families (instead of just within them).

    Limits on keys

    There are limits on how much data can safely be encrypted under a single key or under a single key and IV pair. Now we were coming nowhere near those limits with 1Password data. (Particularly with using separate keys for each attachment), but it is nice to know that we wouldn't have to worry about those limits at all.

    Note that we do have an issue with attachment limits in our latest format. Although our limit on attachment size is well below the limit of the maximum amount of data that can be encrypted using AES-GCM, but for AES-GCM to be used in the safest way all of the data should be in memory. (This is not the case for our Encrypt-then-MAC construction in OPVault, but that requires two passes over the data.) So as a consequence, we've had to limit the size of attachments that can be decrypted in 1Password on some mobile platforms. Ultimately, we will need a new way of encrypting attachments, which will end up requiring more keys, in that the attachment will need to be chunked, with each chunk encrypted under a different key, and the "key" for the attachment will just decrypt the keys for each chunk.

    So that is another example of why we might have to further extend the chain of keys.

    Abstractions

    We don't add complexity for the fun of it. So it is very reasonable to ask what the role of all of the complexity of these chains of keys are. And in general it is because having this kind of complexity makes other things much much simpler. That includes the kinds of encryption that needs to be performed with respect to synching, finding items, and sharing, as well as dealing with key changes.

  • johannesauer
    johannesauer
    Community Member

    First of all, thanks for your detailed answers @brenty and @jpgoldberg. And I complete understand the benefits as you described them. But I see one big problem. Image the following:

    There is Bob, some ordinary guy, that knows that using password managers is a good thing, but does not know exactly what encryption, hashing etc is. Bob installs 1Password and chooses not the best master password. He is using 1Password a lot and after some month he decides to change his master password to something stronger. Only the master encryption/hmac key will get re encrypted, the key itself does not change. As you said, that gives you the benefit that it is not necessary to encrypt all the data again. But here comes the problem:

    Some attacker, Eve, cracked his password when it was weak. At that moment she was able to read all of Bob's data. That is no surprise since she cracked the password. But since the master key itself never changes, she is able to read all of Bob's future data, even though he changed his password! The security of Bob's vault is never stronger than the weakest password he every used as the master password, even for data the will be added in the future.

    Do I miss something here?

    Greetings,
    Johannes

  • AGAlumB
    AGAlumB
    1Password Alumni

    @johannesauer: That's correct: using a weak or known Master Password can have broad (negative) implications for security. That's why we always recommend using a long, strong, unique Master Password, and 1Password further strengthens it against attacks using PBKDF2. At the end of the day, that's the best defense. And these days we also enforce a minimum length and exclude many weak/known passwords. For someone like Bob, it isn't all bad news though; creating a new vault/account (or going through recovery) will generate brand new encryption keys as well; and having them encrypted using a long, strong, unique Master Password will ensure that it's safe from the bad guys. :)

  • XIII
    XIII
    Community Member
    edited November 2018

    creating a new vault

    But you can't do that for your default Personal/Private vault, right?

    So if you ever discover malware on your system you have no choice but to create a new account?

  • AGAlumB
    AGAlumB
    1Password Alumni

    But you can't do that for your default Personal/Private vault, right?

    @XIII: Yes. That's why I said "vault/account", not "vault". ;)

    So if you ever discover malware on your system you have no choice but to create a new account?

    No. As I mentioned, there's also recovery, which will give you new keys. However, depending on the "malware" situation, you may have to do none of that, or need to go and change all of your passwords for websites, if everything was compromised. I'm not sure that hypotheticals are useful.

  • AlwaysSortaCurious
    AlwaysSortaCurious
    Community Member
    edited November 2018

    I asked sort of a similiar question ages ago... it’s a shame it isn’t easier to accomplish without blowing your account data up and effectively resetting your account (recovery, or are you speaking to teams only?) when I first set up my account, I used a decent but not fantastic password so I could get used to the service... and then updated it to something much better... 😔

    Edit: lol. Looks like I bookmarked it. I see that @rickfillion answer back then made me feel better (and might help here in this thread).

    For those who are curious. Still wish I could easily reset it anyway...

    https://discussions.agilebits.com/discussion/83779/muk-and-masterpassword-and-keysets-question#latest

  • AGAlumB
    AGAlumB
    1Password Alumni

    Bookmarks FTW! Totally. We have some ideas in this area, and intentionally designed 1Password.com to be flexible in this regard, but we don't have anything to announce at this time. Sorry for being so cagey, but talking about future plans and/or unreleased stuff is bad news for everyone :)

    But just to clarify, doing account recovery doesn't result in data loss, and even moving to a new vault/account can be done safely: copy the data over before deleting the old one. It isn't the end of the world, and frankly for someone with a legitimate concern that their vault/account has been compromised it's certainly worthwhile to do so. But hopefully we'll be able to offer an easier alternative in the future. It's just that anything involving encryption keys and user data needs to be handled carefully and tested thoroughly.

  • johannesauer
    johannesauer
    Community Member

    @jpgoldberg What I do not understand is the following:

    When I change my master password, only the master encryption/hmac keys are reencrypted, not the data itself - right? This makes it easier/faster/convenient to change the master password. But since the security of a my data is never stronger than my weakest master password I ever used (see argumentation above) - why should I ever change it? It can only get weaker, not stronger.

  • johannesauer
    johannesauer
    Community Member
    edited November 2018

  • @johannesauer I would think, depending on the password, of course, it could only stay the same... (assuming, of course, all other master passwords were stronger than your first. Mine are.).

    As for reasons to change it, too many to count. I for one sometimes type it into the user id field at work. I have access to SumoLogic. I then go on a search and see if it (moron that I was just now) shows up in the cloud-based logging so many have access to use.

    I started with a weak password, but cannot easily make it stronger now it seems (individual account). Or at least it isn't clear to me. Secret Key helps here, but psychologically I would love to redo that.

  • jpgoldberg
    jpgoldberg
    1Password Alumni

    This is a very important observation by @johannesauer:

    When I change my master password, only the master encryption/hmac keys are reencrypted, not the data itself - right? This makes it easier/faster/convenient to change the master password. But since the security of a my data is never stronger than my weakest master password I ever used (see argumentation above) - why should I ever change it? It can only get weaker, not stronger.

    And @AlwaysSortaCurious provides a couple of answers. In particular if your newer passwords are always at least as strong as your older ones, then you aren't doing damage, but you gain some benefits if there is reason to suspect that that an old MP has been compromised.

    For an attacker to make use of this, they would need to have a copy of the right part of old data and also the right parts of new data. It is possible for them to have this, but it takes work and preparation. If someone got your data from off of your machine they wouldn't be able to simply try your old Master Passwords. They would need to try the old ones against old data, then extract the right keys, and then apply those keys to the newer data.

    Again, that is possible, and ideally we would like to be able to prevent these sorts of attacks. I should say that we are in good company here. Things like SSH key encryption and PGP key encryption face the same threats, as do other systems. (Things like Full Disk Encryption have the same issue, but in that case the attacker would need clones of the (relevant portions) of the old disk.)

    So there is some security value in changing your 1Password Master Password, especially if you change it to a stronger one. But there is little value in regular changes. Create a good Master Password and keep it.

    Peculiar semantics

    There are other cases where a 1Password Master Password doesn't behave in the same way as most of the passwords that you've dealt with. I gave a talk about this a few years back at PasswordsCon. Using a password for encryption (instead of for authentication). We can't really expect users to understand the subtle differences, so we need to work to make things have the security properties that people expect.

    Back in my 2014 talk I discussed an approach to doing this; but it turns out to be harder than we'd anticipated and so have not rolled it out. The idea is that on a Master Password change (or removing someone from a vault), A new key would be used for all new encryptions, while data that hasn't been touched would remain encrypted with the older key. This way the attacker who has old data and discovers the old MP cannot decrypt anything that has changed.

    The book keeping of which thing is encrypted with which key when we have a long chain of keys in the first place, just made this more than a bit of a struggle to implement. So we are left where we (and many others) are. And this is why we advise people to pick a good MP and stick with it.

This discussion has been closed.