by

Yesterday, a new messaging app called Zendo got some very favorable coverage from Tech Crunch. At the core of their sales pitch is the fact that they use one-time pads for encryption. With a few strong assumptions, namely that the pads are truly random and are only used once, it’s true that this scheme is “unbreakable” or more precisely that it offers information-theoretic guarantees that no eavesdropper can learn anything about the encrypted message. Zendo’s founder calls it a “crypto unicorn” and claims it is a game-changer in terms of security.

It isn’t. In this post I’ll explain why we don’t need (and shouldn’t want) to use one-time pads for a consumer secure-messaging app and why we should generally be wary of products like Zendo making grandiose claims about solving security problems through magic crypto.

The one-time pad is very old and is quite simple: the sender and receiver agree on a random key or “pad” K, which is as long as the message M to be sent, and then the sender transmits a ciphertext C = M ⊕ K. Because there is a possible value of K that would map C to every possible message M (of the given length, which is revealed), it’s easy to prove that no information about M can be obtained if an eavesdropper has no information about K. By contrast, with a stream cipher (one of two common types of symmetric cipher) the sender would transmit C = M ⊕ F(K) for some function F which takes a constant-sized key K and expands it to a “stream” of bytes as long as M. The function F is designed to produce output that appears completely random, but there’s always a chance that the function F will produce output with some statistical bias and this can leak information about the encrypted message M. This has happened with RC4 over the years to the point that it’s no longer recommended.

It’s important to keep in mind that there are hundreds of things that can go wrong in a secure messaging app, ranging from entropy failures to backdoored devices to malware. One risk, which is a relatively low-priority one, is that the ciphers or other symmetric primitives will be broken. Removing this reliance on secure symmetric primitives is all the one-time pad can get you in a perfect world. Professional cryptographers would mostly say this is not a risk worth worrying about: RC4 is almost 30 years old now, and despite it being “broken” practical attacks still require enormous amounts of ciphertext and would probably not affect security in a meaningful way if you deployed it in a messaging app.

Anyway, one might say that if Zendo have really figured out how to make one-time pads practical, it’s worth using them just to remove this remote risk of a symmetric primitive break. We don’t know exactly how Zendo works, as there is no source code or design documentation available. But there’s the critical thing: As apparently implemented by Zendo, and as would be likely to be implemented by any other mobile messaging app, the use of one-time pads does not remove the reliance on symmetric crypto primitives. There are three reasons for this:

Using one-time pads requires generating a lot of true random data and most mobile devices can’t do that. True randomness is very slow to generate for most devices without a special-purpose hardware RNG. As a result, in practice most personal computers and mobile devices have to “stretch” the limited amount of true randomness collected in an entropy pool like Linux’s /dev/urandom. This is done by by a cryptographic pseudorandom number generator, which is of course built using hash functions and is insecure if they’re broken. Zendo apparently uses Java SecureRandom. A reasonable choice, but not appropriate for generating one-time pads. In practice, most devices can’t afford to generate a truly-random one-time pad and use a pseudorandom one, which is equivalent security-wise and worse performance-wise than just having used a stream-cipher to begin with. We don’t have secure high-bandwidth channels for sharing one-time pads which don’t rely on symmetric cryptography. Before using the one-time pad, both users need to get a copy of it. With an app like Zendo, this requires an in-person meeting and taking a picture of a 2D barcode on the other person’s screen. The claim is that this “visual channel” cannot be eavesdropped on. This is a somewhat dubious claim-if anybody gets a picture of your screen during the exchange, they’ll be able to read all of your communication with that partner. It’s important to note that this is NOT a vulnerability for public-key verification using 2D barcodes as many other apps use, an attacker observing this process can’t break your security, so Zendo’s design seems to introduce a new vulnerability here. Anyway, even assuming this visual channel is secure, it’s not high-bandwidth enough to send a large amount of random data for one-time pads. What Zendo does under the hood is share an AES-256 key using the visual channel, then use this to encrypt the one-time pad data and send that electronically (not clear exactly which channel but this doesn’t really matter). So once again, this scheme depends inherently on a symmetric primitive (namely AES-256). If somebody can break AES, they can eavesdrop on the one-time pad exchange. One-time pads don’t assure integrity. It’s easy to flip bits in a transmitted ciphertext which was encrypted using a one-time pad (or stream cipher),which will result in the recipient decoding a message with the corresponding bits also flipped. Preventing this requires a MAC function, and the Zendo developers used the standard HMAC (they didn’t say which hash function but SHA-256 is a safe guess). Again a reasonable choice, only this is yet another symmetric primitive that can compromise security if broken. Unlike the first two issues, this is actually not a fundamental problem, just a classic design error often found in amateur-hour cryptography. One-time MACs exist and they are acceptably efficient, they’re just rarely used because eliminating reliance on symmetric primitives is usually not a design goal.

So, don’t believe the hype on Zendo and, in general, ignore any app claiming to use one-time pads. Problems 1 and 2 above are quite hard to address without relying on good symmetric crypto (as Zendo definitively does) at which point there’s no security advantage to using a one-time pad. There’s a reason why you rarely see one-time pads used or even mentioned-professional cryptographers know they aren’t actually adding any security value. They are cloak-and-dagger stuff for a reason, making sense if a spy needs to quickly dead drop a large amount of key material and then wants an encryption algorithm so simple it can be performed on pencil and paper.

In general, crypto primitives are not the first thing consumers should be worried about when choosing an encryption app. More important are a clear and properly-documented crypto design that has been subject to independent review, source code available for review, regular audits for implementation security, forward secrecy and a usable way to verify communication partner’s identities. These are the basic elements highlighted in the EFF’s Secure Messaging Scorecard. As Edward Snowden said “crypto works.” We don’t need crypto unicorns so much as we need diligent engineering to deploy the crypto we already have.

More broadly, there is an increasing amount of snake oil in the secure messaging space (some of which has been debunked here before). One-time pads are a classic warning sign, but I’d propose as an even more general rule of thumb:

If a new crypto tool is first announced in a press release or popular science magazine, don’t use it.

Security and crypto are hard to get right, as everybody in the field painfully knows. New projects which are designed by people with sufficient expertise and experience are almost always circulated on mailing lists, have design docs and code distributed, or have academic papers published for a long time to get sufficient review before they go to the press or encourage real users to sign up. Compare Zendo’s launch to that of Pond, which has been in development for years without any publicity outside of the security community and with active warnings that it isn’t advisable to use it yet because it hasn’t received enough security review. It’s possible a brilliant stealth-mode app could launch with marketing first and security details and review later, but this almost always is a sign that the developers don’t understand how reliable crypto tools come into existence.