Why only 2048 bits for account private keys?
Hi, AgileBits.
Could you share a little bit about the choice to use 2048-bit keys for an account’s private key? I thought 2048 was considered acceptable only for very short-term use with 3072 bits or higher recommended for longer term use.
Even 3072 bits seems to be estimated equivalent to only a 128-bit symmetric key. Wouldn’t that mean the security of vault items is significantly less than 256-bit since the vault key protecting them is protected only by 2048 bits?
I’m sure there’s something I’m missing. I’d just like to learn what it is.
Thanks!
1Password Version: 7.4.1
Extension Version: Not Provided
OS Version: OS X 10.14.6
Sync Type: Not Provided
Comments
-
I guess I’m thinking about scenarios where encrypted data is stolen from AgileBits servers possibly without anyone’s knowledge. Might it be possible for them to brute force entry if they kept the data and waited just a few years?
0 -
They would have to brute force the master password and the secret key. The attacker would have to get the correct master password and secret key at the exact same time.
They also did something (I read a while back) how they did something to help against brute force. Someone here can probably tell more about this.
0 -
First things first: we built 1Password so that it's flexible enough to make this type of change when needed (something that works well today won't necessarily work well tomorrow). Because of this, it will be reasonably straightforward to switch to RSA 3072 at some point in the future. But in summary, with current computing power, 2048 is still a reasonable choice (more on this later in this post).
I guess I’m thinking about scenarios where encrypted data is stolen from AgileBits servers possibly without anyone’s knowledge.
It's actually great that you brought up this point, as we built 1Password exactly with such an attack in mind. Should this ever happen, we wanted 1Password data to remain secure despite the attack.
Let's look at this type of attack more closely: if an attacker somehow managed to access your 1Password data, they would only get the encrypted blob (since 1Password data is end-to-end encrypted, only you as the legitimate owner of the data will have the capability to decrypt that data, because you are the only one with the keys). Among this encrypted data, the attacker will also get the encrypted private key, which is encrypted with a random AES 256 key. With current computing power, such a brute-force attack is unfeasible.
It is particularly unfeasible because this AES key derives not only from your Master Password, but also from your Secret Key. An attacker needs both in order to decrypt your 1Password data.
Related to key lenghts more specifically though, you might find this blog post interesting. It was written by our Chief Defender Against the Dark Arts some time ago, and I think it is very applicable to your question.
They also did something (I read a while back) how they did something to help against brute force.
We use two-secret key derivation for this. In summary, we derive two different keys, one for authentication, and one for encryption. And because both of these derive from both the Master Password and the Secret Key, a brute force attack against the Master Password alone won't be effective.
We also use 100,000 rounds of PBKDF2 as our hashing scheme. Perhaps this is also what you were referring to @prime?
0 -
Hey, @DanielP. Thanks for responding.
Among this encrypted data, the attacker will also get the encrypted private key, which is encrypted with a random AES 256 key. With current computing power, such a brute-force attack is unfeasible.
Yes but they won’t need to break that encryption, right? To get the contents of a vault they just need to break the encryption around the vault key which is encrypted with the public key using 2048-bit RSA. If they can use a brute force search to guess the private key then none of the master password, secret key, derived keys or AES wrapping would matter, right?
we built 1Password so that it's flexible enough to make this type of change when needed (something that works well today won't necessarily work well tomorrow). Because of this, it will be reasonably straightforward to switch to RSA 3072 at some point in the future.
I checked this out in the 1Password security white paper. Very elegant!
If that encrypted blob is taken from 1Password servers, though, AgileBits wouldn’t be able to upgrade the level of encryption on that copy after the fact, right? If I’m looking at this correctly then:
- Breaking a 2048-bit cipher is all that is needed to get at the vault contents
- And if 2048-bit becomes crackable within the next 5–10 years
- Then someone that managed to steal my encrypted blob off the server today could access the contents of my vault in 5–10 years and there’s no way AgileBits nor I could stop them (once they have that particular copy)
Does that sound right?
0 -
How're the bad guys gonna get past the combo fingerprint/retinal scan/face ID/DNA sample that replaced typed-in passwords 5 years back.
(Not just something you know and something you have, but the thing ONLY you are.)
0 -
Yes but they won’t need to break that encryption, right? To get the contents of a vault they just need to break the encryption around the vault key which is encrypted with the public key using 2048-bit RSA. If they can use a brute force search to guess the private key then none of the master password, secret key, derived keys or AES wrapping would matter, right?
Brute forcing is always an attack option that is available to you, so in this sense yes, you could just ignore everything else and just try every possible key combination. If you decide to go that way though, the question at this point becomes the feasibility of such an attack. I am not aware of a way to brute force RSA 2048 with current computing power, in the near future. Even the NIST guidelines currently recommend at least 2048 bits [1].
Should you be aware of ways to make such a brute force attack feasible against RSA 2048 with current computing power though, I would love to read more about it. Factorization is a very difficult mathematical problem: there are typically (much) easier ways to get into a system than a brute force attack against RSA.
If that encrypted blob is taken from 1Password servers, though, AgileBits wouldn’t be able to upgrade the level of encryption on that copy after the fact, right?
Correct. The copy that is now outside of our server cannot be upgraded.
If I’m looking at this correctly then:
- Breaking a 2048-bit cipher is all that is needed to get at the vault contents
You make this sound easy :P
- And if 2048-bit becomes crackable within the next 5–10 years
- Then someone that managed to steal my encrypted blob off the server today could access the contents of my vault in 5–10 years and there’s no way AgileBits nor I could stop them (once they have that particular copy)
Does that sound right?
Correct. May I ask what the specific threat model you have in mind is though? I would argue that, due to the nature of data stored inside 1Password, a lot of the Login items and Passwords inside it might be outdated in 10 years, and so the bigger threat would be someone getting that data and managing to decrypt it now.
Also, in case you become aware of a threat such as this, you could also argue that you have 10 years to update your passwords and make the stolen copy of the data useless at that point.
[1] - NIST Special Publication (SP) 800-57 Part 3, Rev. 1 - Recommendation for Key Management, Part 3: Application-Specific Key Management Guidance
0 -
Also, in case you become aware of a threat such as this, you could also argue that you have 10 years to update your passwords and make the stolen copy of the data useless at that point.
How would you know there’s a stolen copy?
0 -
To add to what DanielP mentioned: I think part of the point is that it doesn't necessarily matter if you know that there is a stolen copy. How many accounts do you have stored that you've had for 10 years and in that time the password hasn't changed? Obviously ideally if such a theft did occur you would know, so that you could change your passwords (especially critical ones) sooner than later, but even if that didn't happen... I can't say I have any accounts from 10 years ago that still have the same password.
Ben
0 -
Passwords can be changed, but I have notes with important info they can’t. Social security numbers are also in my 1Password, VIN numbers and they can be used to traced where I live (and yes, I hold my vehicles more than 10 years). I also have mortgage documents stored in 1Password when I bought my house.
0 -
-
May I ask what the specific threat model you have in mind is though?
Of course.
I’m thinking about organized crime using cybercrime-as-a-service, botnet computing resources and criminal-built clouds. Criminals with the ability to rent large amounts of computing power and hacking skill.
I’m thinking about the data breaches that happen every year affecting companies like Target, Yahoo and Equifax. In particular, breaches like the one LinkedIn suffered where it was 4 years before they discovered 100 million accounts had been disclosed.
And I’m thinking about how previously 1Password users’ data was spread over a number of places/accounts and mixed in with millions of non-1Password users’. Now with 1password.com providing sync service there’s just one place you need to hack in order to obtain the (encrypted) vaults of a number of users.
And I’m thinking about the nature of the data one could get if they put in the effort: bags of people’s secrets.
Brute forcing is always an attack option that is available to you, so in this sense yes, you could just ignore everything else and just try every possible key combination. If you decide to go that way though, the question at this point becomes the feasibility of such an attack. I am not aware of a way to brute force RSA 2048 with current computing power, in the near future. Even the NIST guidelines currently recommend at least 2048 bits [1].
Agreed. I also understand 2048-bit to be secure today. I feel very comfortable that my secrets are safe right now.
It’s that scenario where someone steals a copy of my vault today and waits a few years that I’m a little uncomfortable with.
I also use NIST’s SP 800-57 for guidance on key size and estimated protection period. The latest draft estimates the security of 2048-bit keys to be about equal to 112-bit symmetric keys (section 5.6.1.1, table 2). The document estimates the protection period for 112-bit keys ends in 2030 (section 5.6.3, table 4).
https://csrc.nist.gov/publications/detail/sp/800-57-part-1/rev-5/draft
You make this sound easy :P
Fair point. I agree it is not. But I also believe the tools to do this make it more and more accessible each year.
How many accounts do you have stored that you've had for 10 years and in that time the password hasn't changed?
I’ve only been a 1Password customer since 2012. There are about 1,300 items in my vault. There are 6 items that haven’t been changed since 2012. Some of them are still important like the backup codes for two-factor authentication on my Google account.
Moving forward just one year there are 34 items that haven’t been modified since that year including the login credentials for my AgileBits support account.
I am more technically capable and security aware than my friends and family. I know best practice is to rotate account passwords on a regular basis. Yet I still don’t do it thoroughly and consistently. I perceive the friction it takes to change credentials for 1,300 items regularly to be enough that I just don’t try to maintain that rotation.
Moving forward 2 years there are 119 items that haven’t been modified since that year (2014).
I would argue that, due to the nature of data stored inside 1Password, a lot of the Login items and Passwords inside it might be outdated in 10 years, and so the bigger threat would be someone getting that data and managing to decrypt it now.
I also agree the most important thing to do is to protect it now. And I feel great about 1Password’s ability to do that.
I also feel great that 1Password has me covered for the next several years.
But as a rule of thumb I generally look for any kind of stored document I want to protect to be safe for at least 20 years. That feels to me like a safe level of margin. And it seems like 1Password could have that margin if the private key size was just a little bit bigger (3072 or 4096 even).
Much of the contents of my vault could become outdated after 10 years. But it only takes 1 valuable document/account to cause a problem.
0 -
The 10-year mark was just an example time frame. Besides being very difficult to predict the time estimate of brute forcing an algorithm in general (since there are numerous parameters involved, some of which we don't know, or at the very least we don't know exactly how they will develop in the following years), you should not take that as a definitive value.
0 -
I’m thinking about organized crime using cybercrime-as-a-service, botnet computing resources and criminal-built clouds. Criminals with the ability to rent large amounts of computing power and hacking skill.
I think we have hit the nail on the head here. Certainly this is a possible scenario, but would switching to RSA-3072 cancel this threat for you? Surely you could then just say that the criminals will need just some more power, and we will be back at square one (I am playing devil's advocate here).
My problem with this is that if we do that switch now, there will be another user in a few weeks commenting about the same thing, and about why we are not using RSA 4096 instead. We could certainly just keep increasing this, but I don't think we should do it just for the sake of doing it, and only offer a perceived security benefit.
We definitely will have to do the switch one day or another (computing power will keep increasing after all), so please don't take this as "we don't want to do this". Indeed, as I mentioned some posts ago, we built 1Password so that changes such as these will be possible without a crazy amount of effort. I just think that if a cybercriminal organization is targeting you, and has ability to rent large amounts of computing power as you said, it will just rent some more. Remember, this is someone who really, really wants your secrets, not just valuable information in general.
I would also like to offer a different perspective on the calculations though. So far we have exclusively focused on time needed, but I would like to take a look at the cost involved in such an attack, which (especially in your scenario where the attacker is organized crime) is often more important than the time variable. The cost for such an attack can easily be in the millions of dollars (we ran a password-cracking competition last year, so while this is not strictly related to this, it offers some interesting calculations [1] [2]). Unless you are a high-value target, or if someone is targeting you specifically, you need to ask yourself whether your data is actually worth the money and effort put in by the attackers. Especially if they don't target you specifically, but are just on the lookout for useful stuff.
I’m thinking about the data breaches that happen every year affecting companies like Target, Yahoo and Equifax. In particular, breaches like the one LinkedIn suffered where it was 4 years before they discovered 100 million accounts had been disclosed.
Hang on though: those breaches hardly ever (or at least not that I know of) attacked the encryption of these services. Those breaches happened because data was not encrypted in the first place, or a machine was not properly secured and segregated, or an employee made a mistake, or because of social engineering, or malware etc. Encryption is usually the strongest link of the chain, it is much easier to attempt to break things in other ways.
[1] https://discussions.agilebits.com/discussion/comment/469944/#Comment_469944
[2] https://discussions.agilebits.com/discussion/comment/470503/#Comment_4705030 -
I'd like to add some additional (and controversial) thoughts that will make nobody happy.
We have inconsistent security levels. For some purposes we use a 256-bit level (our symmetric encryption is AES-256), while in other cases we use 2048-bit RSA keys (so close to 112 bit level), while our SRP DH group is a 4096 bits (so around 140 bit level).
All of this misalignment is an accident of history. Using RSA keys of 2048 was a combination of what was available at the time for web clients and key sizes in the database. 4096 group for SRP was the largest that didn't have a noticeable performance hit, and the 256 symmetric encryption was chosen for reasons discussed in Guess why we’re moving to 256-bit AES keys.
The next time we make major changes to these sorts of things we will seek more consistent alignment at at least at the 128 bit level. (Though there really isn't anything wrong with the 112 bit level we are at for RSA.) However some inconsistency will remain. We will keep symmetric encryption at 256 bits, even if the keys for those are protected at the 128 bit level. I don't want to commit to anything until we've actually build and tested things, but I foresee us moving all public key operations to either X25519 or P-256, which both have a security level of 128 bits (using 256-bit keys).
Please be patient. Whichever way we go, we have to manage the transition carefully. All 1Password clients will need to be able to cope with the new kinds of keys before any of them actually generate them.
0 -
I dont understand the technical aspects of such a thread but I do appreciate that there is this "give and take" on these forums.
0 -
Yes, thanks for the amount of time you’ve put in on this conversation @Ben and @DanielP. And the honest insight, @jpgoldberg.
I appreciate that AgileBits is willing to make time to talk with customers and to do so in public with a number of people watching. Taking on conversations like this in public certainly contributes to the confidence I have in your team.
0 -
Thank you @OutboundRadiographer! It's always a pleasure to have these discussions for us. We are all passionate about security here, so anytime you would like to discuss something, we are always here :)
0 -
certainly contributes to the confidence I have in your team.
This coupled with its Canadian roots makes it almost perfect ;).
0 -
Thank you :)
0 -
Thank you all for your support. There will be times when accidents of history and the pragmatics of how software does get developed mean that some aspects of design, while providing the security and privacy we want to provide, can be a bit messy. Our view is that if we are going to offer a security product to people then we have to be open and transparent about design and implementation decisions, even when they reveal some messiness.
I think that it also helps to make it clear that we understand the choices we make, whether we make them implicitly or explicitly. Misaligned security levels is a cryptographic hygiene issue. And its something that we've been wanted to clean up. 256 bit EC key pairs (giving us a 128 bit security level) will go a long way to doing so, but there are things that we need to do first, and these things take time.
Common code base to make all-client changes easier
One of the things we have been working on for well over a year is to provide a common code base for 1Password clients. Because of how 1Password works, pretty much all of the cryptography is in the software running on your local machines. For the most part, our server only sees encrypted blobs. So any change has to work in 1Password for iOS, 1Password for Mac, 1Password for Windows, 1Password for Android, 1Password X, 1Password web-app, the 1Password Command Line Utility, and the 1Password SCIM bridge. (The first two share a great deal of code with each other and so do the last two).
With more common code, we will be able to roll out features and improvements to all clients more quickly. This, as I like to say internally, also allows us to put all our bugs in one place1. Thus making them easier to prevent, spot, and fix. But this also posses some difficult choices with respect to cryptography. On the whole, it is best to use the cryptographic libraries that come with the platform native software development kits. For iOS and Mac, this means that for the underlying cryptographic primitives we should be using Apple's Security Framework and CommonCrypto while for Windows it means that we should be using Microsoft's Cryptographic API: Next Generation, and so on for different systems.
So we have to do some work to make some of the cryptographic functions in our common code actually be system dependent. On the the other hand, as cryptographic packages for Rust improve, we help might not have to rely so heavily OS native APIs. But we get some portions of FIPS-22 compliance for free by using the OS provided SDKs. So all of this helps illustrate the messiness of these kinds of choices. And many of the choices will be heavily influenced by what is practically and usably available at the time.
Anyway, this post all started out as a simple "thank you". But I kind of got carried away.
-
Anyone who claims that their software is completely bug free is either lying or shouldn't be in the business of offering software. We have to assume that there are and will be bugs that we don't yet know about. The trick is to (1) use a design that renders most (inevitable) bugs harmless; (2) reduces the introduction of bugs through various coding and development practices, (3) testing, testing, testing. ↩︎
-
We don't claim to be fully FIPS-2 compliant, but it is nice to be able to say that all of the underlying cryptographic implementations we use are. We also conform to the most significant parts of it in terms of algorithm choice and key sizes. One of the big problems with FIPS-2 compliance for implementations is that it freezes bugs. Because the implementation has to go through a very costly and time consuming certification process, and bugs later discovered in those implementations can't be fixed and still get the original certification. ↩︎
0 -
-
I enjoyed your getting carried away!
0 -
Me too. I love when Jeff expounds on 1Password's security model. :+1:
Ben
0
