Company Blog

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!

LAFS Summit Next Week in San Francisco: Nov 11-13

The next LAFS summit starts next Monday, November 11!

  • Monday 11-Nov-2013 (afternoon only)
  • Tuesday 12-Nov 2013 (all day)
  • Wednesday 13-Nov-2013 (all day)

Where: The Mozilla SF Office, 2 Harrison (at Embarcadero)

Who: at least Brian and Daira, plus everyone else who can make it

We'll have drinks and snacks, wifi, and an online videochat going too. We'll also grab dinner together nearby each night. No RSVP needed; we hope you can join us!

LAFS Featured on EFF Tech Blog

The Electronic Frontier Foundation's tech blog has some lovely things to say about LAFS at S4. Snippet:

Tahoe's protections against third-party snooping and deletion have the kind of strong mathematical guarantees that reassure security experts that Tahoe-LAFS is well-defended against certain kinds of attack. That also means its privacy and resilience are not dependent on the good behaviour or policies of its operators

Read the full blog post for more details.

« Page 2 / 4 »