| Summary: | Off-the-Record (OTR) encryption support | ||
|---|---|---|---|
| Product: | [Applications] konversation | Reporter: | lurker <lurker> |
| Component: | encryption | Assignee: | Travis McHenry <wordsizzle> |
| Status: | ASSIGNED --- | ||
| Severity: | wishlist | CC: | asn, hein, jessie, justusranvier, kde-bugtracker, konversation-devel, Neustradamus, ry, yesyoucanspamme |
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | unspecified | ||
| OS: | All | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
| Bug Depends on: | 139849 | ||
| Bug Blocks: | |||
|
Description
lurker
2010-10-20 12:06:49 UTC
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. 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. Let me know what you think of that, and I'll get started on it. (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! (In reply to comment #2) > * 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. I retract all this. Any of the above could lead to users sending unencrypted messages by mistake. OTR sessions should always have to be terminated manually (or when konversation terminates, of course). I guess it's still saft to terminate OTR sessions for an account that disconnects, but that's not so useful, so I think it's better to stick with manual OTR session termination only. Any news on this? I'd really love to have OTR for IRC. Lurker did some great leg work on this and I'm ashamed to say I forgot about it. I will be implementing this, How soon? I have no idea, it depends on if I can use libotr or if I decide to reproduce it with QCA, i'll be doing some research over the next couple of days. So it looks like we'll have to reproduce it with QCA, it's really similar to the DH1080 key exchange we already use but with some added security and anonymity. Unfortunately there's no way to share code, so it's going to be some work. I've got it about half done, and I'll be doing the rest whenever I have free time. Any updates on this bug? Given recent events, not having working OTR support should be considered a major deficiency in any IRC client. I'm currently working on bug 139849 which is required to fix this bug. The OTR spec calls for storing long term DSA public keys, which konvi can't currently do. I might be able to knock that out this weekend, and then finish up the otr work. So I'd give it an eta of Soon^tm. For storing the keys of other people I'm leaning towards creating them as contacts in kdepim, and storing them in Akonadi by porting the current nick/contact association stuff. Does anyone who's following this find that objectionable? I guess some people don't like Akonadi..but the alternative is...messy. ^ Hm, we had actually envisioned the new kpeople lib as the porting-to target for the address book integration these days ... 2 years later ... Any news after this long time? Afraid not. |