Initial Commit err.. Thoughts!

Hello World!

In this post, I will try to present my initial thoughts on how will I be implementing the OTR messaging project.

OTR Protocol Very High Level Overview

OTR assumes a network model which provides in-order delivery of messages, but that some messages may not get delivered at all (for example, if the user disconnects). There may be an active attacker, who is allowed to perform a Denial of Service attack, but not to learn the contents of messages.

• Alice signals to Bob that she would like (using an OTR Query Message) or is willing (using a whitespace-tagged plaintext message) to use OTR to communicate. Either mechanism should convey the version(s) of OTR that Alice is willing to use.


• Bob initiates the authenticated key exchange (AKE) with Alice. Version 2 of OTR uses a variant of the SIGMA protocol as its AKE.


• Alice and Bob exchange Data Messages to send information to each other.

This text is taken from the OTR protocol description here.

Implementation

Overview

I plan to split my development efforts into two parts. The first part will be building a new reusable Java library for OTR (otr4j) and the second part incorporating that library in SipCommunicator.

Java library for OTR - otr4j

OTR4j architecture will be service driven, i.e. you have a state object, e.g. OtrlUserState, that you pass over to a service, e.g. MessageServiceImpl, with other required parameters for the service to work. I have already uploaded a skeleton of the library in Google Code http://code.google.com/p/otr4j/. Nothing functional yet, just a bunch of interfaces that may change in the future.

SipCommunicator Integration

SipCommunicator is build on top of Felix, so it makes sense to integrate the otr4j via an OSGi bundle, therefore the integration should be as simple as creating an OtrActivator class (I don't include it here because it would make the post too lengthy... )
This class is only a tiny tiny tiny (...) draft of the final OtrActivator and it doesn't have any GUI hooks, it just implements the BundleActivator interface that is required for the class to be an OSGi bundle and MessageListener and ServiceListener to hook to the inbound/outbound message traffic.

All of the above writing is “near to theory”, issues for further discussion will arise as soon as actual coding starts.