What algorithm does 1Password use for encryption, AES-GCM-256 or AES-CBC-256?

Question

I would like to know what encryption 1Password uses.

On the About the 1Password security model page, it says:

Your 1Password data is kept safe by AES-GCM-256 authenticated encryption. The data you entrust to 1Password is effectively impossible to decrypt.

But on the OPVault design page, it says:

The data – excluding the IV but including the prepended padding – is encrypted using AES in CBC mode with a 256-bit encryption key.

So I am confused: why is its encryption different on different pages? Which page is correct? Am I missing something?

Answer 1

I am Jeffrey Goldberg, Principal Security Architect at 1Password, and I am the primary author of both documents. Both documents are correct, but they reflect different data formats.

Throughout our history, we have had four distinct data formats, and the transition of one to the next has always involved some overlap, with active versions of 1Password often supporting the most recent two data formats.

OPVault: 2012 – 2022(?)

We introduced the OPVault format in late 2012, and it is still used by actively supported versions of 1Password in certain configurations. It is not common, and certainly not the default for anyone setting things up today, but it is still actively being used. It uses CBC wrapped in an Encrypt-then-MAC construction to provide authenticated encryption. At the time that OPVault was designed GCM mode was not officially available in the cryptographic libraries we used on all supported platforms, so we went with Encrypt-then-MAC around CBC.

1Password.com: 2015 –

In late 2015 we introduced the 1Password.com service. And that is what is documented in the white paper. At the time we developed that data encryption GCM was available in the standard libraries of all the platforms we were supporting, and so we were able to use that instead of the Encrypt-then-MAC construction.

Different roles

The formats are designed not only at different times (and so could be built differently), but were designed for different purposes. OPVault and its predecessors could only be used for sharing data within families and teams with great difficulty and a substantial risk of data corruption. It really wasn't meant for multi-user access to some shared items. OPVault was also designed (as was its immediate predecessor) for file-based syncing, leaving the user to manage the syncing (typically through Dropbox).

To resolve a large number of syncing problems and to allow for secure sharing of items along with other features, we launched our cloud-based service in early 2016 (Beta in late 2015). There are huge advantages in designing a synchronization service that is meant for 1Password data and designing the data format to go with it. In addition to sharing and management features, we could also wire in much more secure authentication and data transport than what people were using with Dropbox or other third party sync service.

We obviously couldn't force everyone who had been managing their own data syncing with OPVault (or its predecessor) into using the new service. But over time, we have changed the defaults for new set-up, and now just support OPVault in a sort of legacy mode.

When data formats are tied to the synchronization systems (as they must be) as well as to important capabilities, transitioning is slow process. We can't tell people "hey, your old data is unusable because we have a new shinier sync and sharing system." We have to give a lot of time for people to make the move. And so running the "new" system alongside OPVault for six or seven years is what you are seeing.

In either case, we have been offering authenticated encryption since late 2012, first with Encrypt-then-MAC and then with GCM. The predecessor to OPVault, Agile Keychain Format, used plain CBC, and it's only been in recent years that we have fully been able to move people off of that format (originally designed in 2007–8).

Answer 2

TL;DR: Almost certainly AES-GCM-256

1Password may nominally not be open source, but browser extensions are JS and thus readable (although minified JS is even nastier than the usual stuff). I took the 1Password browser extension from Firefox and unpacked it. In the file background/background.js, the case-insensitive string "CBC" occurs only twice, both as substrings of seemingly-random hex. The string "GCM" occurs 26 times, including:

• English text error messages such as "gcm: tag doesn't match"
• JS object names, i.mode.gcm={name:"gcm"... among a bunch of other references to encryption and decryption
• One case-sensitive use of "JWK_ALG_A256GCM", which is a constant in https://searchfox.org/mozilla-central/source/dom/crypto/WebCryptoCommon.h and maps to "A256GCM" which also appears
• Two case-sensitive uses of "AES-GCM", one for 128-bit and one for 256-bit (as in, $c={name:"AES-GCM",length:256})
• Six case-sensitive references to "nativeAesGcm"

If they were trying to be malicious, this kind of check would be wholly inadequate - lots of ways to obfuscate what JS is doing, and I didn't read nearly enough of the code (much less trace its execution) to ensure there wasn't something funny going on - but assuming they aren't being deliberately deceptive about their cipher choice it's pretty clearly AES-GCM. The exact bit strength is a bit more ambiguous, but only a bit; there are more references to 256-bit ciphers than 128-bit ciphers (e.g. 3x "A256GCM", 1x "A128GCM"), and it's what you'd expect from the docs.