moxie

I'm not really positioning TextSecure as a secure mail solution, but this article says that the TextSecure protocol can't support asynchronous operations or federated namespaces. To clarify, that's incorrect, the TextSecure protocol was actually designed from the ground up for asynchronous communication, and is designed to support a federated namespace: https://whispersystems.org/blog/asynchronous-security/

That leaves these points for PGP:

> It’s been around for a long time, so it’s cryptographically well understood.

Yes, but it's cryptographically well understood not to provide the properties we need.

> There are a variety of implementations and there is a small but vibrant and highly committed developer community. > A small but active and committed user community.

Small can't be emphasized enough, and this is the most important part to me. I think people have a tendency to look at PGP and conclude that while it might be painful, we have to put up with it for backwards compatibility. The truth is that it's a protocol with few contemporary redeeming qualities, and an active user base of ~50k. So why bother with backwards compatibility?

I don't have a definite answer. There's the path we're executing on at Open Whisper Systems, but there are a bunch of other projects working in this area as well (Mailpile, LEAP, etc).

I think the problems are solvable, but only if we have a different design approach. So when I see projects trying not-PGP, I'm interested. When I see projects building on PGP, I'm less interested.

A lot of the comments I've been getting are in the genre of "well... but GPG works."

Yes, GPG is a powerful tool that makes some encrypted communication possible. But is it really "working" if it's the tool we've had for the past 20 years, and we still ended up in a world where surveillance is so ubiquitous and privacy is so rare? Having used GPG, it seems more likely to me that there are only ~50k GPG users in the world because of the product, not because of weak desire or need for private communication.

I'm not suggesting that there's anything "better," but that it's really sad there isn't. GPG isn't ever going to be anything other than what it is now, and I don't think that's the future we want for ourselves.

We could try to slap a GUI on top of it, but I don't believe great products are made that way. Good UX requires thinking about interactions all the way down to the protocol. The good news is that GPG has such a small legacy install base (literally on the order of ~50k users), that there's no reason to maintain compatibility with OpenPGP. When building new products, we can start fresh with modern cryptography, a modern protocol, and a modern design philosophy.

This 'WhisperSystems' account is not controlled by anyone associated with the Open Whisper Systems project. Whoever this is, please stop claiming to represent us.

Open Whisper Systems (https://whispersystems.org) - Bay Area - Full time - Lead iOS Developer and Lead Designer.

No security or cryptography background needed.

Open Whisper Systems is working to make private communication simple. Building well designed, free, and open source privacy products is the sole mission of Open Whisper Systems. We are not a business, which means we have no VC obligations, and no management to appease. Our technology is currently used by hundreds of millions of people.

Open Whisper Systems is looking for a lead iOS developer in the Bay Area to direct the continued development of our iOS client.

Open Whisper Systems is also looking for a lead designer in the Bay Area to shape the look and feel of our entire suite of applications.

We're looking for people with opinions, vision, self-direction, and responsibility. Substantial experience in the domain of iOS development or design is a must, but we are not looking for experience with security or cryptography.

The position is full time in San Francisco. We can help with relocation.

Interested? workwithus@whispersystems.org

I loved They Live before the pervert's guide to ideology, but you're right that this post is probably derivative of the latter. It's just a daily blog post that we're doing as part of Winter Break Of Code, and wasn't really "meant" for the front page of HN, so I'm surprised to see it in a place like this.

For what it's worth, I wasn't trying to write an analysis of They Live, and was just using it as a tongue-in-cheek back drop for a different question.

This is a great example of deceptive marketing at work. You can check out their API here:

https://core.telegram.org/methods#working-with-messages

...where's the encryption on message histories? There is none. If the data is encrypted server-side, it's with keys that live on the servers. In other words, the encryption provides no value and the servers are "trusted." The point of end to end encryption is not to have to trust servers.

There's been a lot of controversy over the Telegram encryption protocol. Any cryptographer that looks at it cringes, but Telegram has deep pockets and has done a decent job building hype.

Beyond doubts with the protocol itself, I think the more important consideration is that most people never use it. Telegram is not encrypted by default. Users have to create a special "secret chat" with contacts that is ephemeral, and some Telegram clients don't even support that mode. Last I checked, there was no way to have group "secret chats" in any client at all.

The result is a situation where many users seem to think that Telegram is somehow secure by default, when it definitely isn't. Telegram even stores plaintext copies of everyone's entire message history on the server for multi-device sync.

I think what Telegram is doing right now is dangerous, and potentially another Lavabit in the making. I'd like to see them incorporate a modern end to end encryption protocol, and enable it by default.

To be transparent, I work on TextSecure and am involved with the WhatsApp end-to-end encryption project.

IIRC they gave these out at the first Java One. You could program it with what kind of coffee you liked, and hold it up to the coffee machines there. At the time I worked at a company that also had a JavaStation (basically a SPARC that only ran Java).

We all thought the JVM was about to revolutionize client software development and break Microsoft (once everything ran on the JVM, MS wouldn't have an app ecosystem that tied us to them). Meanwhile, the browser was staring us right in the face, and it was server-side where the JVM blew up.

We've noticed that some people have problems when they do weird stuff to their phones. We use GCM for delivery, so that can stop working with a custom gapps install, or a rooted firewall setup, or disabled background data for gcm. We have yet to receive a report where GCM stops working for people with completely stock installs. If that doesn't describe you, please file a bug so that we can help get things working.

For what it's worth, TextSecure also has delivery receipts now, so the sender can see what's happening with their message.

At this point Google pretty much controls the future of web-oriented internet protocols, since they control the client in the form of Chrome, as well as the server in the form of Google properties. What they do is basically what goes.

People inside of Google were putting together HPKP at the same time that we were putting together TACK, so that was pretty much the end of TACK. HPKP is really simple for Google (just pin their own CA), but isn't as clean for most other major sites (who are stuck with many CAs). It also doesn't offer a layer of indirection away from CAs, which again, is not an issue for Google (they already have a layer of indirection in the form of their own CA), but is less ideal for the rest of us.

It's better than only being able to hardcode pins in the browser binary, but it's a shame that it doesn't take on some of the other pain that's come up with pinning.

I don't know what to say, except that you're right. This is the problem that Tor is trying to solve, which is why Tor gets to claim that it is "anonymous," and random websites or apps don't get to make that claim.

I don't think it's a deliberate violation of privacy to operate a website, but I do think that it's a violation to operate a normal website and call it "anonymous." Because, as you point out, it's not.

Not only does it confuse users in the immediate sense, but it poisons the well for everyone who is approaching the problems seriously in the long term.

Based on your own comments here, it sounds like the reporting is entirely accurate. You're attempting to justify why you're tracking your users, but you're still tracking them.

You've highlighted many of the hard problems in this space: how do you achieve anonymity and unlinkability while doing things like IP hiding, spam filtering, and relevance matching? The issue is that you haven't solved the problems, and are instead suggesting you should get a pass because the problems are hard. It seems simple to me: if you haven't designed something that gives you truly unlinkable anonymity, don't claim to provide it. If you have to track your users to make your app work, don't claim not to track your users.

There are projects like Tor that are approaching these types of problems seriously, but apps like Whisper or Secret end up poisoning the well and confusing users. There's a huge difference between "can't" track and "won't" track. Right now you're claiming "can't," but it sounds like you're squarely in the "won't" category of having your servers "avert their eyes." I think this understandably makes people uneasy, particularly given the data mining direction it sounds like the company is headed.

It was interesting to see that Uber is providing financial support for police militarization:

https://twitter.com/shane_bauer/status/507978633894313985

Shane Bauer's full coverage of the "Urban Shield" police convention in Oakland was great:

http://www.motherjones.com/mojo/2014/09/video-highlights-oak... https://storify.com/smbauer1/urban-shield-swat-convention-in...

Thanks! You can support ongoing development by sending donations to our BitHub. Anyone who commits to an Open Whisper Systems repository will get 2% of your donation:

https://whispersystems.org/blog/bithub/

The dashboard:

http://bithub.whispersystems.org/

At Open Whisper Systems, we wrote a small open source gradle plugin called "gradle-witness" for this reason. Not just because dependencies could be transported over an insecure channel, but also because dependencies could be compromised if the gradle/maven repository were compromised:

https://github.com/whispersystems/gradle-witness

It allows you to "pin" dependencies by specifying the sha256sum of the jar you're expecting.

1. You can replace your Google sync account with Flock if you choose. You can import data from a Google account into your Flock account without destroying or altering the data in your Google account.

2. The Flock encryption is used for transmitting data to/from the server. On the device, we let the Android permission system take over from there, so you don't have to enter a password in order to see your contact or calendar items. Your workflow remains the same as before.

With Google Sync, the servers have access to your plaintext data. This means that Google Inc, the engineers at Google with access to the servers, any attackers that compromise Google's sync servers, or any governments that compel Google to provide them access to the servers, all have access to everything (photos, contacts, calendar entries, documents, etc.) that you sync.

With Flock, the data is encrypted with a key that only the user knows before being transmitted to the server. This means that nobody with access to the Flock servers can see your data.

I know a lot is happening with FarmBot right now, and that they've talked about doing larger-area experiments. You might consider getting in touch with them: http://go.farmbot.it/

> 1. What is TextSecure's business model? Who pays for the server infrastructure?

It's a good question. TextSecure is not a business, so we don't really have a business model in the traditional sense. Open Whisper Systems is a collective project made up of volunteers and a growing number of contributors, who are sometimes paid by donations (https://whispersystems.org/blog/bithub/) and grants.

Thus far, we've been able to smoothly fund the server infrastructure through grants and donations as well. I think we'll probably be able to continue that way indefinitely, but if that ever changed for any reason, we would consider charging small amounts for premium or high cost features like extremely large attachments. But in general, Open Whisper Systems is a project rather than a company, and the project's objective is not financial profit. I know that's a difficult thing to explain.

> 2. Doesn't WhisperSystems belong to Twitter? Twitter is a US-company (and also part of the NSA stuff), so why should I use that kind of software?

This is also confusing, but Open Whisper Systems is not Whisper Systems. Open Whisper Systems has no relationship with Twitter at all, and is a different organization that came together to facilitate development of the Whisper Systems software which was released under GPLv3. Twitter has never contributed money or resources to Open Whisper Systems, and is not in control of any of the infrastructure.

Browser support. We've got major internet sites on board waiting to deploy it, but despite some early indications of support, the browsers have not been forthcoming. We even tried writing the code for them, but to little avail.

My sense is that Google is all-in on Certificate Transparency right now, and doesn't want anything to distract from that. However, I think a successful CT deployment is a long time coming still, and TACK could have been out two years ago. My sense is that Mozilla is just understaffed and/or waiting to follow Google's lead in this area.

Ultimately, this is the frustrating thing about trying to improve the state of secure communication today. Most of the levers are in the hands of the browser vendors, which makes it difficult for those of us on the outside to help iterate things forward.

To clarify, these audits aren't a choice, they are a contractual obligation as part of receiving grant funding from OTF. Projects are allowed some flexibility in terms of when they schedule it, but it has to be done. I think it's a great idea.

Also, during the period of time when TextSecure received audits from firms as part of an OTF grant, publishing the results was not an option that was contractually available to us. It's not something we "decided."

These are bugs, but I'm not sure they are what you think they are. I would be worried if TextSecure indicates a message is going to be sent securely, but it is sent insecurely. This bug, however, is an edge case where TextSecure indicates that it is going to send a message insecurely, and that's what it does.

It's also true that until recently we didn't have an encrypted group chat protocol, but at no point in the past did TextSecure ever indicate that group chat was encrypted. Just the opposite.

It's important to realize that TextSecure is simultaneously a standard unencrypted SMS app as well as an encrypted chat app.

Prisoners in the USA are, in fact, put into solitary for some pretty arbitrary reasons, including the types of books they read. You might find this article by Shane Bauer, one of the hostages held by Iran, interesting:

http://www.motherjones.com/politics/2012/10/solitary-confine...

We agree that localization is super important. TextSecure is localized into 30 languages already. We use Transifex to crowdsource it: https://www.transifex.com/projects/p/textsecure-official/

We are also interested in a TextSecure implementation for the desktop!

Right now the protocol includes multi-device support, so the foundation is there for developing desktop and tablet apps that work seamlessly in conjunction with your phone. Our first desktop implementation is likely going to be a browser extension, feel free to jump in and get involved with that if you'd like.

This OTRv3 document has been available since at least 2012(?), so I'm not sure why there's a sudden interest in discussing it, but here was our analysis of OTRv3 at Open Whisper Systems:

1) The introduction of SIGMA in the switch from OTRv1 to OTRv2 significantly reduced the "deniability" properties of OTR. The protocol does some explicit things to provide "full" deniability, but in OTRv3 only people who've actually had a conversation with Alice can produce a complete forged transcript with Alice. More details: https://whispersystems.org/blog/simplifying-otr-deniability

2) OTRv3 doesn't work in asynchronous environments. It depends on a reliable and synchronous transport that delivers messages in-order. The messaging landscape is increasingly asynchronous, so OTRv3 is a difficult fit for modern messaging protocols. More details: https://whispersystems.org/blog/asynchronous-security

3) The OTRv3 "ratcheting" protocol is slow. It uses what we refer to as a "three step ratchet," which provides less-than-ideal forward secrecy and "future secrecy" semantics. More details: https://whispersystems.org/blog/advanced-ratcheting

We sought to improve on OTRv3 by addressing these issues in the TextSecure V2 protocol, which we believe builds on the work of OTR to provide enhanced and simplified deniability, an asynchronous-friendly environment, and optimal forward and future secrecy semantics: https://github.com/WhisperSystems/TextSecure/wiki/ProtocolV2

It also now supports group messaging and multi-device messaging, but we'll cover those in a future blog post.

I help develop TextSecure, an Android app which allows users encrypt their text messages: https://play.google.com/store/apps/details?id=org.thoughtcri...

It's fully open source: https://github.com/whispersystems/textsecure

You can also sign up to be notified when it's released for iOS: https://whispersystems.org/blog/iphone-rsn/

Our feeling is that 40MB for an initial download is not acceptable on mobile devices, particularly in many of the areas we'd like to support. Maybe we're wrong, but it seems like too much on edge networks, particularly given that it's only going to grow as more users join. Ideally we'd have 100MM or 500MM, not just 10MM.

We can definitely make lightweight diffs happen, but that initial download is tough, and is going to get tougher.

This post is about building untrusted servers, which is somewhat orthogonal to "the snapchat problem."

The best a privacy preserving protocol can hope to achieve is to match the characteristics of its non-privacy preserving equivalent.

Asymmetric PIR (the server transmits an unencrypted bloom filter) falls short of the non-privacy preserving equivalent, since the user makes offline queries that can't be rate limited by the server. Symmetric PIR (the server transmits an encrypted bloom filter) provides identical properties to the non-privacy preserving equivalent, since the user needs to make queries that can be rate limited by the server, even though the queries leak no information to the server.

How that rate limiting (or unlisted numbers, or whatever) works is outside the scope of the protocol, just as it is in the non-privacy preserving case. For TextSecure, you'd need to verify 1 million phone numbers in order to perform your attack. Whether you can do that or not isn't really the point: we simply want to do as least as well as everyone else, without revealing information to the server.