Search Mailing List Archives


Limit search to: Subject & Body Subject Author
Sort by: Reverse Sort
Limit to: All This Week Last Week This Month Last Month
Select Date Range     through    

[liberationtech] Surespot? Re: Feedback on Threema - Seriously secure mobile messaging.

Pavol Luptak wilder at trip.sk
Mon Jul 15 14:00:48 PDT 2013


I like Surespot (and also TextSecure), but it runs on Android platform only.

If I want to communicate with iPhone users in a secure way, I am forced to 
use Threema which is available on both platforms (iOS and Android).

Is there any multiplatform opensource end-to-end secure alternative? 
(instead of Threema)?

Of course, I can use Jabber+OTR, but I think there is even no opensource 
alternative of Jabber+OTR client on iOS platform yet.

I would not care about iOS (I use Android), but many my friends have iPhone.

Pavol

On Mon, Jul 15, 2013 at 12:41:45PM +0200, Moritz Bartl wrote:
> Surespot looks like an open source alternative:
> 
> https://www.surespot.me/
> https://www.surespot.me/documents/how_surespot_works.html
> 
> technical overview
> 
> User creation- When a user is created in surespot two ECC (secp521) key
> pairs are generated, one for key derivation, and one for signing.
> 
> The username plus keypairs create a 'surespot identity'. This identity
> is stored on the device symmetrically encrypted using 256 bit AES-GCM
> with a PKCS5S2 key derived from the user's password (plus salt and other
> data). The public keys are uploaded to the server where they are signed
> by the server using the server's private key. A user may create multiple
> identities and switch between them at will.
> 
> User authentication- To login the client generates a signature using the
> identity's private signing key against the username, password, and
> randomly generated data. The server validates the client provided
> username, password, and aforementioned signature against its stored
> public signing key for the identity in question. If successfully
> verified the client is issued a session cookie which authenticates them
> for future requests until the session expires or they logout.
> 
> As the exchange occurs over SSL, session cookies are thought to be a
> secure enough mechanism to facilitate authentication, but in the future
> every request could be validated against the signature. The fact that
> messages could not be decrypted by a session hijacker given the end to
> end encryption nature of the system also factors into this decision.
> 
> Identity backup/restore- As the private key stored on the device is the,
> uh key, to unlocking all of the data, it is of utmost importance. In the
> case of a lost or stolen device, if the key is lost along with it, so is
> all of the data. Identity backup/restore and key versioning help to
> mitigate this problem. A user may backup their (encrypted) identities
> (username and key pair history) to device storage, or the cloud and
> restore them upon demand. Obviously the security is only as strong as
> the password used to store the identity in whatever cloud service and
> the surespot password, so make them strong! Never shall a private key be
> stored on a surespot server.
> 
> Man in the middle- MITM is currently thwarted by the following:
> standard SSL implementation.
> When a user is created and its public keys uploaded to the server, the
> server signs the public keys. Clients that download the public key then
> validate the signature of the key against the hardcoded server public
> key in the client. This ensures a MITM attack trying to use a rogue key
> pair to impersonate a user will be prevented.
> 
> Key versioning/revoking- A user may generate a new pair of key pairs at
> any time. This process is as follows:
> the user requests a “key token” from the server
> the user generates a new pair of key pairs and uploads them to the
> server along with an authentication signature (username, password,
> random) and a token signature (the received key token, password)
> generated by the identity's existing signing private key.
> the server validates the password and both signatures and if valid
> increments the “key version” and signs and stores the public keys in the
> database.
> the server notifies other users involved in conversations with the
> revoker that the key has been revoked.
> clients will receive this revoke notification and act accordingly.
> the old keys are now considered revoked and any message sent using them
> will be rejected by the server.
> 
> Use case: lost/stolen phone-
> adam lost his phone, luckily he has his identities backed up on Google drive
> adam buys a new phone and installs surespot
> adam restores his identities from the backup
> adam generates a new pair of key pairs successfully
> attacker with old phone receives revoke message
> old phone knows revoke message is from the same user and promptly logs
> out and deletes any related data
> any subsequent authentication attempts on old phone will be rejected
> 
> Sending a message- After two users invite then accept each other the
> users are now friends, the two friends can access each other's public
> keys, which allows key derivation and message exchange. The scenario
> plays out as follows at a high level glance:
> adam wants to send cherie a message
> adam asks the server for the latest version of cherie's public key
> adam verifies cherie's public key (which is signed by the server)
> against the hard coded server public key in the app and proceeds if valid
> adam derives the shared secret
> adam encrypts the message using AES 256bit GCM using the derived shared
> secret as the key and sends it to cherie, the to and from key version
> used to generate the message are included as part of the message
> cherie receives the encrypted message
> cherie downloads and verifies the version of adam's public key needed to
> derive the shared secret for the message
> cherie derives the (same) shared secret
> cherie decrypts the message using the shared secret
> 
> Data stored on device- surespot ensures that no message data or keys are
> stored on the device an unencrypted fashion. This means that even if
> someone has your device they will not be able to get the information
> without knowing your password. Users will be prompted to create a secure
> password upon creating an identity.
> 
> 
> -- 
> Moritz Bartl
> https://www.torservers.net/
> --
> Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at companys at stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech

-- 
______________________________________________________________________________
[Pavol Luptak, Nethemba s.r.o.] [http://www.nethemba.com] [tel: +421905400542]


More information about the liberationtech mailing list