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 compa...@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]
-- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
