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 eff.org
Mon Jul 15 14:04:34 PDT 2013


-----BEGIN PGP SIGNED MESSAGE-----
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: http://chrisballinger.info/apps/chatsecure/

Thanks,
Parker

> 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
> 
> 
> 
> -- 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
> 

- -- 
Parker Higgins
Activist
Electronic Frontier Foundation
https://eff.org

Please note our new address:
815 Eddy Street
San Francisco, CA 94109-7701
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJR5GPiAAoJEJQzX4iaNncJyBIQAMy9WXer1ckvx6h/UdtEjshu
M7sYyFNCsipV2+aEiuvQmKljv4KDsKzQnvYvlUL2C/zRfe0dwZxteKiPU+MAMZw3
sUcRpIpc/mV+Qw9EUY1t8z8ibGNSOMGOjGeImoLJu9ncySbRhegZhtBEbPmbjlyr
qzMjB9UG2VRtudY5aNXSIpVAfawaFNLtTRleMwr4lj4LYMccd4Rj2oId4hLcYRx+
NJfotb1PMnAZ6RzFd+s/ORY2ap3vt2rWknOxeidpCcSVEhFqCKXzmo90WumNdao8
T2Xa6ecv2/CxcIu0+A2uYFG87ouFhFjYheCE4KxIyrraZ+9+w8/8IPTe613ys3v4
DfwTGM85jey1QfAoPB7kDPffWtPsKJfV2J/jl7qhpV4nRhuZKWEDjZC8J3nezHrw
QAfJNPqZFvQ5phaLFqBP8EXlLlDw4cJrC5D+5t0YWuyJAvipc836ODQ5vgHQqdZy
y66HfYLJOjRkIFnF/Edm/pp1tNcXpyIe/XB6/GQ/MBDUFSF0I9cJyjUqArevu6IC
ImDGzTfmikgH5qhsow/EAovUMK4uQK9FMD/mOftLBx46V9cX23j1p8ui3YylVpQp
XBOimqQx4T78emXL4QLdOAIYuzarpBlPfiW4VFLAl2YEhLDykJbqzynmpLW4srGz
fyxdbBAJ22IB3bm5auLT
=3M2f
-----END PGP SIGNATURE-----



More information about the liberationtech mailing list