Be wary of one-time pads and other crypto unicorns

So you have a bunch of what are effectively scientists who aren't all that familiar with how products get made (first build something, release it, then refine it over time through feedback) and you have a bunch of developers who aren't familiar with how security products are managed (you don't release anything until you're willing to put people's lives on your product).

What you're left with is an ecosystem of developers releasing code that's not cryptographically sound because they need feedback and a community to help them refine the software, and crypto scientists who scream bloody murder every time they find a bug because, "what if the next Snowden uses your new tool!?!"

Everyone's right in this argument, it's just hard to bridge the gap between these two very different schools of thought.

>... The first step is always optical, and that is an exchange of an AES 256bit key, plus an authentication key, and so those are the keys to encrypt the One-time pad as it’s being transferred ...

This software does not use one-time pad. It uses AES-256 with some extra hoops. Authors are either incompetent, thinking that having message-sized chunk of random data somewhere during encryption is 'one-time pad', or dishonest, using 'one-time pad' as empty buzzword. Both are huge red flags against using that software

In other words they are hyping and trying to sell people something that is at best equally secure to current things and more likely less secure.

If, as the article says, the QR code gives a symmetric AES key, then yes it could well be enough to get the OTP if you've eavesdropped on the traffic as well.

>> But there is no discussion of these points so far. Everybody is just piling hate on the product for its failings. We need to be better than that if we want a secure app ecosystem.

What we need to be better at is recognising that "Hey, look at my brand-new awesome crypto-system!" is a huge red flag, and what we should be looking for is "Hey, we're using tried and tested protocol X, which we're pretty confident about".

From an app-writer's perspective I can see why they want to announce that they've made this awesome new security system - they want to differentiate themselves, and security is in the public eye right now so seems to be a selling point. Human nature being what it is, new and shiny is eye-catching and good for sales. But we really want pretty much the opposite here.

People that want to do the latter should go out of their way to avoid appearing to be the former, not call up Techcrunch to show off their unicorn.

That is what the team at Ionic Security* is doing. With about 50 open engineering positions we are hiring :)

My email is adam at our domain.

* I'm the founder/CTO

The actual problems here are that the claims made by Zendo are 1) pointless and 2) impossible. They're pointless because one-time pads offer zero real-world security benefit over a modern symmetric cipher. They're impossible because there's no way to securely generate and share a one-time pad the way they're saying.

For example, you say the QR code is used to initiate a direct, encrypted wireless connection. Encrypted how, exactly? With a symmetric cipher! Either a symmetric cipher is good enough to keep things secret, in which case the one-time pad is pointless, or a symmetric cipher is not good enough to keep things secret, in which case the one-time pad is compromised in flight.

If you want to make security a core feature and not get criticized, all you have to do is get your security right. If you want to get your security right, bring in a professional. Any crypto professional worth anything could have pointed out all these problems within five minutes of being given a summary of their design. They either didn't consult with a professional, or they did and ignored the advice.

Blog posts like this may not help bring about the security revolution you want, but they sure are helping to prevent a security disaster in the form of a bunch of completely broken programs leaking our info every which way while pretending to be secure.

If companies launched with a real crypto review, this wouldn't happen. On the flip side, most companies wouldn't launch at all because their product is simply inherently insecure. Or, it addresses a mostly useless threat model. For instance, it requires you to trust their server while claiming to be super duper secret.

Even Silent Circle, which touts some famous names, talks up their secure PSTN service which is so obviously interceptable it's bizarre to make any security claim at all.

The problem with crypto your mum can use is that key management is a pain in the ass. And if users don't verify and maintain their own keys, most systems are useless against strong threats. zRTP is the closest thing to great, because there's a simple in-but-out-of-band key verification system built in.

And if you day your mum doesn't need that much security, she just doesn't wanna be in a dragnet or have her ISP read her email, then choosing, say, Gmail, and emailing other users with TLS-enabled SMTP servers gets her pretty damn far (if SMTP actually verified certs). But that's not a very sexy product, is it? (Despite being what many corporations do -- configure explicit SMTP-TLS policies.)

For instance, a messaging protocol that authenticates its participants can be strongly privacy-preserving for the initiator or recipient, but as far as we know, not both. One side can initiate the connection anonymously, but at some point one or the other must identify themselves before the other.

Another issue is that crypto is not, and may never be, at the point where anyone can securely assemble a protocol from raw primitives (e.g., AES or SHA-2) without specialized knowledge. These primitives provide security features that are well-defined mathematically, but that definition may not map well to intuitive real-world security properties. As an example, a one-time pad done correctly is information-theoretically secure. But it's trivial to tamper with, because there's no authentication of the message. AES-CBC has the property of indistinguishability under chosen-plaintext (IND-CPA) and chosen-ciphertext (IND-CCA1) attacks, both of which are considered necessary properties for a block cipher to be secure. For a long time, we though this was good enough. Unfortunately, IND-CCA1 didn't model adaptive chosen-ciphertext attacks, where an attacker uses the outcome of previous decryption attempts on chosen ciphertexts to influence his next choice of ciphertext to submit for decryption. Authenticated modes provide indistinguishability under adaptive chosen-ciphertext attacks (IND-CCA2), but unauthenticated modes like CBC remain popular (they do still have their use, but you need to understand what the risks and tradeoffs are before using an unauthenticated mode like CBC).

We likewise don't know of a good, user-friendly way to authenticate identities without the use of a central authority (à la certificate authorities) or a web of trust (à la GPG). Both suck. With CA-style authentication, if a CA is compromised, you lose many of the security guarantees. This is perhaps good enough for e-commerce, where governments typically have little incentive to steal credit card numbers, but it's potentially catastrophic for communication between political dissidents. A web of trust is perhaps better for this kind of use-case, but nobody knows how to make the process of bootstrapping the web of trust simple, the decision of who to trust is inherently complicated (Alice trusts Bob and Carol, who both sort of know Dave who vouches for Eve implicitly; how should Alice feel about Eve?). You can hide that complication at the cost of decreasing the utility (trust conservatively) or increasing the risk (trust liberally). Or you can expose that complexity and let individuals weigh the risks themselves.

The more of these decisions and choices you hide from the user, the more user-friendly you can make your system. But the cost is control over exactly whom and how you trust. Unfortunately, if you build one easy-to-use system for people to securely share cat photos and one hard-to-use system for political dissidents, it's easy to identify the political dissidents.

Anyone who solves this problem deserves a fucking Nobel.

> The real problem is that the entire OSI stack is a leaking piece of crap.

How is breaking into your computer an issue of the OSI stack? Are you using "OSI stack" as synonymous to "the whole operating system with all its running processes"?

A good private key encryption scheme doesn't have that limitation. That makes it better than a one-time pad for most practical situations.

Homomorphic encryption is still very much an emerging tech. For most applications it's still too slow. There's all sorts of cool things we can build when it gets a bit more mature, but for now it's not unreasonable that there's no press coverage of it.

On secure obfuscation - there was actually a wired article about this (unsurprisingly the title was rather overhyped and click-baity), so I don't think it's fair to say it didn't get press coverage. This is closer to being usable in the real world and thus got more press coverage. Again though, it seems unfair to complain about the amount of coverage it got, because regular readership can't go out and use it yet.

The problem IMO is more that there's a conflict between the big splashy software release that gets you lots of users and attention, and the slow careful discussions on crypto lists that gets you more confidence your software is actually secure before it's in the hands of end users.

Without the big release, it can be hard to build a user-base - and if no-one uses your new more-secure messaging app it doesn't really do a lot of good. Without the slow discussions you're potentially endangering your users. Some sort of compromise is probably the answer, but I'm not sure exactly what that should look like (although I have some ideas).

If you're not using Sodium/Nacl, don't go out of your way to use Salsa/ChaCha/Poly1305. If your platform has a good AES-GCM, that's also fine.

The important thing is to use the best tested, simplest interface available to you. If switching from AES to ChaCha means you have to do any of your own protocol design, it's not a win.

It amounts to basically the same thing. That's the point there, what's happening in the phone is a small amount of random data is being used to generate a large amount of pseudo-random data. The security of the OTP is therefore dependent upon the PRNG and in effect you are using the PRNG as your stream-cipher. It doesn't buy you anything.

>> So you would need to be in the room to eavesdrop. So the transport mechanism they choose there is a little bit less of a risk I think.

With other schemes that use similar things, the exchange is of public keys. Zendo appears to use the barcode as a symmetric key, meaning that the transfer can be eavesdropped/intercepted/impersonated a bit more easily. In an asymmetric situation you could encrypt all messages with the receiver's public key and ensure only they can decrypt.

>> Their 3rd point also doesn't seem to be that big enough of a deal to warrant the tone...

This is more of a criticism of style, and how little they have disclosed.

One time pads need to be large enough to encompass the size of all communications which are encrypted by them. Encryption keys need to be a couple k in size at most.

For 2 and 3, basically the author is stating that the use of a one time pad is redundant at best, and potentially crippling at worst (since the capture of a copy of the OTP compromises all communications, backwards and forwards, and it would be tempting to re-use the OTP instead of constantly having to meet back up and generate a new one).

2. It's a key exchange that can be attacked with a video recorder and, more importantly to this analysis, that depends on AES. There is no point in using a one time pad whose key is encrypted with AES; you might as well eliminate the added risks of a one time pad and just use AES.

3. Integrity failures in cryptosystems tend to produce confidentiality failures. For instance, error oracle attacks depend on attackers injecting bogus messages and observing behavior. You can't have confidential message encryption without message integrity.

That probably isn't the case, there will always be tons of situations overlooked where you already know or have a good guess about what the plaintext of a message looks like and then you can change that section of plaintext to whatever you want, for instance, in a contrived example, lets say that there's some hypothetical messaging app that starts every ordinary message between two users with a header consisting of some fixed bytes and some predictable bytes at the beginning like an account id or something like that. I, the attacker, can replace any known plaintext I want with any other plaintext relatively easily. This might mean replacing the message header with a different one that means, my OTP is empty, resend a OTP encrypted with AES key "password1".

Obviously a vulnerability won't be that simple but there is a good chance that there's something like that where an attacker can compromise our hypothetical OTP app by being able to change any plaintext he already knows. For instance, you can XOR the message text with 0x20 and you'll probably corrupt a lot of punctuation and spaces but that would invert the case of the entire message.