Hello Werner, Romain,
I've finally commited the updated SC code, containing the implementation of the GoClear-GoSecure enhancement for ZRTP4J on which I've been working. I've tried to detail the main additions/modifications and how they are implemented on my dev blog ( http://sipcommkeysharing.blogspot.com/ ) in the entry made this Tuesday. In addition to what is specified there ( hope it's not too long and boring ), in the last two days I also fixed the GUI part problems mentioned, so the version present now on the SVN encryption branch is pretty much a fully working implementation.
About the GUI part, I pretty much redesigned the way this is handled inside the code, also regarding to what was done until now. For short, in terms of usability, the padlock button works as it did until now for calls which are not going to be unsecured by a GoClear message. This means, every user can start the call secured or unsecured according of how the button is pressed or not, and can secure it afterwards (if the peer did it of course). The GoClear - GoSecure addition makes possible now that the users can switch to unsecured mode after a call is secured and back to secure mode (with respect to the ZRTP specifications of course). In terms of usability, when an user switches to unsecured mode does it also through the same padlock button by unpressing it. This causes the peer's padlock button also to become unpressed when the call is unsecured. Switching back to secure mode is done as expected by pressing the padlock button again. However, the difference in this case is that the peer's button is again automatically toggled on, not needing the peer to do this. So, the use case when an user switches to secure mode and the call is secured later, when the peer toggles the button too, applies only for the first call securing during a session. (Actually I think this is probably the only possible way for implementing this feature. After all it is based on the fact that at the call beginning, the first peer remains in detecting state after switching to secure mode, and the other initializes later the engine. In case of re-securing the call, this is done at this moment, according to the specifications, by directly sending a Commit packet which leads to immediately re-securing the call). To summarize, probably will be more clear when you actually will see it :).
Ok, all this was a presentation related only to how the padlock button works at this moment in terms of usability. The actual implementation behind it, is more complicated (and maybe could be simplified a bit), and is not presented along with the GoClear-GoSecure additions to ZRTP4J on my blog. I won't describe it here because it will take too long. I'll try detailing it in my next blog entry (probably next week). I needed to make some additions to various classes in order to do it, but I tried and finally almost managed not to change any code from the ZRTP4J packages to acomplish it (it is after all the SC GUI part and should not be related too much with ZRTP4J). However I needed to add an init function to the ZrtpUserCallback class which I've called from ZrtpTransformEngine.
I've done many changes on how the GUI was implemented until now, like adding a source (local, remote) parameter for the SecureEvent dispatched to CallSessionImpl, and others. The most important change was, I think, removing the button code from the quick menu, and integrating it along with the label inside the ZRTPGUI plugin (The components are however placed where they were before on the SC interface, but now are both in the same plugin separate from the SC menus GUI code). I think, I've detailed already pretty much for a short overview. I'll try to add next week on my blog, as I said, a description of how GUI works.
At the moment I managed to perform several successful tests by switching off and on the call in various sequences. There are however some points related to ZRTP on which I'm not totally certain, as I described on my blog. Many of them are related with the exception/error handling conditions present in the additions done to the state engine (there are actually probably some crash or unexpected behavior chances, if SC gets in such a situation - like an error or exceeded timer). I didn't had the time yet to reanalyze those points but I'll try to do it this weekend, and make a list with what isn't totally clear.
I didn't tested yet using the no-registrar mode, but I don't think there will be any difference, the changes not being related to that.
To Werner: if you need it, my latest no-registrar patch can be found at http://students.info.uaic.ro/~eonica/sc/no-registrar.patch ; I didn't apply it on this branch version but there are 90% chances, I think, to be compatible with it; if you try to use it and encounter any problems please mail me about it.
The bottom line ( to end this already-another-too-long mail ), is for now that the GoClear - GoSecure ZRTP enhancement seems to be pretty stable (at least for the tests I've done, hope will be the same after the next).
"Life is full of unexpected but nothing happens without a reason..."
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com