[Konversation-devel] [Bug 254752] konversation should have Off-the-record (OTR) support

[lurker]

https://bugs.kde.org/show_bug.cgi?id=254752





--- Comment #2 from lurker <lurker lavabit com>  2010-10-21 16:02:36 ---
(In reply to comment #1)
> I'll look into it. This would be a great opportunity to rewrite the encryption
> stuff to try to avoid the random QCA crash of doom. 

Awesome!

> Adding a GUI for it would be interesting..It'd probably be something simple
> like making the lock icon (that currently shows up in encrypted conversations)
> into a button that spawns a context menu with some options. 
> 
> Or even have an image of an unlocked padlock, and clicking on it initates the
> configured form of key exchanges (DH1080 going to blowfish ECB/CBC or whatever
> the OTR does) and then it'd turn into a locked image and there'd be a context
> menu with the options "Enter new key" and "Set key" in the case of blowfish
> (i've never seen these in an OTR implementation let me know if those would be
> expected) and a "End Encrypted Conversation" or something along those lines. 

In order to use OTR, a long-term assymatric key pair (i.e. one private, one
public) must be generated for the user (and it should be one for each
nick/identity or something like that). When a private conversation is requested
with another user, OTR then uses the Diffie-Hellman key exchange to exchange
public keys and create an encrypted channel.

The above key exchange is done unathenticated so there can be a man in the
middle. The idea is to do the authentication once the encrypted channel has
been established. Usually this is done by showing the other user's key
fingerprint, and that then has to be verified with the other user through a
secure channel, and once that's done you can tell OTR that the key is trusted.
My point here is that there are two "modes" of a key and encrypted sessions
established against that key:

  * secure/authenticated/trusted or whatever you want to call it
  * insecure/unathenticated/untrusted

There's no technical difference between the two, the crypto is the same. The
distinction is just for making the user aware of whether the key has been
authenticated or not. So, just to be clear, when OTR is enabled the first time
ever with another user, an insecure encrypted session is always started. If
that session is ended and a new one is started at some later point it will also
be labelled as insecure. However, once the user have explicitly said that a key
is trusted (by verifying the fingerprint) the current and all future sessions
are labelled secure.

With respect to the above I suggest the below:

* Each started OTR session should show whether the session is Secure or
Insecure directly in the chat dialog. A short pointer how to do authentication
may be shown if the session is insecure.

* The GUI icon should have three modes:
  1. No OTR
  2. Insecure
  3. Secure

* When a key/fingerprint is authenticad, the state is immediately changed to
state 3 for any active session using that key.

* The context menu should include:
  - "Start/Refresh private conversation" - which start a new OTR session if
there is none, or refreshes (end + start) the current one if there is a
session.
  - "End private conversation" - which terminates the current OTR session.
  - "Authenticate <the other user's nick>" - which opens a prompt described
below.
  - Checkbox: "Enforce OTR with <the other user's nick>" - see below.

* The authentication prompt should briefly which explain authentication and
show your and the other user's key fingerprint. There should be a button or
something similar that upgrades the trust level of the other user's key (and
the current

* There are other modes of authentication than comparing fingerprints. Pidgin,
for instance, has a mode where one of the users in a session can specify a and
if the other user gives the right answer both users upgrade their trust of the
other's key to secure. You might want to look into that, I guess it has support
in libotr.

* It would be nice to have the option (possibly in the context-menu) to select
users for which OTR sessions should be enforced and enabled automatically. I.e.
when you send a message to such a user when there's no OTR session, that
message and any following messages are queued on hold, and a OTR request is
sent instead. Once the OTR session has started, the messages in the queue are
sent, now encrypted. Something similar should happen if you receive a message
from such a user when there's no OTR session: an OTR request is sent
automatically.

* In many implementations I've seen there's a race-condition if you try to
start an OTR session at the same time as the other user is, or if you send two
OTR requests rapidly (especially if you have OTR enforcement enabled like
described above). This can either result in that the session is never started,
freezing in some state, or a flood of started-ended/refreshed sessions. Hence I
think you'd be wise to have locks or something to prevent more than one OTR
request to be handled at the same time. I.e. as soon as you receive and OTR
request from a user, you can't send OTR requests to that user until it has
finished or timed out. Similarly, if you have sent an OTR request to a user you
can't send any more until it has finished or timed out.

* If you receive an OTR request but have no key, a key is automatically
generated, and the user is informed that this happens. The same happens if you
send an OTR request but have no key.

* On disconnect all OTR sessions should be terminated. If a user you have a OTR
session with disconnects, that OTR session should terminate. If a user ends the
OTR session with you, your session should also terminate automatically.

* If an unencrypted message is received during an OTR session, that should be
made very clear some how. This is quite common with away messages for some
reason, so...

* Away messages should also be sent through OTR (in order to avoid unencrypted
messages of the type mention in the item above).

The pidgin-otr plugin for pidgin handles OTR in a very good way. I recommend
you to check it out to get a feel for it and a clearer picture of what a good
implemention looks like. But pidgin-otr has some issues but if you implemented
all the points I listed above you'd avoid them.

Cheers!

-- 
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.