Whatsapp

Zitat

OTR was designed for synchronous transports. It works well for desktop IM clients, but is not well-tailored for the mobile environment, where a number of factors such as the OS process model, battery constraints, and network conditions have conspired to make mobile messaging systems asynchronous.

If an application running on iOS wishes to receive messages while it’s in the background, for instance, the only reliable mechanism is to use Apple Push Notifications. Once a push notification is delivered, the user will be presented with a familiar prompt:

But on iOS, the actual app still hasn’t received anything at this point. Only once a user physically taps the prompt or otherwise opens the app does the app itself finally receive the message.

These types of asynchronous transports pose a fundamental problem for forward secrecy protocols: in order to send a message, the app first needs to complete a key exchange. However, to complete a key exchange requires a full round trip of sending a key exchange message and waiting for a key exchange message response – in a world where there is no guarantee of a rapid response.

On platforms like iOS, this would make for a particularly bad user experience:

Someone has a message to send, but first has to send a key exchange message and wait for a key exchange message response.
Meanwhile, the recipient of the would-be message gets a visual notification of having received a key exchange message, and has to physically interact with the app before the app has the opportunity to process the key exchange message and respond with one. If the user is away from their device or doesn’t immediately click through to the app, the sender is left waiting.
The receiving user still hasn’t received a message, though, and has to continue waiting for the actual message to be delivered.
If the sending user has navigated away from the app, they will then get their own notification that they’ve received a key exchange response from the message recipient, and will have to navigate back to the app in order for the app to be able to process the key exchange response and finally send the encrypted message.
At this point, the message’s recipient finally receives it.

From a user experience perspective, this is not a tenable model.

Zitat

The TextSecure Protocol

TextSecure’s upcoming iOS client (and Android data channel client) uses a simple trick to provide asynchronous messaging while simultaneously providing forward secrecy.

At registration time, the TextSecure client preemptively generates 100 signed key exchange messages and sends them to the server. We call these “prekeys.” A client that wishes to send a secure message to a user for the first time can now:

Connect to the server and request the destination’s next “prekey.”
Generate its own key exchange message half.
Calculate a shared secret with the prekey it received and its own key exchange half.
Use the shared secret to encrypt the message.
Package up the prekey id, the locally generated key exchange message, and the ciphertext.
Send it all in one bundle to the destination client.

The user experience for the sender is ideal: they type a message, hit send, and an encrypted message is immediately sent.

The destination client receives all of this as a single push notification. When the user taps it, the client has everything it needs to calculate the key exchange on its end, immediately decrypt the ciphertext, and display the message.

With the initial key exchange out of the way, both parties can then continue communicating with an OTR-style protocol as usual. Since the server never hands out the same prekey twice (and the client would never accept the same prekey twice), we are able to provide forward secrecy in a fully asynchronous environment.

Zitat von deagle

Nur für Vielschreiber ist es nix, bei OTP muss der Key mindestens so lang wie die Nachricht selbst sein, d.h. für eine kurze Nachricht werden gleich einmal 2/3 SMS verbraucht.

Zitat von deagle

Nur für Vielschreiber ist es nix, bei OTP muss der Key mindestens so lang wie die Nachricht selbst sein, d.h. für eine kurze Nachricht werden gleich einmal 2/3 SMS verbraucht.

Zitat von wergor

afaik ist sms nur als fallback lösung drin, wenns keine datenverbindung gibt.

Zitat

Gestern ging Textsecure einen Schritt weiter, weg vom reinen Verschlüsseln von SMS und hin zu einer Messenger-App mit mehr Kommunikationsmöglichkeiten als lediglich asynchronen Textnachrichten. Man kann sich aussuchen, ob Textsecure weiterhin eine verschlüsselte Nachricht über den SMS-Weg sendet oder über mobiles Netz kommuniziert (und dann mehr Möglichkeiten bietet).