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 compa...@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 compa...@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 -- _______________________________________________________________ [wil...@trip.sk] [http://trip.sk/wilder/] [talker: ttt.sk 5678]
-- 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
