Add OTR support to KVirc

[DarthGandalf]

Reported by asn on 20 Jun 2011 16:21:12 UTC http://www.cypherpunks.ca/otr/

---

Migrated from: https://svn.kvirc.de/kvirc/ticket/1163

[DarthGandalf]

Comment by HelLViS69 on 28 Jun 2011 09:06:59 Give a look to Bitlbee network

---

Version: 4.0.4 Insomnia → 4.1 Equilibrium

[DarthGandalf]

Comment by Gaming4JC on 21 Feb 2012 02:49:25 Adding myself to the CC. This would definately be useful as about a dozen people I know of are using OTR now. Painful trying to bootup Pidgin or Adium just to chat.

[un1versal]

zhr0 commented 25 days ago

Would like to request otr on crypt list of kvirc or some way of implementation

below some IRC clients that can have it added

-irssi via https://github.com/cryptodotis/irssi-otr -weechat via /script install otr.py https://weechat.org/scripts/source/otr.py.html/ or https://github.com/mmb/weechat-otr -hexchat via https://github.com/TingPing/hexchat-otr or https://github.com/adhux/hexchat-otr and https://github.com/HextorIRC/hextor-otr -pidgin via https://otr.cypherpunks.ca/pidgin-otr-4.0.1.tar.gz -adium via https://adium.im/help/pgs/AdvancedFeatures-OTREncryption.html

---

Merged from https://github.com/kvirc/KVIrc/issues/1652

[OmegaPhil]

For reference, I'm starting to look into this now.

[OmegaPhil]

Right, I have done some reading into this now (thanks for the old links to the various implementations).

Integration of OTR does not seem to be an addon task (which would be implemented in KVS) - this is serious crypto, so it would make sense to use the most canon official implementation, which is the C library libotr - anything else would presumably be 'Baby's first crypto' by me, and naturally be utter shit from the security perspective (I have no real secure coding experience, some C experience, a little C++ experience for reference).

Looking at other crypto functionality in KVIrc, there is Fish/Mircyption and AES - these are implemented as C++ modules, custom for KVIrc, using the KVIrc cryptengine framework. Looking at the documentation for the latter, there is no initial key discovery/exchange functionality, which contrasts with OTR's defined protocol for flagging use of itself, authentication etc (see 'Requesting an OTR conversation).

So it doesn't feel like OTR can just be jammed into the current crypto framework (and even if I extended the framework for some sort of key exchange, libOTR would presumably be 'too separate' from the KVIrc C++ to really be a part of it anyway).

So it feels like to get any hope of a good implementation, libOTR should get wrapped and used direct, presumably forming another module (perhaps forked from irssi's implementation, since that software has the best reputation perhaps?).... looks like KVIrc's Python integration would be a good example of integrating a C library, looks like a lot of study needed to understand it.

@pragmaware | @ctrlaltca : You've worked on the KVIrc cryptoframework + modules some time ago, what do you think of the above?

[IceN9ne]

there is no initial key discovery/exchange functionality

The fish module in KVIrc does a DIffie-Hellman 1080 key exchange with fish.keyx. All key exchange messages for IRC OTR will likely be done with either PRIVMSG or NOTICE, as I doubt it's implemented with DCC by other clients, although I haven't checked.

I can't foresee why this couldn't be added as an otr module that still uses the KviCryptEngine, but is conditionally built by using a FindLibOTR.cmake and some #ifdefs. Using libotr is the correct way to go about this. This might actually be a module more similar to the fish module rather than the rijndael module.

[OmegaPhil]

Sorry, where is 'fish.keyx' in the source?

Edit: I'm a retard, was looking at something else.

[OmegaPhil]

Right, the fish module looks quite odd - I don't see where it implements the decrypt and encrypt functions - but I can see it dealing with key exchange detection inline with fish_event_onQueryNotice, and triggering it manually this end with fish_cmd_keyx.

Waiting on any comment from pragma/CtrlAltCa or a week timeout before I start doing some damage.

[IceN9ne]

The fish module only adds the keyx functionality. It creates a KviCryptEngine using the Mircryption engine (that is sourced in the rijndael module) and instantiated from the keys derived from the keyx.

In your otr module, you'd need to add the key exchange handling and derive a new class based on the KviCryptEngine to handle the encrypt/decrypt.

[OmegaPhil]

Ah right, I could see blowfish mentioned in there (and in the fish code it also references a version from OpenSSL??) but didn't see how it linked/is used. Thanks.

My first task will be to see how to compare the irssi implementation, since thats a bonafide OTR implementation over IRC - once thats done I'll be able to understand how to shoehorn it into the cryptoframework here.

[IceN9ne]

The use of OpenSSL in the fish module can be seen in these lines:

#include <openssl/blowfish.h>
#include <openssl/bn.h>
#include <openssl/dh.h>
#include <openssl/err.h>
#include <openssl/ssl.h>
#include <openssl/sha.h>
...
BIGNUM * dhp = BN_new();
BN_init(dhp);
if(!BN_hex2bn(&dhp, g_fish_prime1080_hex))
...

Also, its library inclusion is in the CMakeList.txt using find_package(OpenSSL) and setting the results as needed with cmake.

include_directories(${OPENSSL_INCLUDE_DIR})
list(APPEND LIBS ${OPENSSL_LIBRARIES})
set(COMPILE_SSL_SUPPORT 1)

Edit: Oh, I think you were asking about the OpenSSL's blowfish, not how the libs were done. I don't think OpenSSL's blowfish is actually used in the fish module. It might be left over from when it was originally written.

[OmegaPhil]

I have been thinking of starting off with irssi-otr, dumping it into the KVIrc OTR module, porting it to the cmake build system (it uses autotools atm), updating KVIrc with the build dependencies (libotr, glib2.0, libgcrypt), and then making it at least build, prior to hooking it up with KVIrc proper.

But this is meaningless if its unacceptable to have a blob of C code in the C++ codebase? The intention was that I keep the code as code to upstream as possible, so that upstream changes could be almost directly applied in the future.

If C is unacceptable, then I guess I would keep the structure and rewrite it in KVIrc C++, with the risk of introducing bugs.