475
Comment:
|
4431
refactored page
|
Deletions are marked like this. | Additions are marked like this. |
Line 1: | Line 1: |
= Get OTR to work with bitlbee = Bitlbee has no native support for OTR but there are custom versions that include OTR functionality (sadly you have to compile your own bitlbee) |
= OTR with bitlbee = |
Line 4: | Line 3: |
some versions that include OTR Support: | Off-the-Record Messaging, commonly referred to as OTR, is a cryptographic protocol that provides strong encryption for instant messaging conversations. OTR uses a combination of the AES symmetric-key algorithm, the Diffie–Hellman key exchange, and the SHA-1 hash function. In addition to authentication and encryption, OTR provides perfect forward secrecy and malleable encryption. |
Line 6: | Line 5: |
* Original (outdated!) http://khjk.org/bitlbee-otr/ * One current version http://github.com/abbe/bitlbee-otr * Another current version http://wahjava.wordpress.com/ |
!BitlBee supports OTR natively since 3.0, but it's an optional component. |
Line 10: | Line 7: |
== Why is it that OTR is not supported upstream? == | Note that this requires running your own !BitlBee. OTR functionality '''should not ever be offered on any public server''' as it only gives a false sense of security! It is important to note that if you have logging turned on for !BitlBee then your OTR messages are in vain. Also they could trace your connections via your network connection. |
Line 12: | Line 9: |
because | For more information on how to use OTR, see {{{help otr}}} and other existing documentation. |
Line 14: | Line 11: |
* ... | == Enabling OTR support == When using distro packages, there is hopefully a {{{bitlbee-plugin-otr}}} package you can install. When compiling your own !BitlBee, pass {{{--otr=1}}} or {{{--otr=plugin}}} to the configure script. You'll need the right version of the OTR library installed, with its development headers. See the following table for details. === Version reference === Since the OTR versions seem to be a bit confusing, here's a nice table explaining ''absolutely everything''. || '''Protocol''' || '''Library''' || '''.so name (ABI version)''' || '''Debian package''' || '''Supported bitlbee releases''' || '''Supported bitlbee bzr''' || || [[https://otr.cypherpunks.ca/Protocol-v2-3.1.0.html|v2]] || libotr 3.2.1 || {{{libotr.so.2.2.1}}} || [[http://packages.debian.org/sid/libotr2|libotr2]](-dev)|| 3.0 ... 3.2.1 || <=1000 || || [[https://otr.cypherpunks.ca/Protocol-v3-4.0.0.html|v3]] || libotr 4.0.0 || {{{libotr.so.5.0.0}}} || [[http://packages.debian.org/sid/libotr5|libotr5]](-dev)|| ''none yet''' || >=1001 || == OTR-related settings == * {{{otr_policy}}} * Possible values: never, opportunistic, manual, always * This setting controls the policy for establishing Off-the-Record connections. See the next section for details. * {{{otr_color_encrypted}}} * If set to true, !BitlBee will color incoming encrypted messages according to their fingerprint trust level: untrusted=red, trusted=green. * {{{otr_does_html}}} * No one really knows what this does, but it's been suggested that it means "Web frontends use web technologies". {{{/* FIXME */}}} == OTR policies == * {{{never}}}: disables the OTR subsystem. * {{{opportunistic}}}: A magic whitespace pattern will be appended to the first message sent to any user. If the peer is also running opportunistic OTR, an encrypted connection will be set up automatically. * {{{manual}}}: OTR connections must be established explicitly using {{{otr connect}}}. * {{{always}}}: enforces encrypted communication by causing !BitlBee to refuse to send any cleartext messages at all. The "magic whitespace pattern" that opportunistic OTR uses consists of 16-40 bytes of either space or tab characters (See the "Tagged plaintext messages" section of the [[https://otr.cypherpunks.ca/Protocol-v3-4.0.0.html|OTR spec]] for more details). This might cause minor visual issues in some IM clients. == Simple Question and Answer Response == You can authenticate a user's fingerprint by asking a question using the {{{otr smpq}}} {{{ #!irc <@alice> otr connect bob <@alice> otr smpq bob "question question question" answer <@root> smp: initiating with bob... }}} On the other side: {{{ #!irc <@root> smp: initiated by alice with question: "question question question" <@root> smp: respond with otr smp alice <answer> <@bob> otr smp alice answer <@root> smp: responding to alice... <@root> smp alice: secrets proved equal, fingerprint trusted }}} == Issues == OTR does NOT work (well) with offline messages. Without previous or future chat-session, offline messages from either party will not be passed on and no notification will be sent. OTR messages are only being delivered in these scenarios: 1. User "A" and "B" are in an OTR session, when "B" is disconnecting. Messages from "A" are being delivered after "B" reconnects. 1. User "A" is attempting an OTR session with the offline-user "B", when "B" is connecting while "A" is still online. |
OTR with bitlbee
Off-the-Record Messaging, commonly referred to as OTR, is a cryptographic protocol that provides strong encryption for instant messaging conversations. OTR uses a combination of the AES symmetric-key algorithm, the Diffie–Hellman key exchange, and the SHA-1 hash function. In addition to authentication and encryption, OTR provides perfect forward secrecy and malleable encryption.
BitlBee supports OTR natively since 3.0, but it's an optional component.
Note that this requires running your own BitlBee. OTR functionality should not ever be offered on any public server as it only gives a false sense of security! It is important to note that if you have logging turned on for BitlBee then your OTR messages are in vain. Also they could trace your connections via your network connection.
For more information on how to use OTR, see help otr and other existing documentation.
Enabling OTR support
When using distro packages, there is hopefully a bitlbee-plugin-otr package you can install.
When compiling your own BitlBee, pass --otr=1 or --otr=plugin to the configure script.
You'll need the right version of the OTR library installed, with its development headers. See the following table for details.
Version reference
Since the OTR versions seem to be a bit confusing, here's a nice table explaining absolutely everything.
Protocol |
Library |
.so name (ABI version) |
Debian package |
Supported bitlbee releases |
Supported bitlbee bzr |
libotr 3.2.1 |
libotr.so.2.2.1 |
libotr2(-dev) |
3.0 ... 3.2.1 |
<=1000 |
|
libotr 4.0.0 |
libotr.so.5.0.0 |
libotr5(-dev) |
none yet |
>=1001 |
OTR-related settings
otr_policy
- Possible values: never, opportunistic, manual, always
- This setting controls the policy for establishing Off-the-Record connections. See the next section for details.
otr_color_encrypted
If set to true, BitlBee will color incoming encrypted messages according to their fingerprint trust level: untrusted=red, trusted=green.
otr_does_html
No one really knows what this does, but it's been suggested that it means "Web frontends use web technologies". /* FIXME */
OTR policies
never: disables the OTR subsystem.
opportunistic: A magic whitespace pattern will be appended to the first message sent to any user. If the peer is also running opportunistic OTR, an encrypted connection will be set up automatically.
manual: OTR connections must be established explicitly using otr connect.
always: enforces encrypted communication by causing BitlBee to refuse to send any cleartext messages at all.
The "magic whitespace pattern" that opportunistic OTR uses consists of 16-40 bytes of either space or tab characters (See the "Tagged plaintext messages" section of the OTR spec for more details). This might cause minor visual issues in some IM clients.
Simple Question and Answer Response
You can authenticate a user's fingerprint by asking a question using the otr smpq
On the other side:
Issues
OTR does NOT work (well) with offline messages.
Without previous or future chat-session, offline messages from either party will not be passed on and no notification will be sent. OTR messages are only being delivered in these scenarios:
- User "A" and "B" are in an OTR session, when "B" is disconnecting. Messages from "A" are being delivered after "B" reconnects.
- User "A" is attempting an OTR session with the offline-user "B", when "B" is connecting while "A" is still online.