1Password 3 and OpenSSL

WndChill

This is an excerpt from AgileBit's recent email message regarding the Heartbleed bug: "1Password does not rely on OpenSSL to secure your data. Your data in 1Password is protected using Authenticated AES 256-bit encryption and can only be unlocked with your Master Password."

This is an excerpt from the FAQs for 1Password 3: "We know how complex encryption can be and so we decided to leave it to the experts instead of inventing our own. 1Password does not contain a single line of encryption code; instead we used OpenSSL, which is shipped with over 20 million Macs and is the standard used by most of the Internet. In addition to its huge user base, OpenSSL is open source. This is critical. It means that experts from around the world can view the code and ensure it is correct and does not contain any back doors. The size of the community and open nature of OpenSSL, combined with the state of the art encryption algorithm, makes 1Password’s encryption incredibly secure and reliable."

That is confusing to say the least. Was the email message intended to apply only to 1Password 4 and not 1Password 3?

Megan

Hi @WndChill‌

Thanks for checking in here, and I sincerely apologize for the confusion. You're right, 1Password 3 did use OpenSSL, but Heartbleed exploited the heartbeat extension in OpenSSL, and no version of 1Password ever relied on that.

If you have any further questions, I'll ask our security guru ( @jpgoldberg‌ ) to pop in here with some details. The short version though is that there is no vulnerability in 1Password's encryption as a result of this bug.

jpgoldberg

Hi @WndChill‌!

Just to elaborate at what @Megan‌ said:

In the distant past, 1Password 3 did use OpenSSL for much of its cryptography, but that was phased out as CommonCrypto provided more tools and we could rely less on OpenSSL for certain cryptographic functions, none of which would have had anything to do with Heartbleed (Or TLS heartbeats) anyway.

Some history

As a historical note our move from OpenSSL to CommonCrypto really picked up steam when we started developing 1Password for iPhone. Building in the OpenSSL libraries for iOS was adding more development and deployment complexity. At the same time, CommonCrypto was becoming more capable. A purely bureaucratic advantage of using CommonCrypto is that if we only used the cryptographic tools provided by the operating system, we can avoid having to apply for any sort of export control exemptions. It's automatic. But the real clincher was when Apple introduced AES hardware acceleration into iOS devices. 1Password 4 does things that could not be done otherwise. Once CommonCrypto was able to provide all of our cryptographic needs, we stopped using OpenSSL entirely. This happened during the 1Password 3 days.

99.9% of the OpenSSL functions are just fine

OpenSSL is an enormous cryptographic library. For example 1Password 4 (beta) for Windows uses OpenSSL for its PBKDF2 implementation. Heartbleed has no impact on it. Only if you are using OpenSSL to control an SSL connection. That happens to be most web servers, but it is not the case for the zillions of other uses of OpenSSL.

By analogy, when Bayer recalled some disposable tubing used for some of their pumps, it didn't make use of Bayer aspirin unsafe.

Should the world be looking beyond OpenSSL?

Now whether this bug reflects a more fundamental problem with OpenSSL development is a separate question. I would say that no single bug (unless it were malicious, and this doesn't look like that) should really do that. I do think that it would be good to see more diversity of cryptographic libraries used generally and in SSL/TLS servers.

It's sort of a historical accident that OpenSSL became dominant open source cryptographic library, and I'd love to something like Cryptlib more widely deployed.

More history

I've previously alluded to the Crypto Wars of the 1990s. OpenSSL has its origins from then. Netscape (the company) produce (one of) the first SSL web servers. But as a US company developing their products in the US the were subject to US cryptographic export restrictions. And so their servers and browsers (Netscape Navigator) could only use 40 bit symmetric keys (well only 40 bits of the longer keys could be random) in any product they exported from the US. I'd say that these export restrictions killed off Netscape Inc. (The blink tag is a close second. ;-)

SSLeay, the ancestor of OpenSSL, was developed primarily in New Zealand and not subject to these export restrictions. Cryptlib is also a product of New Zealand.

I really can't recall why OpenSSL took off while Cryptlib didn't, despite the fact that, in (not just) my opinion, Cryptlib appears to be programmed in a more robust style. I suspect it was because for some reason it was easier to integrate with Apache/NCSA web server at the time. That integration may simply have been better documented at the time.

But I do know that we (where I worked in the UK at the time) and thousands like us started to use Apache/NCSA with OpenSSL/SSLeay in the mid to late 90s.

WndChill

Thank you for the explanation.

Jasper

On behalf of jpgoldberg, you're welcome. Please let us know if you have any other questions! :)