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.

Parker Higgins parker at
Mon Jul 15 14:04:34 PDT 2013

Hash: SHA1

On 7/15/13 2:00 PM, Pavol Luptak wrote:
> Of course, I can use Jabber+OTR, but I think there is even no
> opensource alternative of Jabber+OTR client on iOS platform yet.

There is ChatSecure:


> On Mon, Jul 15, 2013 at 12:41:45PM +0200, 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 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 -- Too many emails?
>> Unsubscribe, change to digest, or change password by emailing
>> moderator at companys at or changing your settings at
> -- Too many emails? Unsubscribe, change to digest, or change
> password by emailing moderator at companys at or changing
> your settings at

- -- 
Parker Higgins
Electronic Frontier Foundation

Please note our new address:
815 Eddy Street
San Francisco, CA 94109-7701
Version: GnuPG v1.4.13 (Darwin)
Comment: GPGTools -
Comment: Using GnuPG with Thunderbird -


More information about the liberationtech mailing list