[OTR-dev] libotr/pidgin-otr 4.0 beta

[Chris Ballinger]

Awesome, great work!

Have you guys considered releasing the protocol reference implementation
libraries (libotr and/or java-otr) under an academic free license like
MIT/BSD/Apache2 and/or using libcrypto instead of libgcrypt?

On Wed, May 2, 2012 at 3:00 PM, Rob Smits <rdfsmits at cs.uwaterloo.ca> wrote:

> Hey,
>
> I've just pushed a beta of libotr and pidgin-otr 4.0 into a new
> sourceforge git. This was delayed as we decided to separate the
> repositories into:
> git://otr.git.sourceforge.net/**gitroot/otr/libotr<http://otr.git.sourceforge.net/gitroot/otr/libotr>
> git://otr.git.sourceforge.net/**gitroot/otr/pidgin-otr<http://otr.git.sourceforge.net/gitroot/otr/pidgin-otr>
> git://otr.git.sourceforge.net/**gitroot/otr/otrproxy<http://otr.git.sourceforge.net/gitroot/otr/otrproxy>
> git://otr.git.sourceforge.net/**gitroot/otr/java-otr<http://otr.git.sourceforge.net/gitroot/otr/java-otr>
>
> The old repository (git://otr.git.sourceforge.**net/gitroot/otr/otr<http://otr.git.sourceforge.net/gitroot/otr/otr>)
> will be removed soon, and instructions on the sourceforge page will be
> updated.
>
> Ian Goldberg and I have done a code review for libotr, but we have not yet
> looked at pidgin-otr. We'll hopefully be reviewing pidgin-otr over the next
> couple weeks. That isn't to say that libotr 4.0 does not currently have
> bugs either ;).
>
> Also notably outstanding are libotr/UPGRADING and libotr/Protocol-v3.html,
> which will be coming soon. The translations for pidgin-otr also need some
> updates.
>
> CHANGES:
>
> -Instance tags (libotr, pidgin-otr, protocol)
> The protocol change, and the most significant change in libotr/pidgin-otr
> is the inclusion of client instance tags. Clients generate instance tags
> that are intended to be persistent. If the same client is logged into the
> same account from multiple locations, the intention is that he or she will
> have different instance tags at each location. OTR wire messages
> (fragmented and unfragmented) include the source and destination instance
> tags after the OTR/fragment header portion. If a client receives a message
> that lists a destination instance tag different from his own, he will
> discard it (and issue a callback notifying the application of the event).
>
> This avoids an issue on IM networks that always relay all messages to all
> sessions of a client who is logged in multiple times. In this situation,
> OTR clients can attempt to establish an OTR session indefinitely if there
> are interleaving messages from each of the sessions.
>
> The API changes here allow you to specify a particular instance in
> otrl_message_sending, or a "meta-instance" like OTRL_INSTAG_RECENT. Each
> instance of a buddy has its own ConnContext. There is a "master context"
> for a particular buddy, which is used before you know any of their
> instances. This is also the context that gets used for OTR v2 conversation.
>
> In pidgin-otr, a special menu gets built for buddies who you have multiple
> OTR v3 sessions with. This allows you to select a particular instance, the
> "most secure" or most recent.
>
> Note that instances do add some uncertainty when dealing with IM networks
> that only deliver messages to the most recently active session for a buddy
> who is logged in multiple times. If you have a particular instance
> selected, and the IM network is simply not going to deliver to that
> particular instance, there isn't too much we can do. Pidgin-otr will warn
> you when you have selected an instance that is not the most recent, but
> will not try to guess network behaviour.
>
> -Asynchronous private key generation (libotr)
>
> Key generation can happen in a separate thread without blocking an
> application.
>
> -Extra symmetric key (libotr, protocol)
>
> An extra symmetric key can be easily established when creating a data
> message. The intention here is establish a key that could be used for
> things like a file transfer, in some other channel of communication. There
> is a small protocol change here since we define a new TLV type for this.
>
> -Fragmentation changes (libotr)
>
> Functions that create new messages to be sent (e.g., otrl_message_sending)
> can fragment and send for you, without requiring a separate call to
> otrl_message_fragment_and_send (this function is no longer exposed in the
> API).
>
> -Callback events (libotr)
>
> There are now callbacks for SMP events, error codes, and message events
> that simply pass an event type (instead of an English string).
>
> -Convert ops (libotr)
>
> There is now a callback that is made immediately before a message is
> encrypted and immediately after a message is decrypted. This callback can
> tweak the plaintext message as needed. The original use case for this was
> to allow an application to convert format tags (if this would normally be
> done on the plaintext by some other entity while the message is in transit).
>
> -Logging changes (pidgin-otr)
>
> When establishing a private conversation, pidgin-otr will also output
> whether or not pidgin is logging the conversation. The default behaviour
> will now turn off logging for otr conversations.
>
>
> Please have a look, try things out and help us find bugs! Also keep an eye
> out for the code-reviewed version of pidgin-otr, and the updated documents.
>
> Thanks!
> Rob Smits
>
>
>
> ______________________________**_________________
> OTR-dev mailing list
> OTR-dev at lists.cypherpunks.ca
> http://lists.cypherpunks.ca/**mailman/listinfo/otr-dev<http://lists.cypherpunks.ca/mailman/listinfo/otr-dev>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cypherpunks.ca/pipermail/otr-dev/attachments/20120502/4dbc33aa/attachment.html>