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.stanford.edu/mailman/listinfo/liberationtech
