TextSecure: Forward secrecy for asynchronous messages | Hacker News Reader

TextSecure: Forward secrecy for asynchronous messages

whispersystems.org

96 pointsneilk53 comments

Maybe the time has come to resurrect Wave (http://en.wikipedia.org/wiki/Apache_Wave) and usurp email by turning Wave into a p2p PFS communications platform.

What's the news on that collaboration with CyanogenMod? Will they use TextSecure as the default texting app, or will they create something new?

We're integrating TextSecure into the CyanogenMod system SMS provider. You'll be able to use any text messaging app you'd like, and outgoing messages will transparently be encrypted when communicating with other TextSecure or CM users.

Great. Hopefully we'll see RedPhone integrated in the future, too, maybe when data usage is not an issue anymore.

There's a comment on that blog post that says "what is meant by 'the server'?" That's probably the best possible question here. What's the point of building another messaging system and key distribution method if they can show up with a secret subpoena and do whatever they want with your servers?

The client is open source [1], so you can verify that it's doing what they claim. You can also build it yourself if you want to be really careful. I don't think messing with the servers would do any good (except for metadata) when the clients are handling the encryption.

[1] https://github.com/WhisperSystems/TextSecure/

> would do any good (except for metadata)

But metadata is important

Metadata is important, but right now TextSecure uses SMS/MMS, so "the server" is your telco. I don't think it's possible for anything we do server side to be worse.

metadata is what they are looking at now. they collect everything else so they can look at it later when they break the encryption

From what I gather the system is built so that "the server" does not hold any secrets. I suppose there is a possibility of metadata leakage and/or denial of service, but the message bodies would remain safe due the end-to-end encryption.

I have a couple problems with this:

    * Don't trust an OS you can't examine the source for.
    * Don't trust binaries you can't build from source, no matter what OS you run them on.

I wouldn't trust iOS, OSX, Windows or any other closed system with any kind of encryption these days.

sure, but i trust Moxie Marlinspike

Right, he has a good reputation. But that shouldn't help -- he can't do anything about what underlies his code on these closed systems.

You can add most Android devices to that list. Sadly, this is a compromise we'll have to make if we want encryption to be even vaguely widespread.

I think you also forgot:

  * Don't trust a compiler that has been compiled with an untrustworthy compiler... [1]

[1] http://cm.bell-labs.com/who/ken/trust.html (well worth the read)

Any discussions with Mozilla? It would be great to get TextSecure as Firefox OS's default text message app. Also RedPhone should be the default phone app.

Isn't the whole interface and all of the apps HTML5? I know that Firefox OS is Android under the hood, but can it run APK files?

> can it run APK files?

I don't see why it'd need to. It's not like iPhone is running the APK either.

Firefox OS is not Android under the hood at all.

"Firefox OS (sometimes abbreviated FxOS) is a new mobile operating system developed by Mozilla. It uses a Linux kernel and boots into a Gecko-based runtime engine, which lets users run applications developed entirely using HTML, JavaScript, and other open web application APIs." https://developer.mozilla.org/en-US/docs/Mozilla/Firefox_OS

It does use Android kernels, probably for the drivers.

So, the problem is that the app itself can't run (reliably) in the background to respond to key-exchange requests?

It looks like iOS apps aren't allowed network connections when in the background[0]. So would another platform with fewer restrictions on background processes (e.g. Android?) be able to perform key-exchange while the app is backgrounded?

(forgot the link:)

[0]: https://developer.apple.com/library/ios/documentation/iPhone...

Not really...you'd still need to be online which isn't always the case.

But surely you must have enough connectivity for a key-exchange to take place (most of the time) if you're able to receive push notifications in the first place?

iOS push notifications are about one idea: power management. By forcing all servers to communicate to their apps through one channel, the actual iOS hardware only needs to maintain one connection: the connection to Apple's servers.

The alternative is that 3, or 8, or dozens of apps all maintain separate connections to their own motherships, which drains a device's battery like a mynock with a case of the munchies.

i guess there could be a system service where you register "please check server x for new messages every y minutes" and the service would handle the queue intelligently to save power?

In real life, apps just leak your passwords into the cloud and send you push notifications. Thats how the average jabber IM on an iphone stays online when the app is in the background.

One of these apps tried to connect to my jabber server even after I deleted it from the phone.

Actually you can have time limited connections with VoIP socket background processing mode. IOS 7 also has some new push features that cover one corner case that VoIP sockets didn't cover.

Unrelated to the content of your post, but your website has mixed content (which is blocked by Firefox 23): [13:47:59.462] Blocked loading mixed active content "http://openwhispersystems.disqus.com/embed.js" @ https://whispersystems.org/blog/asynchronous-security/:184

Are these WhisperSystems apps going to get desktop clients anytime soon?

Is this not susceptible to a man in the middle attack? You have to trust that WhisperSystems will never release the keys, and always maintain server security. Perhaps it would be better to send the initial keys out of band.

The prekey messages are signed with the owner's identity key.

Are the prekeys generated/saved per potential contact (signed/encrypted with the contact's public key of course!) or is it a general pool for everybody? If it's the latter than couldn't a malicious user flood you with 100+ messages and prevent others from async contacting you?

I think it uses SMS to send the actual messages. Anyway, the re-usability of keys is actually a feature that enables perfect forward secrecy.

If I get the idea right, the server keeps a list of Alice's p, g and A generated in advance for a Diffie-Hellman exchange. Bob then can complete his part of the key agreement when Alice is offline and send B together with the message ciphertext. It is vulnurable to a mitm attack just like online DH, but leaking the prekeys will not compromise anything, because the are designed to be public.

Thanks. I guess that one side of the communication is always assured to be authentic and not a MITM as it is not using a pre-generated key. Reading the documentation there is a facility to verify keys [1] with QR codes or voice over the phone. That's really cool.

[1] https://github.com/WhisperSystems/TextSecure/wiki/Using-Text...

This does mean that you can't use ZRTP-style short authentication strings, though, as the attacker would have a very easy time brute-forcing the SAS. You'd have to verify the entire length of the fingerprint.

Does textsecure req Google framework apk like Redphone? I don't trust Google to not silently install spyware on journalists phones whenever US feds want to identify sources or commit easy political blackmail

It's on iOS. As far as we know, iOS will read every NSString it wants without regard to privacy.

RedPhone (for Android) works fine without GSF installed. It just falls back to using SMS instead of GCM for the call signaling.

TextSecure, at least the current Android version, also works without GSF, because SMS is used as message transport.

according to this it does https://github.com/WhisperSystems/RedPhone/issues/143

However, like the majority of network-enabled Android applications, RedPhone relies on the existence of APIs provided by the Play Services Framework. If you're avoiding Google Play because you don't want your device to "phone home," you should be aware that merely having Play installed (even without an account registered) is enough for your device to phone home. If you uninstall Play, however, the Play Services Framework will be unavailable, and RedPhone (along with many other applications) will not function.

That's not entirely true, I have an Android phone without any closed source Google junk installed (including GSF) and RedPhone works just fine using SMS for signaling.

However, I do wonder if Moxie might be planning on deprecating the SMS signalling functionality in the future, now that GCM exists and considering it costs about $0.01 per SMS sent by the server...

Could the prekeys be exchanged in one synchronous session directly between the peers to enable future async messages? Is there a need to store them outside either end-point?

Users can always revoke their public keys. The same public key does not have to be used continually. Allow users to revoke their keys as often as they like. Heck, force the keys to expire in 1 day if you like! We already expect the sender to be online. The sender can check for key revocation before they send the message. Or let the server send back a error response if the sender used an expired or revoked key to encrypt the message.

This is an odd twist on perfect forward secrecy. PFS is the assertion that even with one of the private keys, a passive attacker cannot decrypt the stream. With this system knowledge of the initiator's private key and the prekey is enough to decrypt the stream.

Getting that prekey is almost certainly easier than getting both private keys, so the security guarantee isn't equivalent to PFS.

I think you might be misunderstanding what's happening here. The prekey is nothing but a public signed ECDH message. An attacker would need to compromise that message's corresponding private key in order to decrypt any ciphertext that was encrypted with it. It is only used once to start a conversation and then destroyed, so the attacker would have a very small window in which to compromise the private key. Just as if it were a synchronous conversation.

This is identical to a situation where a client initiates secure sessions with 100 different people who happen to be offline. When they come online, they respond with their key exchange message and continue.

This is great for PFS, but still doesn't try to provide any protection from traffic analysis. Defeating traffic analysis in a mobile client environment with minimal trust on servers, while retaining PFS, and supporting multi-party chat, is the hard problem.

how does this compare to https://pond.imperialviolet.org/ ?

I think textsecure still leaks some metadata (ie. there is no mixing/forced delays). Overall it seems their approach to design is radically different.

Would love to see this protocol for email as well.

This seems clever, but isn't this problem obviated by Push Triggers in iOS7?

Mobile networking is imperfect. An app capable of waking in response to a push notification may still fail to create a network connection with the sender.

Any possibility of adding this kind of functionality to libotr?

Is it possible to use without play store?

Reply on news.ycombinator.com