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:55:12 PDT 2013


But there is a strong disadvantage of Jabber+OTR compared to Threema (and
probably Heml.is):

Jabber+OTR needs a running client on both sides (two-way interactive 
communication) -> offline messages are not supported by Jabber+OTR
( offline messages are supported by XMPP, but not with OTR ).

But Jabber+PGP works for offline messages (I use it in my mcabber), but 
PGP is probably not supported by these smartphone jabber clients.... :(

Any idea how to have offline secure messaging (when Jabber+OTR is not possible
to use)? (this is probably the reason why Heml.is would use XMPP + PGP instead
of OTR).

Pavol

On Mon, Jul 15, 2013 at 02:04:34PM -0700, Parker Higgins wrote:
> 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

-- 
_______________________________________________________________
[wilder at trip.sk] [http://trip.sk/wilder/] [talker: ttt.sk 5678]


More information about the liberationtech mailing list