Arsenal selection

I feel much more productive in Eclipse, and I also find it less obtrusive so I switched back to it.

A promising plugin, unfortunately not officially supported, for integrating Mercurial with Eclipse exists, and I installed it. IMHO the plugin is very nice and clean (I downloaded the source) BUT -as it usually happens..- I did some wrong clicks here and there and I messed up my source tree..

Then (in a bright moment I guess..) I thought I'd better switch to the command line (, I am aware of TortoiseHg, but I want my terminal back!) where I can have full control of what I’m doing (step by step..). So there I was, back at the beginning, using Eclipse and the command line :D and as I had already lost quite some time clicking around the various windows, I got back to work.

Finally (and thankfully..), I completed my changes and I wanted a tool to compare the diffs. I wanted a tool that would do folder diffing/directory diffing/folder compare/”call it what you like”, because I had done many changes and I wanted an overview picture of them.

I stumbled upon this stackoverflow post which led me to use WinMerge, because it is free, and even better it’s open source! I had to download the setup executable to get it to work because WinMergeU.exe depends on MFC7.1 and I could not find the the Microsoft VC++ 2003 Redistributable Package. The tool works fine, in fact it works great and I liked a lot.

If anyone wants to use WinMerge add this to the Mercurial.ini:

[extensions]
hgext.extdiff =
[extdiff]
cmd.wmdiff = C:\Program Files\WinMerge\WinMergeU.exe
opts.wmdiff = /r /e /x /ub

and then run hg wmdiff

But, (in yet another bright moment I guess..) I thought I’d try SourceGear’s DiffMerge which am used to it’s coloring conventions. This tool has folder diffing/directory diffing/folder compare/”call it what you like” and most importantly, it seemed to be a little faster than WinMerge.

If anyone want to use Sourcegear’s DiffMerge tool add this to the Mercurial.ini:

[extensions]
hgext.extdiff =
[extdiff]
cmd.sgdm = C:\Program Files\SourceGear\Vault Client\sgdm.exe

and run then hg sgdm

That’s all with my arsenal selection. If you ask me, it was a little boring to do all this stuff, but one has to do changes to his development toolset from time to time :-)

Have you checked out some cool features of NetBeans?

I wanted an overall picture of otr4j, so I thought a good idea would be to create a class diagram.

Initially, I checked what's the Eclipse way of doing this. It seems although there are tools for modeling in Eclipse, they don't support reverse engineering source code into UML diagrams, so I thought "this must be something Eclipse developers do with some 3rd party -not very expensive- application..".

I browsed the web for a while, but found nothing standard except from ArgoUML maybe (one should define standard off course..). I eventually settled with NetBeans.

I was aware of the fact that NetBeans has support for reverse engineering Java Applications but didn't consider using it from the beginning because I wanted to build up my existing Eclipse skills.

The good stuff about NetBeans don't end here, it even has Mercurial support by default, which made me want to use Mercurial and let me be productive at the same time. Apparently I was very wrong about NetBeans..

I got so excited that I just made a question in the post where Mercurial support for Google Code has been announced, asking when it will go public. Now that Mercurial is working for me, I want to push my change sets!

Progress by June 04

I think it's about time for another update on the otr4j library development progress..

First of all, a new dependency has been added, the BouncyCastle Java Cryptography Library.

The default security provider fails to generate a D-H KeyPair with a modulus larger than 1024 bits with the following message: "Prime size must be multiple of 64, and can only range from 512 to 1024". OTR uses a specific 1536 bit prime, so incorporating the BouncyCastle library was inevitable.

Furthermore, I have revisited some of the methods for assembling/disassembling the various OTR messages. I mostly changed the method signatures, for example instead of passing BigIntegers and byte arrays, I now pass DHPublicKey or PublicKey interfaces, which seems to be a better choice for cleaner code.

I have also made progress on handling state transitions, but this area still needs a lot of work.

I expect that by June 10 (next Wednesday) there will be proper code structure for state transition handling and that the library will successfully "receive" (through test cases) plain text (with or without whitespace tags), query messages, error messages, D-H commit messages and D-H key messages.

Lastly, I started using Mercurial, so to run the code (the tests) you must have mercurial to import the repository. The code for this preview release is available here.

Progress by May 26

Assembling/Disassembling of all OTR messages is now supported. All operations are accompanied by the corresponding test units.

I have also started working in handling state transitions.. It starts to get exciting!!

This is the direct link to this preview release.

P.S. As I read my previous blog posts, it seems that the post length is reduced over time; I want to believe that this is because the actual code length increases..

Progress by May 20

The library can now disassemble all message types except tagged plain text messages. Whoever is interested in the library can download it from the project home page here: http://code.google.com/p/otr4j/ or use this direct link.

Unit testing and logging has been implemented for the so far functionality, so you can extract the library somewhere, run

ant junit

and see what happens.

First term Planning

Here I present a first plan of the first term period. Numbered items correspond to top level requirement items. Also, dates are maximum values, hopefully it won't take that long!

• Develop a java library that handles encryption (see The current state of OTR libraries in Java)
  • Build methods to Assemble/Dissasemble OTR Messages and tests to verify things work properly
    • OTR Query Messages
    • Tagged plaintext messages
    • OTR Error Messages (May 20)
    • D-H Commit Message
    • D-H Key Message
    • Reveal Signature Message
    • Signature Message
    • Data Message (May 25)
  • Handle state transitions for the following actions (detailed description of state transitions here),build key management infrastructure (NOTE: key management for the library, not SC) and build tests to verify things work properly
    In this period functionality for Requesting an OTR conversation, Authenticated Key Exchange (AKE), and Data Exchange will be added.
    • Plaintext message without the whitespace tag
    • Plaintext message with the whitespace tag
    • Query Message
    • Error Message
    • D-H Commit Message
    • D-H Key Message (June 10)
    • Reveal Signature Message
    • Signature Message
    • Version 1 Key Exchange Message
    • Data Message
    • User requests to start an OTR conversation
    • User requests to end an OTR conversation
    • User types a message to be sent (June 25)
• Create a transformation operation set
• Implement support for the transformation set in all protocols
• Implement an OTR encryption bundle prototype/proof of concept that encrypts all conversations (July 05)

Comments and critiques are very welcome :-)

The current state of OTR libraries in Java

Existing Implementations

• jOTR is a Java framework that provides the base functionality for OTR (Off The Record) support. It is intended to be a java version of the c-based libotr, and be completely compatible with it. Sounds great but, there is no source code although the project is more than a year old.

• Ian Goldberg, lead developer of the OTR development team, mentions an otr library for Java (java-otr) (here) that is in the workings. There is no source code or binaries, only a mentioning so I sent a follow up mail (here) with no reply, so we can't rely on this.

• libjotr ibjotr is a Off-The-Record library in native java. It was developed for libkara but can also be used with other applications written in java. This seems to be the first and only existing implementation for OTR in Java. libjotr is working but it will be hard to use it with an other messenger than kara without modfying the API. It is also OTR v2 only. No support for Version 1. These information are confirmed by Markus, libjotr developer.

OTR4j

Having considered the above solutions, I plan to develop my own library (otr4j) for integration with SipCommunicator and any other IM, as described in my initial post.