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