[guardian-dev] [Oi2-dev] Fwd: [Gibberbot] GPG/PGP Encryption (#181)

[Abel Luck]

I understand his concern that OTR /seems/ synchronous, but I disagree
that his proposal is a tenable solution.

First, OTR isn't inherently synchronous any more than any other chat
protocol is. Look no further than TextSecure. That's a modified OTR on
SMS, a distinctly async protocol [1].

Rather, the problem is all of the UIs are synchronous.

The right solution, imho, is to hide from the user the key exchange.
This only works when OTR is enforced.

Example:

1. Alice starts new chat to previously unseen recipient, Bob
2. Alice types in message, presses "send"
3. GB holds the message internally, and sends OTR init
4. GB waits for init to complete with Bob
  Meanwhile: Alice sees her message is sent, but with the delivery/read
notification not active.
5. GB sends queued message to Bob
6. Alice sees delivery notification

Of course this assumes Alice and Bob don't want to verify their keys,
but Henning's proposal to use GPG doesn't solve this easier. In fact it
makes it even more difficult, as the public key for Bob has to be
fetched from somewhere or provided ahead of time and verified. OTR
support in-band exchange of keys and in-band verification.

Additionally, Henning's proposal lacks security properties that OTR
provides. Swapping protocols like this behind the scenes is, at best,
disingenuous to the user, and at worst, fatal.

Now, one good takeaway here is to investigate how many roundtrips an OTR
init() requires and whether that can be reduced. I will follow up on the
otr dev list.

TL;DR: OTR isn't synchronous. OTR's initialization === GPG's
initialization process. OTR has desirable security properties. Rolling
homegrown crypto = bad.

[1]: Admittedly, he dropped some security properties, but that was to
fit inside the byte limit not a function of async SMS


~abel

Nathan of Guardian:
> Seems relevant to PSST!
> 
> 
> -------- Original Message --------
> Subject: [Gibberbot] GPG/PGP Encryption (#181)
> Date: Sun, 14 Oct 2012 08:51:59 -0700
> From: Henning Meyer <notifications at github.com>
> Reply-To: guardianproject/Gibberbot
> <reply+i-7574536-19876172d77744275ffcbc82f14a3a1b4605cb5d-30851 at reply.github.com>
> To: guardianproject/Gibberbot <Gibberbot at noreply.github.com>
> 
> Gibberbot is a Jabber-Client for Mobile Devices. Mobile Devices tend to
> have unstable network connections. As OTR needs a bidirectional
> communication between Alice and Bobs clients for initialization, OTR
> only works, when both Alice and Bob are online at the same time.
> GPG-Encryption would allow Alice to initiate a Chat, even if Bob is
> currently offline. Once the Bob is online he could receive Alice'
> message, even though Alice might be offline at that time.
> So - overall GPG might not feature as many security features as OTR, it
> still provides message secrecy and authentication. PLUS GPG is more
> robust in a mobile environment.
> 
> So my request is: Please incorporate GPG-Encryption into Gibberbot!
> I guess as Bob might have more than one key (depending on the XMPP
> ressource he is going to use) Alice should encrypt her message with all
> of Bobs keys, resulting in a slighty larger message.
> 
> Please let's discuss this.
> 
> I'd like to help implementing.
> 
> ---
> Reply to this email directly or view it on GitHub:
> https://github.com/guardianproject/Gibberbot/issues/181
> 
> 
> 
> _______________________________________________
> Oi2-dev mailing list
> 
> Post: Oi2-dev at lists.mayfirst.org
> List info: https://lists.mayfirst.org/mailman/listinfo/oi2-dev
> 
> To Unsubscribe
>         Send email to:  Oi2-dev-unsubscribe at lists.mayfirst.org
>         Or visit: https://lists.mayfirst.org/mailman/options/oi2-dev/abel%40guardianproject.info
> 
> You are subscribed as: abel at guardianproject.info
>