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?

  • The second document references a blog post dated 2013. It might be out of date now. The first document might be out of date too. I think you would have to look at the source code to know for sure, but the 1Password client is not open source.
    – hft
    Dec 1, 2021 at 21:53
  • Probably they were using CBC mode and then appending an HMAC of the ciphertext (as explained in the second document you cited) for authentication... but probably they then decided it would be better to just use GCM, which already has authentication "built in." But, it will be hard to say for sure if they replaced all of their CBC mode stuff.
    – hft
    Dec 1, 2021 at 21:55
  • @hft Thanks, I think their white paper should be updated, it says they are using GCM.
    – JIE WANG
    Dec 1, 2021 at 22:05

2 Answers 2


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).

  • Thanks for the details. Have you ever considered using AES-GCM-SIV to mitigate possible (IV,key) pair reuse? Or even, forgot the fragile AES-GCM and use XChaCha20-Poly1305?
    – kelalaka
    Dec 3, 2021 at 15:45

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.

  • 1
    Why would they lie about using AES-GCM and then use AES-CBC?
    – user163495
    Dec 2, 2021 at 1:16
  • I never said they would. However, even assuming those were the only two possibilities (an assumption the asker implied, but which is not true): some companies have been known to claim they're using better security than they are, for marketing purposes. I have no reason to expect that's happening here, but I haven't disproved it
    – CBHacking
    Dec 2, 2021 at 1:49
  • Why would a company lie about using better security than they are? I mean, I understand claims of snakeoil manufacturers being outlandish, when all they have is an XOR, but there's no difference in using CBC over GCM.
    – user163495
    Dec 2, 2021 at 9:27
  • +1. With regard to AES-GCM being preferred over AES-CBC, see crypto.stackexchange.com/questions/52566/… for an interesting read on why the developers of TLS 1.3 chose to use AES-GCM exclusively in TLS 1.3.
    – mti2935
    Dec 8, 2021 at 14:27

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .