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.

Michael Carbone michael at
Mon Jul 15 12:02:27 PDT 2013

Hash: SHA1

GitHub here:, includes client and server
software. Would be interested in hearing folks' thoughts on it.

Dev is @adam2fours, we ought to invite him to the conversation if he
isn't on libtech.

On 07/15/2013 06:41 AM, Moritz Bartl wrote:
> Surespot looks like an open source alternative:
> 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 faciligroup chattate 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.

- -- 
Michael Carbone
Manager of Tech Policy & Programs
Access |
michael at | PGP: 0x81B7A13E
PGP Fingerprint: 25EC 1D0F 2D44 C4F4 5BEF EF83 C471 AD94 81B7 A13E



More information about the liberationtech mailing list