Articles by Zooko Wilcox-O'Hearn

Least Authority Performs Security Audit For Cryptocat

This is the second post in our series about security audits of Free and Open Source end-to-end encryption software. The first post in the series was about our security audit of SpiderOak's crypton project.

Our mission at LeastAuthority is to bring verifiable end-to-end security to everyone.

As part of that mission, in addition to operating the S4 simple secure storage service, we also perform security consulting. We LeastAuthoritarians have extensive experience in security and cryptography, and other companies sometimes ask us to analyze the security of their protocols and software.

We audited the widely-used Cryptocat encrypted chat program. This audit was funded by Open Technology Fund as part of their Red Team project to provide multiple professional security audits to Internet freedom projects.

What were the results?

We found several security issues in the version of Cryptocat that we examined (Cryptocat v2.1.15). For each one, we reported it to the Cryptocat developers, and they have either deployed a fix in a newer release of Cryptocat or else disabled the feature that has the vulnerability.

The complete list of the issues we found is at the end of this article, along with a link to the report document.

Unfortunately we didn't have time to examine all parts of Cryptocat that we wanted to. We concentrated on the “crypto-related” parts: key generation and key management, random number generation, encryption and decryption, authentication and integrity, and the new file transfer feature. Most of the issues that we found were in those areas.

Our report explains what parts of it we looked at most closely (this is called the "coverage" results of the audit).

parting thoughts

I would like to thank the Cryptocat project, led by Nadim Kobeissi, for their commitment to doing development in the open, inviting external review, and moving to address the issues we uncovered. This open development process is a good complement to Cryptocat's Free and Open Source publication of their code and their commitment to providing end-to-end security for their users.

On top of that, I'd like to thank Cryptocat for their unflagging focus on usability. Usability is a critical factor if we are going to succeed at bringing verifiable end-to-end security to everyone, and it is an area where we as a community and as a society need to improve.

Any questions?

If you have any questions about these results or the process, please contact us or the Cryptocat developers.

The next project we are auditing is GlobaLeaks, so stay tuned.

further reading

The full report: Report of Security Audit of Cryptocat

The post on the Cryptocat blog.

Tickets on the Cryptocat github issue tracker to track the status of each issue:

BLAKE2: “Harder, Better, Faster, Stronger” Than MD5

best read while listening to Daft Punk: Harder, Better, Faster, Stronger

Why use BLAKE2 instead of Skein, Keccak (SHA-3), MD5, or SHA-1 as a secure hash function?

BLAKE was the best-rated hash function in the SHA-3 competition

NIST, in the final report of the SHA-3 competition, said this about the finalists (which included BLAKE, Keccak, Skein, and Grøstl):

  • BLAKE had a security margin — the gap between a known-weak reduced version and the full version — comparable to Keccak and superior to the other finalists. (§4.3: “BLAKE and Keccak have very large security margins.”)
  • BLAKE had a depth of analysis — the amount of published research analyzing its security — comparable to Grøstl and Skein and superior to the other finalists. (§3.1: “Keccak received a significant amount of cryptanalysis, although not quite the depth of analysis applied to BLAKE, Grøstl, or Skein”)
  • BLAKE had performance (in software) comparable to Skein and superior to the other finalists. (§5.1.4: “Skein and BLAKE […] have the best overall software performance.”)

but BLAKE was similar to SHA-2

So if BLAKE was in the top tier in all three of these measures, why didn't NIST choose BLAKE to be the winner of the SHA-3 contest? The main reason is given in §3.4 of the final report: because BLAKE's design was similar to SHA-2's.

When the SHA-3 project was announced, being like SHA-2 was explicitly listed as an undesirable property. That made sense at the time, but today, being like SHA-2 should increase your confidence in a hash function's security. Here's why:

When the SHA-3 project was announced (in 2007), MD5 and (to a lesser extent) SHA-1 had just been shockingly revealed to be weak, by a previously-unknown cryptographer from China, Xiaoyun Wang. There was a general fear among cryptographers that SHA-2 might be next. SHA-2's design is like that of SHA-1 and MD5. SHA-2 was still relatively new (having been published in 2002) and was not yet widely used compared to MD5 or SHA-1. This was actually the impetus for launching the SHA-3 competition: to have a new hash function ready in case SHA-2 was suddenly shown to be unsafe. At the same time, NIST advised everyone to transition from MD5 and SHA-1 to SHA-2 immediately, instead of waiting for the eventual standardization of SHA-3.

This explains why it was a design criterion for SHA-3 candidates to be different from SHA-2: because the purpose of SHA-3 was to be available as a fallback in case SHA-2 failed!

but being similar to SHA-2 is good!

Now, however, another seven years have gone by, and further efforts by cryptographers to analyze SHA-2 have not found any way to defeat it. This means that SHA-2 is now twelve years old, and during most of that time it has been the most widely recommended secure hash function in the world. So today, the fact that BLAKE has a few design elements in common with SHA-2 doesn't seem to reflect badly on BLAKE at all.

BLAKE compares well to the modern hash functions Keccak and Skein. There is good reason to think that it is secure, and it has better performance (in software, on Intel or ARM CPUs) than Keccak. However, the other two are also good—there is no reason to suspect any of them of any weakness.

BLAKE2 is faster than MD5

Okay, so what is BLAKE2 then? Well, after NIST settled on Keccak to be the winner of the SHA-3 contest, Jean-Philippe Aumasson, Samuel Neves, Christian Winnerlein, and I decided that what the world needed was not just a secure hash function that was faster than Keccak, but one that was faster than MD5! This is because MD5 (and SHA-1) continue to be very widely used, even in new applications, even though MD5 and SHA-1 are unsafe for many uses. We hypothesized that offering engineers a hash function that was both faster and more secure than their beloved MD5 or SHA-1 might be more effective than haranguing them to upgrade to an alternative that is more secure but slower.

So, we took BLAKE (Jean-Philippe Aumasson had been one of the designers of BLAKE), traded-off a little of its generous security margin in return for more efficiency, and optimized it to produce BLAKE2, which is faster than MD5 (on a modern Intel CPU). On top of that, we added an optional parallel mode so that if you have 4 or 8 CPU cores available you can run your BLAKE2 function almost 4 or 8 times as fast.

Bottom line:

  • MD5 and SHA-1 are not responsible choices for a secure hash function today [*].
  • Keccak (SHA-3), Skein, and BLAKE2 are all reasonable choices.
  • BLAKE2 is not only faster than the other good hash functions, it is even faster than MD5 or SHA-1 (on modern Intel CPUs).

Further reading:

Here are the slides from a presentation that I gave about BLAKE2 at “Applied Cryptography and Network Security 2013”.

Here is an essay I posted in April 13, 2012 and updated in October 3, 2012, which outlines the motivation for what later became BLAKE2.

[*]Some software, notably git, is still using SHA-1, and relying on the fact that the best publicly-known method of generating SHA-1 collisions costs 2⁶⁹ computations, which is expensive. I think it is unwise to rely on this for two reasons. One is that there could be more efficient techniques to compute SHA-1 collisions that we don't know about. Another is that the cost of doing 2⁶⁹ computations is falling rapidly—at the time of this writing (March 22, 2014), the Bitcoin network is performing enough computation to generate SHA-1 collisions every 131 minutes!

P.S. this isn't about hashing passwords

P.S. Secure hash functions are not for hashing passwords! Secure hash functions are building blocks in cryptographic protocols and they should be as efficient as possible while still being secure. Password-hashing functions are for impeding brute force guessing of passwords, and they should be as inefficient as possible while still being usable. See "scrypt" and "bcrypt" for current password-hashing functions, and see the Password Hashing Competition for some candidate next-generation ones.

By the way, some of the entrants in the Password Hashing Competition use BLAKE2 as an internal building block in their algorithm. They presumably chose it because it is fast, and then their design forces the computer to calculate BLAKE2 many, many times, iteratively, in order to be slow again. This actually makes sense. ☺

Acknowledgments: Thanks to an anonymous reviewer, Jean-Philippe Aumasson, Daira Hopwood, and Amber Wilcox-O'Hearn for comments on earlier drafts of this post. I'm solely responsible for any errors.

Least Authority Performs Security Audit For SpiderOak

Our mission at LeastAuthority is to bring verifiable end-to-end security to everyone.

As part of that mission, in addition to operating the S4 simple secure storage service, we also run a security consulting business. We LeastAuthoritarians have extensive experience in security and cryptography, and other companies pay us to analyze the security of their protocols and software.

Almost all of our consulting clients are making Free and Open Source software which protects user freedoms and works against censorship. It is wonderful that in this day and age we can get paid to work on software in the public interest.

One of our clients is SpiderOak, a company who, like LeastAuthority, sells cloud storage with end-to-end encryption. They didn't hire us to evaluate the security of their current storage product (that would be a big job!), but instead to do a limited, two-week long, security audit of their new framework.

It was a fun project because we got to learn some of the details of the design and implementation. We came away with a favorable impression of the professionalism and good engineering practices of the SpiderOak team. is all Free and Open Source software, and it is designed for real, end-to-end security, which is part of why we wanted to take the job.

Today SpiderOak has published the security auditing report. We'd like to thank them for producing, subjecting it to this kind of independent review, and publishing the complete results. That's the right way to do things!

The next security audit that we performed, was for the Cryptocat secure chat app. We expect the report from that to also be published soon. Stay tuned!

Open Letter to Phil Zimmermann and Jon Callas of Silent Circle, On The Closure of the “Silent Mail” Service

This open letter is in response to the recent shutdown of Lavabit , the ensuing shutdown of Silent Circle's “Silent Mail” product, Jon Callas's posts about the topic on G+, and Phil Zimmermann's interview in Forbes. Also, of course, all of this is unfolding in the context of the 2013 Mass Surveillance Scandal.

Dear Phil and Jon: Hello there! It is good to have a chance to chat with you in public.

Please accept the following in the spirit of constructive criticism in which it is intended.

For those readers who don't know, I've known you both, personally and professionally for decades. You've each written texts that I've learned from, inspired me to follow your example, we've worked together successfully, and you've mentored me. I have great respect for your technical abilities, your integrity, and your general reasonableness. Thank you for all of that and for holding fast to your principles today, when we need it more than ever.


Your job is not yet done. Your customers are currently vulnerable to having all of their communications secretly monitored.

I just subscribed to the service at, and after I paid $120 for one year of service, it directed me to install the Silent Text app from Silent Circle on my android phone, which I did. Now, when I use that Silent Circle app to send text messages to other Silent Circle customers, I have no way of verifying whether it is really encrypting my message on my own phone, and if it is really keeping the encryption key only for me, or if it is leaking the contents of my messages or my encryption keys to you or to others.

If some attacker, for example the U.S. Federal Government — or to pick a different example the Zetas Mexican drug cartel — were to coerce Silent Circle into cooperating with them, then that attacker would simply require Silent Circle to distribute an update to the app, containing a backdoor.

There is no way for me to verify that any given version of Silent Text, including the one that I just installed, is correctly generating strong encryption keys and is protecting those keys instead of leaking them.

Therefore, how are your current products any safer for your users that the canceled Silent Mail product was? The only attacker against whom your canceled Silent Mail product was vulnerable but against whom your current products are safe is an attacker who would require you to backdoor your server software but who wouldn't require you to backdoor your client software.

Does that constraint apply to the U.S. Federal Government entities who are responsible for PRISM, for the shut-down of Lavabit, and so much else? No, that constraint does not apply to them. This was demonstrated in the Hushmail case in which the U.S. DEA asked Hushmail (a Canadian company) to turn over the plaintext of the email of one of its customers. Hushmail complied, shipping a set of CDs to the DEA containing the customer's messages.

The President of Hushmail emphasized in interviews with journalists at the time that Hushmail would be able to comply with such orders regardless of whether the customer used Hushmail's “client-to-server” (SSL) encryption or its “end-to-end” (Java applet) encryption.

Phil had been Chief Cryptographer of Hushmail years earlier, and was still a member of the Advisory Board of Hushmail at the time of that case. He commented about the case at that time, and he also stated, correctly, that the Hushmail model of unverified end-to-end encryption was vulnerable to government coercion. That's the same model that Silent Circle uses today.

You have just taken the courageous act of publicly shutting down the Silent Mail product, and publicly stating your reasons for doing so. This, then, is your opportunity to make your stance consistent by informing your customers of the similar dangers posed by the software distribution practices currently used by Silent Circle (along with most of the rest of the industry).

I don't know the perfect solution to the problem of the unverifiability of today's software. But being frank about the current approach and the vulnerability that it imposes on users is the first step. People will listen to you about this, now. Let's start talking about it and we can start finding solutions.

Also, warn your users. Don't tell them the untruth that it is impossible for you to eavesdrop on their communications even if you try (as your company seems to be on the borderline of doing in public statements like these: [ ¹, ²]).

We're trying an approach to this problem, here at, of “verifiable end-to-end security”. For our data backup and storage service, all of the software is Free and Open Source, and it is distributed through channels which are out of our direct control, such as Debian and Ubuntu. Of course this approach is not perfectly secure — it doesn't guarantee that a state-level actor cannot backdoor our customers. But it does guarantee that we cannot backdoor our customers.

This currently imposes inconvenience on our customers, and I'm not saying it is the perfect solution, but it shows that there is more than one way to go at this problem.

Thank you for your attention to these important matter, and your leadership in speaking out about them.

(By the way, is not a competitor to Silent Circle. We don't offer voice, text, video, or email services, like Silent Circle does/did. What we offer is simply secure offsite backup, and a secure cloud storage API that people use to build other services.)


Zooko Wilcox-O'Hearn Announces A PRISM-Proof Storage Service today announced Simple Secure Storage Service (S4), a backup service that encrypts your files to protect them from the prying eyes of spies and criminals.

“People deserve privacy and security in the digital data that make up our daily lives.” said the company's founder and CEO, Zooko Wilcox-O'Hearn. “As an individual or a business, you shouldn't have to give up control over your data in order to get the benefits of cloud storage.”

Verifiable end-to-end security

The Simple Secure Storage Service offers verifiable end-to-end security.

It offers “end-to-end security” because all of the customer's data is encrypted locally — on the customer's own personal computer — before it is uploaded to the cloud. During its stay in the cloud, it cannot be decrypted by, nor by anyone else, without the decryption key which is held only by the customer.

S4 offers “verifiable end-to-end security” because all of the source code that makes up the Simple Secure Storage Service is published for everyone to see. Not only is the source code publicly visible, but it also comes with Free (Libre) and Open Source rights granted to the public allowing anyone to inspect the source code, experiment on it, alter it, and even to distribute their own version of it and to sell commercial services.

Wilcox-O'Hearn says “If you rely on closed-source, proprietary software, then you're just taking the vendor's word for it that it actually provides the end-to-end security that they claim. As the PRISM scandal shows, that claim is sometimes a lie.”

The web site of proudly states “We can never see your data, and you can always see our code.”.

Trusted by experts

The Simple Secure Storage Service is built on a technology named “Least-Authority File System (LAFS)”. LAFS has been studied and used by computer scientists, hackers, Free and Open Source software developers, activists, the U.S. Defense Advanced Research Projects Agency, and the U.S. National Security Agency.

The design has been published in a peer-reviewed scientific workshop: Wilcox-O'Hearn, Zooko, and Brian Warner. “Tahoe: the least-authority filesystem.” Proceedings of the 4th ACM international workshop on Storage security and survivability. ACM, 2008.

It has been cited in more than 50 scientific research papers, and has received plaudits from the U.S. Comprehensive National Cybersecurity Initiative, which stated: “Systems like Least-Authority File System are making these methods immediately usable for securely and availably storing files at rest; we propose that the methods be further reviewed, written up, and strongly evangelized as best practices in both government and industry.”

Dr. Richard Stallman, President of the Free Software Foundation said “Free/Libre software is software that the users control. If you use only free/libre software, you control your local computing — but using the Internet raises other issues of freedom and privacy, which many network services don't respect. The Simple Secure Storage Service is an example of a network service that does respect your freedom and privacy.”

Jacob Appelbaum, Tor project developer and WikiLeaks volunteer, said “LAFS's design acknowledges the importance of verifiable end-to-end security through cryptography, Free/Libre release of software and transparent, peer-reviewed system design.”

The LAFS software is already packaged in several widely-used operating systems such as Debian GNU/Linux and Ubuntu.

Page 1 / 1