Re: [liberationtech] Surespot? Re: Feedback on Threema - Seriously secure mobile messaging.
On Mon, Jul 15, 2013 at 02:17:38PM -0700, Tony Arcieri wrote: > They seem to have an... interesting philosophy about open source: > > "When you have an entire planet looking at the source code you can be > assured that the implementation is highly scrutinized and proven." > > Apparently all you have to do is put your source code online and it will > magically be highly scrutinized and proven It's a prerequisite. Necessary, but not sufficient. Closed source can't be audited by the public by definition. -- 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
Re: [liberationtech] Surespot? Re: Feedback on Threema - Seriously secure mobile messaging.
On 15 July, 2013 - Nathan of Guardian wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 07/15/2013 05:55 PM, Pavol Luptak wrote: > > Any idea how to have offline secure messaging (when Jabber+OTR is > > not possible to use)? > > Gibberbot already partially implements this, and we are working with > ChatSecure and others to move forward with a standards-based solution > to this. While we already have OpenPGP support on Android, we don't > think PGP is the way to go for efficient mobile chat, and also are not > ready to abandon forward secrecy as a feature. > > And so, our OTR offline solution is comprised of the following pieces: > > 1) Client/App supports XMPP extension for message delivery receipts > and auto-retry: > http://xmpp.org/extensions/xep-0184.html > > While the person you are trying to send a message to may be offline at > the very moment you want to message them, it is very likely that they > will be online at some point in the near future. If your chat client > is always running in the background on your device, it can sense when > they come online, and deliver the message you wrote earlier. By > supporting delivery receipts, you can confirm it did indeed get > through to them, and if not, continue auto-retrying until it does. The main problem I see with this is that this still requires both clients to be online at the same time, something which Threema, Heml.is etc. avoids. My phone internet access is seldom a constant thing, so this is obviously not ideal. > > 2) XMPP server that supports offline messages storage and delivery: > http://xmpp.org/extensions/xep-0160.html > http://xmpp.org/extensions/xep-0091.html > ejabberd support: http://www.process-one.net/en/ejabberd/protocols/ > http://prosody.im/doc/modules/mod_offline > > XMPP already has a well-established mechanism for this, and many > open-source servers like ejabberd and prosody support it well. > > 3) Client that supports long-lived OTR sessions. If a chat > conversation is held open, then the same OTR session key should be > used as long as possible, i.e. until one of the participants request a > session restart. > I assume that these two options go together, i.e. that an OTR session is kept alive from both ends, and offline message delivery is used to send messages over that session. Definitely a good idea - if you only work with a single client per user. Alternatively, that you would attempt to keep an OTR session going with each resource ever seen, and send multiple messages (OTR v4 according to wikipedia). Long-lived OTR session keys is also something of a relaxation of the forward secrecy requirement, is it not? (Playing a bit of devil's advocate here) > 4) Optionally: use the OTR v3 shared "extra" symmetric key generation > feature to encrypt offline messages and send those via a mobile push > service. Sidechannel message delivery definitely sounds interesting. Could you expand on the guarantees made regarding this key? Is it the same as for regular OTR keys? (PFS, etc) > Would love comments on this. Anything else we might have missed? > To be quite frank, for offline message delivery to an unknown client, the OTR model rarely holds up very well. As such, I would propose just going for XEP-0027 (PGP-encrypted messages) if there is no OTR session available, and trust the offline message delivery services of the server to get them to the destination. This drops forward secrecy, but makes it actually possible to send messages in the first place. Moving transparently onto OTR as soon as possible would still be a priority of course. Best /P > +n > > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.11 (GNU/Linux) > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQIcBAEBAgAGBQJR5I2eAAoJEKgBGD5ps3qpXSsP/2Bd1R7fw4C2LeGM3RAZuFup > Jhd/YIBt4I7Yh4tIGGs2Bn7B3gCGmDXRTnqWPtj8IpE/XINB0Pr4gME0kC/xV0Kf > dFotFwps3WkihJXaR2IeK4FmDoLX4xVETqiFFwZSE4FM2zNJiVPsXIDzeIXKp//9 > HSU/Rhv4y/ycSPONqC0Wy6x+0TOM6arcTGmg9noDbnBWIGxbOEU9jKSpJhzDHSz7 > 79rMorer7KS1p88zJ+tMoprdwGqtf0wEZacwgIOKcZRUPxWveqUPcANOyGfi40u4 > 11vvbwVBj0hETTCWDtxFOO61JTLGWiqlVNd6bsPICr08cfe42s6hJEMnay00tWaJ > ovcw4MCAHP/c9sWqy5KSufa04NIMlON5g83cQRGevqnEMJYDHHlrLyFTHO8M+ZY+ > CF6wmiGJIHQyet6xxjPZH97vk+tPC6eTnoLFiNxS2SlAJYmQxmcAtqvFO+HLDBNM > wOosJ0TjA3gmDwU6udhpPbe/BBigemnFedRahta1PbRVgl/1oDwH8ecwoj9xTWtq > O/LmJbiAkqCf4YnFq+1sbyTXvRw9MBdXXJUc3vClbxmGQ6xZjMAZKnOVpbKeSmSd > v73UVvtNXsV4XfVOICbRS84dakxA3YG9P+T37un82r0tyDJUB7DXe2HZwiGHQ58T > YJUO0epUFqDfidtrWyJf > =7SnB > -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 -- Petter Ericson (pett...@acc.umu.se) -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanf
Re: [liberationtech] Surespot? Re: Feedback on Threema - Seriously secure mobile messaging.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/15/2013 05:55 PM, Pavol Luptak wrote: > Any idea how to have offline secure messaging (when Jabber+OTR is > not possible to use)? Gibberbot already partially implements this, and we are working with ChatSecure and others to move forward with a standards-based solution to this. While we already have OpenPGP support on Android, we don't think PGP is the way to go for efficient mobile chat, and also are not ready to abandon forward secrecy as a feature. And so, our OTR offline solution is comprised of the following pieces: 1) Client/App supports XMPP extension for message delivery receipts and auto-retry: http://xmpp.org/extensions/xep-0184.html While the person you are trying to send a message to may be offline at the very moment you want to message them, it is very likely that they will be online at some point in the near future. If your chat client is always running in the background on your device, it can sense when they come online, and deliver the message you wrote earlier. By supporting delivery receipts, you can confirm it did indeed get through to them, and if not, continue auto-retrying until it does. 2) XMPP server that supports offline messages storage and delivery: http://xmpp.org/extensions/xep-0160.html http://xmpp.org/extensions/xep-0091.html ejabberd support: http://www.process-one.net/en/ejabberd/protocols/ http://prosody.im/doc/modules/mod_offline XMPP already has a well-established mechanism for this, and many open-source servers like ejabberd and prosody support it well. 3) Client that supports long-lived OTR sessions. If a chat conversation is held open, then the same OTR session key should be used as long as possible, i.e. until one of the participants request a session restart. 4) Optionally: use the OTR v3 shared "extra" symmetric key generation feature to encrypt offline messages and send those via a mobile push service. Would love comments on this. Anything else we might have missed? +n -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJR5I2eAAoJEKgBGD5ps3qpXSsP/2Bd1R7fw4C2LeGM3RAZuFup Jhd/YIBt4I7Yh4tIGGs2Bn7B3gCGmDXRTnqWPtj8IpE/XINB0Pr4gME0kC/xV0Kf dFotFwps3WkihJXaR2IeK4FmDoLX4xVETqiFFwZSE4FM2zNJiVPsXIDzeIXKp//9 HSU/Rhv4y/ycSPONqC0Wy6x+0TOM6arcTGmg9noDbnBWIGxbOEU9jKSpJhzDHSz7 79rMorer7KS1p88zJ+tMoprdwGqtf0wEZacwgIOKcZRUPxWveqUPcANOyGfi40u4 11vvbwVBj0hETTCWDtxFOO61JTLGWiqlVNd6bsPICr08cfe42s6hJEMnay00tWaJ ovcw4MCAHP/c9sWqy5KSufa04NIMlON5g83cQRGevqnEMJYDHHlrLyFTHO8M+ZY+ CF6wmiGJIHQyet6xxjPZH97vk+tPC6eTnoLFiNxS2SlAJYmQxmcAtqvFO+HLDBNM wOosJ0TjA3gmDwU6udhpPbe/BBigemnFedRahta1PbRVgl/1oDwH8ecwoj9xTWtq O/LmJbiAkqCf4YnFq+1sbyTXvRw9MBdXXJUc3vClbxmGQ6xZjMAZKnOVpbKeSmSd v73UVvtNXsV4XfVOICbRS84dakxA3YG9P+T37un82r0tyDJUB7DXe2HZwiGHQ58T YJUO0epUFqDfidtrWyJf =7SnB -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
Re: [liberationtech] Surespot? Re: Feedback on Threema - Seriously secure mobile messaging.
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
Re: [liberationtech] Surespot? Re: Feedback on Threema - Seriously secure mobile messaging.
Moritz Bartl writes: >Surespot looks like an open source alternative: > >https://www.surespot.me/ >https://www.surespot.me/documents/how_surespot_works.html surespot's code may be excellent (I haven't looked at it), but their front page at https://surespot.me/ makes a promise it shouldn't make: | You can delete your message from the receivers phone. | | Be confident sending private information and pictures. You have | control over your messages, when you delete a sent message it will | be removed from the receivers phone and images are not sharable | unless you make them so. Software can't be simultaneously open source on the client side and make promises about how the client side will behave. Actually, one can't really make that commitment even when the client side is closed-source (for example, if a closed-source app runs on an open source OS, then when the app tries to delete the message, the OS can retain a copy). But anyway, the loophole is even easier to exploit when the application code itself is open source. Surespot is just one of several apps making such claims. I wrote a bit of a rant about this trend here: http://www.rants.org/2013/06/09/privacy-promises-and-client-side-betrayal/ Again, this is not about their code, which may be fantastic. It's just about their marketing language around the code. Best, -Karl >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 succ
Re: [liberationtech] Surespot? Re: Feedback on Threema - Seriously secure mobile messaging.
They seem to have an... interesting philosophy about open source: "When you have an entire planet looking at the source code you can be assured that the implementation is highly scrutinized and proven." Apparently all you have to do is put your source code online and it will magically be highly scrutinized and proven On Mon, Jul 15, 2013 at 3:41 AM, Moritz Bartl wrote: > Surespot looks like an open source alternative: > > https://www.surespot.me/ > https://www.surespot.me/documents/how_surespot_works.html -- 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
Re: [liberationtech] Surespot? Re: Feedback on Threema - Seriously secure mobile messaging.
Thanks guys for info! Pavol On Mon, Jul 15, 2013 at 05:04:25PM -0400, Nathan of Guardian wrote: > On 07/15/2013 05: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. > > ChatSecure! > chatsecure.org > https://github.com/ChatSecure > https://github.com/chrisballinger/Off-the-Record-iOS > > Fully interoperable XMPP and OTR. > > It does have its limitations (i.e. iOS limits background apps > capabilities), but it is getting better all the time. > > +n > -- > 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
Re: [liberationtech] Surespot? Re: Feedback on Threema - Seriously secure mobile messaging.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/15/2013 05: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. ChatSecure! chatsecure.org https://github.com/ChatSecure https://github.com/chrisballinger/Off-the-Record-iOS Fully interoperable XMPP and OTR. It does have its limitations (i.e. iOS limits background apps capabilities), but it is getting better all the time. +n -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJR5GPZAAoJEKgBGD5ps3qplzMQAIIYJnssfduB+30HtZguo2rF 9GpqCbnsuo2TQBE+Nu8Wun2IOiCgRPBZY4pWs8p9XvsBoaV/Oc/rHAGWK8hWaTmk 4H0CxVT2Ig106MlUfbjmMusjdubs5r+49CLjD/ogspL/8vZbQfuVVE3yvfW+01MO ymHC5Q9RjZeP29KDmF9ITfjvKj93UyAfgSMSLua5dbC1/NCaLhDQNHBVMrSscFTy pbeMz2tDyjbGmGIzqIwdYMdZAI+ja900TMXTTBZYW5ozpApgyK4NC0ibOQHX/oHD Z7sxE2TBg7mC1xCQR7SaV+JrRjoHQeW5G725QlEPjB+KrioeVf61Hs3jm2DLRDD8 ux8NxtapMi2ZxWJsyc2hIKqOk9UMHpCfva1Dnd5WLm48RCFxaGkgXOo8vflWJSvr JRaiIHX40twUcbAFQZGM6czQk5GokkdLrvbLZ0DR+rg3qz0SpLSrhLHxYHyCnd0x Ps9LltYL6XbddhLkPMOlXWu+TDntE2JWKZ07bn1U0kqBGBgdI7gd4NGYWce8SjAp bg4DgE/o1k4C/myTDCJeHQW6d6oiFVVfJQcNcQY8VPYXc+RJdQsqeuYW1vouoC9v YOB6UguRGEa5yAXlkELA8i0kMnJ1c6oRq19jgaTWTLMBf2/SoftyAS5ywGcaR8zW IOnZWYcJSvqD/vgN4St2 =kZWQ -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
Re: [liberationtech] Surespot? Re: Feedback on Threema - Seriously secure mobile messaging.
-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 co
Re: [liberationtech] Surespot? Re: Feedback on Threema - Seriously secure mobile messaging.
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 th
Re: [liberationtech] Surespot? Re: Feedback on Threema - Seriously secure mobile messaging.
On 07/15/2013 06:41 AM, Moritz Bartl wrote: > Surespot looks like an open source alternative: > > https://www.surespot.me/ > https://www.surespot.me/documents/how_surespot_works.html Yes, I just discovered this myself. Looks interesting at first glance. Seems much more promising than other apps who just say "We'll use PGP!" as their answer to security. I have reached out to them via Twitter to offer support in adding Orbot/proxy support into their app. +n -- 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
Re: [liberationtech] Surespot? Re: Feedback on Threema - Seriously secure mobile messaging.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 GitHub here: https://github.com/surespot, includes client and server software. Would be interested in hearing folks' thoughts on it. Dev is @adam2fours, we ought to invite him to the conversation if he isn't on libtech. On 07/15/2013 06:41 AM, 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 faciligroup chattate 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
[liberationtech] Surespot? Re: Feedback on Threema - Seriously secure mobile messaging.
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
