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 <[email protected]> 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 > [email protected] > http://lists.cypherpunks.ca/**mailman/listinfo/otr-dev<http://lists.cypherpunks.ca/mailman/listinfo/otr-dev> >
_______________________________________________ OTR-dev mailing list [email protected] http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
