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