TextSecure: Forward secrecy for asynchronous messages

[espeed]

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.

[mtgx]

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

[moxie]

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.

[jacobquick]

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?

[m_ram]

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/

[zokier]

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.

[bcl]

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.

[andrewreds]

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)

[lucian1900]

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.

[21echoes]

sure, but i trust Moxie Marlinspike

[arthuredelstein]

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.

[m_ram]

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?

[jeffbr13]

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...

[jbrechtel]

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

[mahyarm]

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.

[handsomeransoms]

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

[zokier]

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

[7952]

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.

[pampa]

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.

[moxie]

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

[dobbsbob]

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

[A3c4a]

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.

[gsibble]

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

[zokier]

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?

[ahalam]

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.

[Scaevolus]

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.

[moxie]

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.

[rdl]

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.

[andrewcooke]

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

[zokier]

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

[yourcelf]

Would love to see this protocol for email as well.

[bredren]

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

[skue]

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.

[nwf]

Any possibility of adding this kind of functionality to libotr?

[ebin]

Is it possible to use without play store?