[sip-comm-dev] ZRTP integration update, GUI issues, and minor problems


#1

Hello Romain, Werner and Yana,

I've posted a new entry on my blog http://sipcommkeysharing.blogspot.com/ related to the progress I made since last week with Werner's library integration. Also the last sources version are there. I'll try moving them on the svn branch (thank you Emil for it) this week.

I know it's a long entry :slight_smile: but when you got the time please take a look at it, as I need a bit of feedback on some issues.

To Werner: some feedback needed about the GUI components ZRTP4J should use
and some feedback needed on the way I "bound" SC to ZRTP4J at this moment

To Romain: some feedback needed also on the current approach of how SC integrates and uses ZRTP4J

To Yana : sorry to bother you too :slight_smile: but I really need some feedback on some GUI issues (some of them already done and some of them needed to do);
I know all that long entry probably wouldn't be of much interest to you so to get it shorter: the GUI problems are discussed in the first part (above the picture) and immediately after the long bulleted list

To all : I'm stuck at this moment at a classpath/import/or something like that I think issue, which is described at the end of the entry; hopefully I'll go past it soon, but if someone has an idea about the reason for it until I figure it out myself will surely speed up the process :slight_smile:

All these detailed on the blog.

Regards,
Emanuel

路路路

--
--------------------------------------------------------------------

"Life is full of unexpected but nothing happens without a reason..."

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#2

Just browsed your blog - impressive work done :slight_smile: .

I'll have a loook at the patches in more detail and give
you feedback.

For the GUI desing: just create some buttons or text fields
that we required - for example to show the SAS and verifiy the
SAS.

The ZRTP4J library does not support goClear/goSecure - it's
optioal AFAIK, thus no need to implement this for now.

Regarding start of ZRTP: ZRTP4J has an "autosensing" mode. If
you call the initialize method setting the "autoEnable" parameter
to true the ZRTP4J prepares itself to start. As soon as it sees
traffic on the RTP session (at least on packet was sent and
one received) it automatically starts ZRTP negotiation. This
way ZRTP knows the both clients are up and RTP is established
and it can start ZRTP. This prevents unnecessary timeouts or
ZRTP restarts. Thus you probably don't need to call startZrtp().
You may have a look at the GNU ZRTP Howto:
<http://www.gnutelephony.org/index.php/GNU_ZRTP_How_To>

About the overall path you describe in your blog this seems
ok to me. Also to bring back SRTP into SC is good, I planned to
provide a patch to bring back the modifications I did. There
were a design problem in the InputSource as far as I can remember,
also some optimizations with respect to byte array handling.

I can remember there were some problems when using an unmodified
BouncyCastle library, AFAIK Romain addresse this problem - and
it also wasn't it also an issues with class loading or alike?

Regards,
Werner

Onica S. Emanuel schrieb:

路路路

Hello Romain, Werner and Yana,

I've posted a new entry on my blog http://sipcommkeysharing.blogspot.com/ related to the progress I made since last week with Werner's library integration. Also the last sources version are there. I'll try moving them on the svn branch (thank you Emil for it) this week.

I know it's a long entry :slight_smile: but when you got the time please take a look at it, as I need a bit of feedback on some issues.

To Werner: some feedback needed about the GUI components ZRTP4J should use
and some feedback needed on the way I "bound" SC to ZRTP4J at this moment

To Romain: some feedback needed also on the current approach of how SC integrates and uses ZRTP4J

To Yana : sorry to bother you too :slight_smile: but I really need some feedback on some GUI issues (some of them already done and some of them needed to do);
I know all that long entry probably wouldn't be of much interest to you so to get it shorter: the GUI problems are discussed in the first part (above the picture) and immediately after the long bulleted list

To all : I'm stuck at this moment at a classpath/import/or something like that I think issue, which is described at the end of the entry; hopefully I'll go past it soon, but if someone has an idea about the reason for it until I figure it out myself will surely speed up the process :slight_smile:

All these detailed on the blog.

Regards,
Emanuel

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#3

Hello,

Just browsed your blog - impressive work done :slight_smile: .

Thank you for your response and for appreciation ! :slight_smile: There isn't really that much done :slight_smile:

I'll have a loook at the patches in more detail and give
you feedback.

For the GUI desing: just create some buttons or text fields
that we required - for example to show the SAS and verifiy the
SAS.

The problem is that I should know in essence if there are any other GUI elements which should be available to the user at any time during a call for an undetermined period (like the SAS) or if there are any other input GUI elements related to ZRTP on which the user can act whenever he/she desires not at specific moments required by the application (like some buttons or entry forms). As far as I know for the first there is only the SAS (but I might miss something) and about the last there aren't any cases (again I'm not 100% sure). If I'm correct all the other needed GUI elements could be implemented by popup dialogs easily with eventually the posibility for input - when the application requires a response from the user. To be sure I'm clear enough - in the other case, if the user is the one who can trigger an action at it's own initiative, at an unspecified time (again - I don't know any situations for this to happen - but I'm new to ZRTP) or other info like the SAS should be displayed for the user when
he/she desires or for indefinite time (so a popup isn't enough), I should start thinking on a SC GUI plugin to support all these.

Anyway, I'm thinking already at a GUI plugin for the SAS, but taking into consideration that is only one GUI element I'll wait a bit for a feedback from Yana, or other SC GUI developer on what I've written on the blog. Eventually I'm gonna make another quick "parse" of the standard to see if there are any other elements like the one described above.

(For Werner - in order to be more clear about what I said above:
- the SC GUI plugin is the normal way for adding GUI elements to SC interface - as much as I understood from the SC docs at least :slight_smile: ;
- the popups, confirms and data inputs as message boxes can be done without a GUI plugin ;
- the last way is adding directly other type of elements to the main GUI source code - as I did for the Secure Button, but that I think it should be only for essential GUI elements)

The ZRTP4J library does not support goClear/goSecure - it's
optioal AFAIK, thus no need to implement this for now.

I know that in the standard it says is optional but I saw some skeleton code (empty) functions in your code related to this and I thought it might be supported in the future, and anyway, after we have a first stable phase
which runs fine without GoClear :), I might take a thought on implementing
also this feature. So, for now I'll disable eventually from the code that part, but I'll let it there to enable for future support.

Regarding start of ZRTP: ZRTP4J has an "autosensing" mode. If
you call the initialize method setting the "autoEnable" parameter
to true the ZRTP4J prepares itself to start. As soon as it sees
traffic on the RTP session (at least on packet was sent and
one received) it automatically starts ZRTP negotiation. This
way ZRTP knows the both clients are up and RTP is established
and it can start ZRTP. This prevents unnecessary timeouts or
ZRTP restarts. Thus you probably don't need to call startZrtp().
You may have a look at the GNU ZRTP Howto:
<http://www.gnutelephony.org/index.php/GNU_ZRTP_How_To>

Thank you for the link and especially for reminding me that I missed something. I actually completely forgot to call initialize for the engine (probably I would have realized myself, but I didn't had the time yet to think more on the other problem I'm stuck at - hope I'll pass it today.. - so I haven't reached that point with the debugging)

I added another small patch with the engine initialization at:
http://students.info.uaic.ro/~eonica/sc/zrtp02.01.patch

Also the modified source is available at:
http://students.info.uaic.ro/~eonica/sc/patch02/src/net/java/sip/communicator/impl/media/CallSessionImpl.java
(lines 1563-1578)

(I know :slight_smile: I must move all this on the svn branch - gonna' do that soon)

The idea still remains as I said on my blog:
- if the user toggled secure communication before the start of the call session the initialization is made with auto-sensing in order to start ZRTP automatically (to avoid calling startZrtp when it's already started
in this case I've added the getter isStarted to the engine as I said on the blog)
- if the user didn't toggle the secure communication before the start of
the call session (so secure comm is off) the initialization is done without auto-sensing and ZRTP starts through the startZrtp method if the user toggles secure comm on during the call

I implemented it this way because as far as I recall from the standard it is said that the Discovery phase can start anytime - though usually at the session start; and after all I think it adds more flexibility in the user actions; otherwise - if I initialize the ZRTP engine with autosensing on at every call I don't know how the user could renounce at the secure comm - if for some reason desires it. In the way I've done the implementation the ZRTP connector is used for any call as long as ZRTP is registered as
a key management solution and has the top priority (which it does)- so the only other way to make unsecured comm calls would be to lower it and consequently choose normal RTP for transport - but in this case the user won't be able to toggle secure comm on during the call not having the connector present. So I think the described/implemented solution is better, having the communication made through the ZRTP connector and letting it pass normal RTP traffic as long secure comm is toggled off = engine not started (hope I'm correct about how it works internally :slight_smile: ).

About the overall path you describe in your blog this seems
ok to me. Also to bring back SRTP into SC is good, I planned to
provide a patch to bring back the modifications I did. There
were a design problem in the InputSource as far as I can remember,
also some optimizations with respect to byte array handling.

I only hope I'll manage to pass the problem with the NoClassDef exception at exec time without modifying much more the packages structure.

I can remember there were some problems when using an unmodified
BouncyCastle library, AFAIK Romain addresse this problem - and
it also wasn't it also an issues with class loading or alike?

Yes, there were. I've tried around a month ago to use the last version of BouncyCastle and as far as I remember from the logs resulted that the entire SC media bundle didn't start (hope I remember correctly...). I think it's an OSGi/Felix related problem to how the bundles/jars are packed. If I'll got the time (though until this project I had 0 experience with OSGi :slight_smile: ) I'll try to take another look at it. But for now I'll focus more on what is to do directly related with the ZRTP integration.

In the end, thank you very much again for your feedback!

Regards,
Emanuel

路路路

On Wed, 11 Jun 2008, Werner Dittmann wrote:

Regards,
Werner

Onica S. Emanuel schrieb:

Hello Romain, Werner and Yana,

I've posted a new entry on my blog http://sipcommkeysharing.blogspot.com/ related to the progress I made since last week with Werner's library integration. Also the last sources version are there. I'll try moving them on the svn branch (thank you Emil for it) this week.

I know it's a long entry :slight_smile: but when you got the time please take a look at it, as I need a bit of feedback on some issues.

To Werner: some feedback needed about the GUI components ZRTP4J should use
and some feedback needed on the way I "bound" SC to ZRTP4J at this moment

To Romain: some feedback needed also on the current approach of how SC integrates and uses ZRTP4J

To Yana : sorry to bother you too :slight_smile: but I really need some feedback on some GUI issues (some of them already done and some of them needed to do);
I know all that long entry probably wouldn't be of much interest to you so to get it shorter: the GUI problems are discussed in the first part (above the picture) and immediately after the long bulleted list

To all : I'm stuck at this moment at a classpath/import/or something like that I think issue, which is described at the end of the entry; hopefully I'll go past it soon, but if someone has an idea about the reason for it until I figure it out myself will surely speed up the process :slight_smile:

All these detailed on the blog.

Regards,
Emanuel

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

--
--------------------------------------------------------------------

"Life is full of unexpected but nothing happens without a reason..."

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#4

See some comments inline.

Regards,
Werner

Onica S. Emanuel schrieb:

Hello,

Just browsed your blog - impressive work done :slight_smile: .

Thank you for your response and for appreciation ! :slight_smile: There isn't really that much done :slight_smile:

I'll have a loook at the patches in more detail and give
you feedback.

For the GUI desing: just create some buttons or text fields
that we required - for example to show the SAS and verifiy the
SAS.

The problem is that I should know in essence if there are any other GUI elements which should be available to the user at any time during a call for an undetermined period (like the SAS) or if there are any other input GUI elements related to ZRTP on which the user can act whenever he/she desires not at specific moments required by the application (like some buttons or entry forms). As far as I know for the first there is only the SAS (but I might miss something) and about the last there aren't any cases (again I'm not 100% sure). If I'm correct all the other needed GUI elements could be implemented by popup dialogs easily with eventually the posibility for input - when the application requires a response from the user. To be sure I'm clear enough - in the other case, if the user is the one who can trigger an action at it's own initiative, at an unspecified time (again - I don't know any situations for this to happen - but I'm new to ZRTP) or other info like the SAS should be displayed for the user when
he/she desires or for indefinite time (so a popup isn't enough), I should start thinking on a SC GUI plugin to support all these.

The twinkle SIP client that already uses ZRTP (based on C++) conatins
only one active button in form of a padlock. This button is shown after
ZRTP reports it has switched to secure mode. Just after this button there
is a small textfield that displays the SAS so the user can read and
verfiy this. The padlock button has a tooltip that displays the used
encryption method and streng if the user positions the mouse on top of
the padlock button. I'll try to manage to get a screenshot of it after
ZRTP entered secure mode..

Anyway, I'm thinking already at a GUI plugin for the SAS, but taking into consideration that is only one GUI element I'll wait a bit for a feedback from Yana, or other SC GUI developer on what I've written on the blog. Eventually I'm gonna make another quick "parse" of the standard to see if there are any other elements like the one described above.

(For Werner - in order to be more clear about what I said above:
- the SC GUI plugin is the normal way for adding GUI elements to SC interface - as much as I understood from the SC docs at least :slight_smile: ;
- the popups, confirms and data inputs as message boxes can be done without a GUI plugin ;
- the last way is adding directly other type of elements to the main GUI source code - as I did for the Secure Button, but that I think it should be only for essential GUI elements)

The ZRTP4J library does not support goClear/goSecure - it's
optioal AFAIK, thus no need to implement this for now.

I know that in the standard it says is optional but I saw some skeleton code (empty) functions in your code related to this and I thought it might be supported in the future, and anyway, after we have a first stable phase
which runs fine without GoClear :), I might take a thought on implementing
also this feature. So, for now I'll disable eventually from the code that part, but I'll let it there to enable for future support.

Regarding start of ZRTP: ZRTP4J has an "autosensing" mode. If
you call the initialize method setting the "autoEnable" parameter
to true the ZRTP4J prepares itself to start. As soon as it sees
traffic on the RTP session (at least on packet was sent and
one received) it automatically starts ZRTP negotiation. This
way ZRTP knows the both clients are up and RTP is established
and it can start ZRTP. This prevents unnecessary timeouts or
ZRTP restarts. Thus you probably don't need to call startZrtp().
You may have a look at the GNU ZRTP Howto:
<http://www.gnutelephony.org/index.php/GNU_ZRTP_How_To>

Thank you for the link and especially for reminding me that I missed something. I actually completely forgot to call initialize for the engine (probably I would have realized myself, but I didn't had the time yet to think more on the other problem I'm stuck at - hope I'll pass it today.. - so I haven't reached that point with the debugging)

I added another small patch with the engine initialization at:
http://students.info.uaic.ro/~eonica/sc/zrtp02.01.patch

Also the modified source is available at:
http://students.info.uaic.ro/~eonica/sc/patch02/src/net/java/sip/communicator/impl/media/CallSessionImpl.java

(lines 1563-1578)

(I know :slight_smile: I must move all this on the svn branch - gonna' do that soon)

The idea still remains as I said on my blog:
- if the user toggled secure communication before the start of the call session the initialization is made with auto-sensing in order to start ZRTP automatically (to avoid calling startZrtp when it's already started
in this case I've added the getter isStarted to the engine as I said on the blog)
- if the user didn't toggle the secure communication before the start of
the call session (so secure comm is off) the initialization is done without auto-sensing and ZRTP starts through the startZrtp method if the user toggles secure comm on during the call

Also in twinkle it's a sort of a configuration option. The user may select
if he/she wants to use ZRTP. It's a check box in the configuration part
of the twinkle GUI. As long as the box is checked ZRTP is enabled and tries
to detect if the other client supports ZRTP - using autosensing mode.

路路路

On Wed, 11 Jun 2008, Werner Dittmann wrote:

I implemented it this way because as far as I recall from the standard it is said that the Discovery phase can start anytime - though usually at the session start; and after all I think it adds more flexibility in the user actions; otherwise - if I initialize the ZRTP engine with autosensing on at every call I don't know how the user could renounce at the secure comm - if for some reason desires it. In the way I've done the implementation the ZRTP connector is used for any call as long as ZRTP is registered as
a key management solution and has the top priority (which it does)- so the only other way to make unsecured comm calls would be to lower it and consequently choose normal RTP for transport - but in this case the user won't be able to toggle secure comm on during the call not having the connector present. So I think the described/implemented solution is better, having the communication made through the ZRTP connector and letting it pass normal RTP traffic as long secure comm is toggled off = engine not started (hope I'm correct about how it works internally :slight_smile: ).

About the overall path you describe in your blog this seems
ok to me. Also to bring back SRTP into SC is good, I planned to
provide a patch to bring back the modifications I did. There
were a design problem in the InputSource as far as I can remember,
also some optimizations with respect to byte array handling.

I only hope I'll manage to pass the problem with the NoClassDef exception at exec time without modifying much more the packages structure.

I can remember there were some problems when using an unmodified
BouncyCastle library, AFAIK Romain addresse this problem - and
it also wasn't it also an issues with class loading or alike?

Yes, there were. I've tried around a month ago to use the last version of BouncyCastle and as far as I remember from the logs resulted that the entire SC media bundle didn't start (hope I remember correctly...). I think it's an OSGi/Felix related problem to how the bundles/jars are packed. If I'll got the time (though until this project I had 0 experience with OSGi :slight_smile: ) I'll try to take another look at it. But for now I'll focus more on what is to do directly related with the ZRTP integration.

In the end, thank you very much again for your feedback!

Regards,
Emanuel

Regards,
Werner

Onica S. Emanuel schrieb:

Hello Romain, Werner and Yana,

I've posted a new entry on my blog http://sipcommkeysharing.blogspot.com/ related to the progress I made since last week with Werner's library integration. Also the last sources version are there. I'll try moving them on the svn branch (thank you Emil for it) this week.

I know it's a long entry :slight_smile: but when you got the time please take a look at it, as I need a bit of feedback on some issues.

To Werner: some feedback needed about the GUI components ZRTP4J should use
and some feedback needed on the way I "bound" SC to ZRTP4J at this moment

To Romain: some feedback needed also on the current approach of how SC integrates and uses ZRTP4J

To Yana : sorry to bother you too :slight_smile: but I really need some feedback on some GUI issues (some of them already done and some of them needed to do);
I know all that long entry probably wouldn't be of much interest to you so to get it shorter: the GUI problems are discussed in the first part (above the picture) and immediately after the long bulleted list

To all : I'm stuck at this moment at a classpath/import/or something like that I think issue, which is described at the end of the entry; hopefully I'll go past it soon, but if someone has an idea about the reason for it until I figure it out myself will surely speed up the process :slight_smile:

All these detailed on the blog.

Regards,
Emanuel

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#5

Thank you for the answer!

The twinkle SIP client that already uses ZRTP (based on C++) conatins
only one active button in form of a padlock. This button is shown after
ZRTP reports it has switched to secure mode. Just after this button there
is a small textfield that displays the SAS so the user can read and
verfiy this. The padlock button has a tooltip that displays the used
encryption method and streng if the user positions the mouse on top of
the padlock button. I'll try to manage to get a screenshot of it after
ZRTP entered secure mode..

Don't bother with the screenshot, anymore :). I had a pretty similar vision for this part. The difference is that the button has more the role of the checkbox you've mentioned below and not of a notifier for ZRTP being active. The ZRTP being active or not, I thought will be indicated by the permanent SAS presence on the screen as long as the communication is secured through ZRTP but, I'll think a bit more on this part. I'll just wait for some feedback from a GUI SC dev to tell me if it's ok to add the SAS field in the toolbar near the button and if I should do this through a GUI plugin or it's ok directly adding it to the main SC GUI code.

Also in twinkle it's a sort of a configuration option. The user may select
if he/she wants to use ZRTP. It's a check box in the configuration part
of the twinkle GUI. As long as the box is checked ZRTP is enabled and tries
to detect if the other client supports ZRTP - using autosensing mode.

The role of the checkbox is actually maintained by the padlock button as I said before. If it's not pressed it's equivalent with the mentioned check box not being checked. In this case ZRTP engine will initialize but won't start at the same time with the call (no autosensing). This way it's maintained anyway the option to start it if the user presses the button during the call by calling startZrtp. After the call the button remains pressed, unless the user doesn't toggle ZRTP off by pressing it again.
In case the button is pressed before the call (or remains pressed from a previous call) - same thing with the checkbox in Twinkle being checked,
ZRTP will start with autosensing mode on.

Anyway, to summarize it in less words :slight_smile: the button in my interface has the same role as the checkbox in Twinkle has, according to your description, regarding the ZRTP activation.

Regards,
Emanuel

路路路

On Thu, 12 Jun 2008, Werner Dittmann wrote:

I implemented it this way because as far as I recall from the standard it is said that the Discovery phase can start anytime - though usually at the session start; and after all I think it adds more flexibility in the user actions; otherwise - if I initialize the ZRTP engine with autosensing on at every call I don't know how the user could renounce at the secure comm - if for some reason desires it. In the way I've done the implementation the ZRTP connector is used for any call as long as ZRTP is registered as
a key management solution and has the top priority (which it does)- so the only other way to make unsecured comm calls would be to lower it and consequently choose normal RTP for transport - but in this case the user won't be able to toggle secure comm on during the call not having the connector present. So I think the described/implemented solution is better, having the communication made through the ZRTP connector and letting it pass normal RTP traffic as long secure comm is toggled off = engine not started (hope I'm correct about how it works internally :slight_smile: ).

About the overall path you describe in your blog this seems
ok to me. Also to bring back SRTP into SC is good, I planned to
provide a patch to bring back the modifications I did. There
were a design problem in the InputSource as far as I can remember,
also some optimizations with respect to byte array handling.

I only hope I'll manage to pass the problem with the NoClassDef exception at exec time without modifying much more the packages structure.

I can remember there were some problems when using an unmodified
BouncyCastle library, AFAIK Romain addresse this problem - and
it also wasn't it also an issues with class loading or alike?

Yes, there were. I've tried around a month ago to use the last version of BouncyCastle and as far as I remember from the logs resulted that the entire SC media bundle didn't start (hope I remember correctly...). I think it's an OSGi/Felix related problem to how the bundles/jars are packed. If I'll got the time (though until this project I had 0 experience with OSGi :slight_smile: ) I'll try to take another look at it. But for now I'll focus more on what is to do directly related with the ZRTP integration.

In the end, thank you very much again for your feedback!

Regards,
Emanuel

Regards,
Werner

Onica S. Emanuel schrieb:

Hello Romain, Werner and Yana,

I've posted a new entry on my blog http://sipcommkeysharing.blogspot.com/ related to the progress I made since last week with Werner's library integration. Also the last sources version are there. I'll try moving them on the svn branch (thank you Emil for it) this week.

I know it's a long entry :slight_smile: but when you got the time please take a look at it, as I need a bit of feedback on some issues.

To Werner: some feedback needed about the GUI components ZRTP4J should use
and some feedback needed on the way I "bound" SC to ZRTP4J at this moment

To Romain: some feedback needed also on the current approach of how SC integrates and uses ZRTP4J

To Yana : sorry to bother you too :slight_smile: but I really need some feedback on some GUI issues (some of them already done and some of them needed to do);
I know all that long entry probably wouldn't be of much interest to you so to get it shorter: the GUI problems are discussed in the first part (above the picture) and immediately after the long bulleted list

To all : I'm stuck at this moment at a classpath/import/or something like that I think issue, which is described at the end of the entry; hopefully I'll go past it soon, but if someone has an idea about the reason for it until I figure it out myself will surely speed up the process :slight_smile:

All these detailed on the blog.

Regards,
Emanuel

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

--
--------------------------------------------------------------------

"Life is full of unexpected but nothing happens without a reason..."

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#6

Hi Emanuel,

Sorry to jump in the discussion so late, I was travelling the whole day today.
Thank you for this extensive overview of your work, I'm quite impressed :slight_smile:
Some comments on the various points you raise in your mails and posts:

The GUI part: actually the location of the toggle button can be misleading for the user. The is intended for VoIP calls only (i.e. not for instant messaging nor any other communication type), so I was wondering if we could put it somewhere else. Maybe the place where the call buttons (bottom part of the SC gui) are located could be used to put such toggle button, and later the SAS stuff also. I think I'll discuss that with Emil and Yana and come back to you.

I was also wondering what happens if one peer does not have the secure button toggled and the other peer has. Is the communication encrypted only on one-way, or is the communication automatically encrypted for both way? (it seems that the "autosensing" mode Werner describes would allow the latter).

About the overview of the ZRTP4J integration, this seems OK to me on the SC side, and I'll trust Werner if he thinks his implementation is correctly used :slight_smile: For the SRTP part, you can use Werner's modifications as I'll eventually push them to the main SC repository.

Keep up the good work!

Cheers,
romain

路路路

On 2008/06/12, at 19:29, Onica S. Emanuel wrote:

On Thu, 12 Jun 2008, Werner Dittmann wrote:

Thank you for the answer!

The twinkle SIP client that already uses ZRTP (based on C++) conatins
only one active button in form of a padlock. This button is shown after
ZRTP reports it has switched to secure mode. Just after this button there
is a small textfield that displays the SAS so the user can read and
verfiy this. The padlock button has a tooltip that displays the used
encryption method and streng if the user positions the mouse on top of
the padlock button. I'll try to manage to get a screenshot of it after
ZRTP entered secure mode..

Don't bother with the screenshot, anymore :). I had a pretty similar vision for this part. The difference is that the button has more the role of the checkbox you've mentioned below and not of a notifier for ZRTP being active. The ZRTP being active or not, I thought will be indicated by the permanent SAS presence on the screen as long as the communication is secured through ZRTP but, I'll think a bit more on this part. I'll just wait for some feedback from a GUI SC dev to tell me if it's ok to add the SAS field in the toolbar near the button and if I should do this through a GUI plugin or it's ok directly adding it to the main SC GUI code.

Also in twinkle it's a sort of a configuration option. The user may select
if he/she wants to use ZRTP. It's a check box in the configuration part
of the twinkle GUI. As long as the box is checked ZRTP is enabled and tries
to detect if the other client supports ZRTP - using autosensing mode.

The role of the checkbox is actually maintained by the padlock button as I said before. If it's not pressed it's equivalent with the mentioned check box not being checked. In this case ZRTP engine will initialize but won't start at the same time with the call (no autosensing). This way it's maintained anyway the option to start it if the user presses the button during the call by calling startZrtp. After the call the button remains pressed, unless the user doesn't toggle ZRTP off by pressing it again.
In case the button is pressed before the call (or remains pressed from a previous call) - same thing with the checkbox in Twinkle being checked,
ZRTP will start with autosensing mode on.

Anyway, to summarize it in less words :slight_smile: the button in my interface has the same role as the checkbox in Twinkle has, according to your description, regarding the ZRTP activation.

Regards,
Emanuel

I implemented it this way because as far as I recall from the standard it is said that the Discovery phase can start anytime - though usually at the session start; and after all I think it adds more flexibility in the user actions; otherwise - if I initialize the ZRTP engine with autosensing on at every call I don't know how the user could renounce at the secure comm - if for some reason desires it. In the way I've done the implementation the ZRTP connector is used for any call as long as ZRTP is registered as
a key management solution and has the top priority (which it does)- so the only other way to make unsecured comm calls would be to lower it and consequently choose normal RTP for transport - but in this case the user won't be able to toggle secure comm on during the call not having the connector present. So I think the described/implemented solution is better, having the communication made through the ZRTP connector and letting it pass normal RTP traffic as long secure comm is toggled off = engine not started (hope I'm correct about how it works internally :slight_smile: ).

About the overall path you describe in your blog this seems
ok to me. Also to bring back SRTP into SC is good, I planned to
provide a patch to bring back the modifications I did. There
were a design problem in the InputSource as far as I can remember,
also some optimizations with respect to byte array handling.

I only hope I'll manage to pass the problem with the NoClassDef exception at exec time without modifying much more the packages structure.

I can remember there were some problems when using an unmodified
BouncyCastle library, AFAIK Romain addresse this problem - and
it also wasn't it also an issues with class loading or alike?

Yes, there were. I've tried around a month ago to use the last version of BouncyCastle and as far as I remember from the logs resulted that the entire SC media bundle didn't start (hope I remember correctly...). I think it's an OSGi/Felix related problem to how the bundles/jars are packed. If I'll got the time (though until this project I had 0 experience with OSGi :slight_smile: ) I'll try to take another look at it. But for now I'll focus more on what is to do directly related with the ZRTP integration.
In the end, thank you very much again for your feedback!
Regards,
Emanuel

Regards,
Werner
Onica S. Emanuel schrieb:

Hello Romain, Werner and Yana,
I've posted a new entry on my blog http://sipcommkeysharing.blogspot.com/ related to the progress I made since last week with Werner's library integration. Also the last sources version are there. I'll try moving them on the svn branch (thank you Emil for it) this week.
I know it's a long entry :slight_smile: but when you got the time please take a look at it, as I need a bit of feedback on some issues.
To Werner: some feedback needed about the GUI components ZRTP4J should use
and some feedback needed on the way I "bound" SC to ZRTP4J at this moment
To Romain: some feedback needed also on the current approach of how SC integrates and uses ZRTP4J
To Yana : sorry to bother you too :slight_smile: but I really need some feedback on some GUI issues (some of them already done and some of them needed to do);
I know all that long entry probably wouldn't be of much interest to you so to get it shorter: the GUI problems are discussed in the first part (above the picture) and immediately after the long bulleted list
To all : I'm stuck at this moment at a classpath/import/or something like that I think issue, which is described at the end of the entry; hopefully I'll go past it soon, but if someone has an idea about the reason for it until I figure it out myself will surely speed up the process :slight_smile:
All these detailed on the blog.
Regards,
Emanuel

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

--
--------------------------------------------------------------------

"Life is full of unexpected but nothing happens without a reason..."

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#7

Hello,

Hi Emanuel,

Sorry to jump in the discussion so late, I was travelling the whole day today.
Thank you for this extensive overview of your work, I'm quite impressed :slight_smile:
Some comments on the various points you raise in your mails and posts:

The GUI part: actually the location of the toggle button can be misleading for the user. The is intended for VoIP calls only (i.e. not for instant messaging nor any other communication type), so I was wondering if we could put it somewhere else. Maybe the place where the call buttons (bottom part of the SC gui) are located could be used to put such toggle button, and later the SAS stuff also. I think I'll discuss that with Emil and Yana and come back to you.

About the fact that it could be misleading being related to only VoIP calls, I also gave it a thought before adding it. In the end I decided to do it based on the fact the sound on/off is placed also there :slight_smile: but I agree that isn't the best reason for the placement. So, it's no problem, I think I can move it from there to where the call buttons are. I suppose it won't be very different from the quick menu positioning and handling related code. If that's the decision after you'll talk to Emil and Yana please let me know. Also it would be helpful if they can eventually point me directly for the class where this should be done (in the case of the quick menu there is an extended quick menu also which seems to have the same buttons and I didn't know where to add the secure button until I put some breakpoints to see how the code flows).

I was also wondering what happens if one peer does not have the secure button toggled and the other peer has. Is the communication encrypted only on one-way, or is the communication automatically encrypted for both way? (it seems that the "autosensing" mode Werner describes would allow the latter).

This is a good observation, as I don't recall to explaining the situation. Anyway, I think the whole button idea as i imagined isn't very clear yet, so I'll try to break it down again :slight_smile: on this case in particular:

First of all, the communication is of course encrypted both way, if the ZRTP
exchange is succesfull. If not, RTP normal stream should be supported between the two peers.

For the actual purpose of the button is not to actually inform that a secure session is on - this notification will be handled by the
SAS label presence, eventually colored in green :slight_smile: and displaying "Secure
comm ON as tooltip". The purpose of the button is to indicate/command SC to try using ZRTP (or maybe other management systems in the future) to secure a session. For clarity, I think I'll attach a tooltip to the button which will say "Try secure comm" when it's toggled on, and "No secure comm" when it's toggled off.

Now, let's say whe have user Alice who has secure toggled ON and user Bob who hase secure toggled OFF. This means Alice wants to communicate secure and BOB doesn't. Let's say for now that this preference setting is done when they both start ZRTP, prior to any call they make. Alice's endpoint attempts to start a call to Bob. Because Alice prefers secure comm and she toggled the button accordingly, her ZRTP implementation will start with the autosensing mode on, and try to establish the ZRTP communication with Bob. Bob doesn't want secure comm - so his call session will not start with autosensing on (but the ZRTP engine is anyway initialized), because we don't want to force Bob to secure the session automatically if he really doesn't want it. What will happen next ? Alice's attempts to secure the session will fail, because Bob's ZRTP engine isn't started, and Alice will be anounced that the communication isn't secure. Alice could choose, if she wants to go on this way - unsecure - which will still go through the ZRTP connector but with normal RTP traffic, or to drop the call. Let's say Alice really really wants to talk to Bob and accepts the unsecure option. After a while Alice tells Bob that she has a big secret :slight_smile: to tell him, and absolutely needs securing the call. Bob wants to know the secret, presses his secure preference setting button, and startZrtp is called, which starts the engine (which was initialized as I told before), and re-initiates ZRTP exchange.

I actually didn't look deeper into the ZRTP implementation, but according to the standard all this scenario should be possible as I recall. (Actually I think it's really recommended to be possible in order to add the necessary flexibility in the eventuality of further development for the GoClear message, which adds even more toggle on/off secure mode dinamically during the call) The big assumption I made, without looking deeper into the ZRTP implementation is that when Alice's ZRTP fails for the first time and switches to normal RTP, it should be able to start again the ZRTP exchange when Bob re-initiates it. If this is possible, what I don't know is if Alice needs to call startZrtp for it (she had autosensing on the first time but failed with ZRTP because of Bob, so I think it should be started). In case it isn't I probably should move the startZrtp call from the NewReceivedStreamEvent to more general ReceivedStreamEvent. It is checked anyway before it is called if the zrtpEngine isn't already started.

Well, if all this isn't possible at the current time in the ZRTP implementation, or I'm wrong about it complies with the standard, or it's bad from other points of view, I really don't have any problem to start both peers with autosensing :slight_smile: (but like I said this will start Bob's ZRTP also automatically, so I should redesign the role of the button). I just hope I made the whole approach clear this time, I don't want to insist with it if it's wrong or innapropriate at some point :). I know I'm far less experienced with ZRTP and JMF than Werner is, so if he says it's not ok I'll change it.

About the overview of the ZRTP4J integration, this seems OK to me on the SC side, and I'll trust Werner if he thinks his implementation is correctly used :slight_smile: For the SRTP part, you can use Werner's modifications as I'll eventually push them to the main SC repository.

Right at this moment, I'm going on with some package structure changing unfortunately because of the problem I pointed out in the final of the blog entry. I didn't find yet an explanation so I'll try moving them from the gnu folder to the net one. I know it sounds stupid and it shouldn't be done, but it seems to work (until now.. at least). I'll point again that the problem is at exec time with NoClassDefFoundError. Yes, it sounds like a classpath problem but I really don't know what to change. In the Eclipse .classpath file I have <classpathentry kind="src" path="src"/> and <classpathentry kind="output" path="bin"/> and I added the gnu folder in src at the same level as net folder is. All imports go well, the build goes well and the compiled classes are at the path they should be in the bin folder, but at exec happens what I told before and explained in detail on the blog. I'll go this way - changing package structure a little bit for now - to be able to go forward with the debugging, and eventually I'll refactor it later if I find out what causes this to happen.

Cheers,
Emanuel

路路路

On Thu, 12 Jun 2008, Romain KUNTZ wrote:

Keep up the good work!

Cheers,
romain

On 2008/06/12, at 19:29, Onica S. Emanuel wrote:

On Thu, 12 Jun 2008, Werner Dittmann wrote:

Thank you for the answer!

The twinkle SIP client that already uses ZRTP (based on C++) conatins
only one active button in form of a padlock. This button is shown after
ZRTP reports it has switched to secure mode. Just after this button there
is a small textfield that displays the SAS so the user can read and
verfiy this. The padlock button has a tooltip that displays the used
encryption method and streng if the user positions the mouse on top of
the padlock button. I'll try to manage to get a screenshot of it after
ZRTP entered secure mode..

Don't bother with the screenshot, anymore :). I had a pretty similar vision for this part. The difference is that the button has more the role of the checkbox you've mentioned below and not of a notifier for ZRTP being active. The ZRTP being active or not, I thought will be indicated by the permanent SAS presence on the screen as long as the communication is secured through ZRTP but, I'll think a bit more on this part. I'll just wait for some feedback from a GUI SC dev to tell me if it's ok to add the SAS field in the toolbar near the button and if I should do this through a GUI plugin or it's ok directly adding it to the main SC GUI code.

Also in twinkle it's a sort of a configuration option. The user may select
if he/she wants to use ZRTP. It's a check box in the configuration part
of the twinkle GUI. As long as the box is checked ZRTP is enabled and tries
to detect if the other client supports ZRTP - using autosensing mode.

The role of the checkbox is actually maintained by the padlock button as I said before. If it's not pressed it's equivalent with the mentioned check box not being checked. In this case ZRTP engine will initialize but won't start at the same time with the call (no autosensing). This way it's maintained anyway the option to start it if the user presses the button during the call by calling startZrtp. After the call the button remains pressed, unless the user doesn't toggle ZRTP off by pressing it again.
In case the button is pressed before the call (or remains pressed from a previous call) - same thing with the checkbox in Twinkle being checked,
ZRTP will start with autosensing mode on.

Anyway, to summarize it in less words :slight_smile: the button in my interface has the same role as the checkbox in Twinkle has, according to your description, regarding the ZRTP activation.

Regards,
Emanuel

I implemented it this way because as far as I recall from the standard it is said that the Discovery phase can start anytime - though usually at the session start; and after all I think it adds more flexibility in the user actions; otherwise - if I initialize the ZRTP engine with autosensing on at every call I don't know how the user could renounce at the secure comm - if for some reason desires it. In the way I've done the implementation the ZRTP connector is used for any call as long as ZRTP is registered as
a key management solution and has the top priority (which it does)- so the only other way to make unsecured comm calls would be to lower it and consequently choose normal RTP for transport - but in this case the user won't be able to toggle secure comm on during the call not having the connector present. So I think the described/implemented solution is better, having the communication made through the ZRTP connector and letting it pass normal RTP traffic as long secure comm is toggled off = engine not started (hope I'm correct about how it works internally :slight_smile: ).

About the overall path you describe in your blog this seems
ok to me. Also to bring back SRTP into SC is good, I planned to
provide a patch to bring back the modifications I did. There
were a design problem in the InputSource as far as I can remember,
also some optimizations with respect to byte array handling.

I only hope I'll manage to pass the problem with the NoClassDef exception at exec time without modifying much more the packages structure.

I can remember there were some problems when using an unmodified
BouncyCastle library, AFAIK Romain addresse this problem - and
it also wasn't it also an issues with class loading or alike?

Yes, there were. I've tried around a month ago to use the last version of BouncyCastle and as far as I remember from the logs resulted that the entire SC media bundle didn't start (hope I remember correctly...). I think it's an OSGi/Felix related problem to how the bundles/jars are packed. If I'll got the time (though until this project I had 0 experience with OSGi :slight_smile: ) I'll try to take another look at it. But for now I'll focus more on what is to do directly related with the ZRTP integration.
In the end, thank you very much again for your feedback!
Regards,
Emanuel

Regards,
Werner
Onica S. Emanuel schrieb:

Hello Romain, Werner and Yana,
I've posted a new entry on my blog http://sipcommkeysharing.blogspot.com/ related to the progress I made since last week with Werner's library integration. Also the last sources version are there. I'll try moving them on the svn branch (thank you Emil for it) this week.
I know it's a long entry :slight_smile: but when you got the time please take a look at it, as I need a bit of feedback on some issues.
To Werner: some feedback needed about the GUI components ZRTP4J should use
and some feedback needed on the way I "bound" SC to ZRTP4J at this moment
To Romain: some feedback needed also on the current approach of how SC integrates and uses ZRTP4J
To Yana : sorry to bother you too :slight_smile: but I really need some feedback on some GUI issues (some of them already done and some of them needed to do);
I know all that long entry probably wouldn't be of much interest to you so to get it shorter: the GUI problems are discussed in the first part (above the picture) and immediately after the long bulleted list
To all : I'm stuck at this moment at a classpath/import/or something like that I think issue, which is described at the end of the entry; hopefully I'll go past it soon, but if someone has an idea about the reason for it until I figure it out myself will surely speed up the process :slight_smile:
All these detailed on the blog.
Regards,
Emanuel

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

--
--------------------------------------------------------------------

"Life is full of unexpected but nothing happens without a reason..."

--
--------------------------------------------------------------------

"Life is full of unexpected but nothing happens without a reason..."

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#8

One correction at the previous mail :slight_smile: in the Alice/Bob "story":

"Let's say for now that this preference setting is done
聽聽when they both start ZRTP, prior to any call they make."

it's of course when "they both start SC" not ZRTP. I hope I didn't make any other mistakes and all it will be clear now.

路路路

On Fri, 13 Jun 2008, Onica S. Emanuel wrote:

Hello,

On Thu, 12 Jun 2008, Romain KUNTZ wrote:

Hi Emanuel,

Sorry to jump in the discussion so late, I was travelling the whole day today.
Thank you for this extensive overview of your work, I'm quite impressed :slight_smile:
Some comments on the various points you raise in your mails and posts:

The GUI part: actually the location of the toggle button can be misleading for the user. The is intended for VoIP calls only (i.e. not for instant messaging nor any other communication type), so I was wondering if we could put it somewhere else. Maybe the place where the call buttons (bottom part of the SC gui) are located could be used to put such toggle button, and later the SAS stuff also. I think I'll discuss that with Emil and Yana and come back to you.

About the fact that it could be misleading being related to only VoIP calls, I also gave it a thought before adding it. In the end I decided to do it based on the fact the sound on/off is placed also there :slight_smile: but I agree that isn't the best reason for the placement. So, it's no problem, I think I can move it from there to where the call buttons are. I suppose it won't be very different from the quick menu positioning and handling related code. If that's the decision after you'll talk to Emil and Yana please let me know. Also it would be helpful if they can eventually point me directly for the class where this should be done (in the case of the quick menu there is an extended quick menu also which seems to have the same buttons and I didn't know where to add the secure button until I put some breakpoints to see how the code flows).

I was also wondering what happens if one peer does not have the secure button toggled and the other peer has. Is the communication encrypted only on one-way, or is the communication automatically encrypted for both way? (it seems that the "autosensing" mode Werner describes would allow the latter).

This is a good observation, as I don't recall to explaining the situation. Anyway, I think the whole button idea as i imagined isn't very clear yet, so I'll try to break it down again :slight_smile: on this case in particular:

First of all, the communication is of course encrypted both way, if the ZRTP
exchange is succesfull. If not, RTP normal stream should be supported between the two peers.

For the actual purpose of the button is not to actually inform that a secure session is on - this notification will be handled by the
SAS label presence, eventually colored in green :slight_smile: and displaying "Secure
comm ON as tooltip". The purpose of the button is to indicate/command SC to try using ZRTP (or maybe other management systems in the future) to secure a session. For clarity, I think I'll attach a tooltip to the button which will say "Try secure comm" when it's toggled on, and "No secure comm" when it's toggled off.

Now, let's say whe have user Alice who has secure toggled ON and user Bob who hase secure toggled OFF. This means Alice wants to communicate secure and BOB doesn't. Let's say for now that this preference setting is done when they both start ZRTP, prior to any call they make. Alice's endpoint attempts to start a call to Bob. Because Alice prefers secure comm and she toggled the button accordingly, her ZRTP implementation will start with the autosensing mode on, and try to establish the ZRTP communication with Bob. Bob doesn't want secure comm - so his call session will not start with autosensing on (but the ZRTP engine is anyway initialized), because we don't want to force Bob to secure the session automatically if he really doesn't want it. What will happen next ? Alice's attempts to secure the session will fail, because Bob's ZRTP engine isn't started, and Alice will be anounced that the communication isn't secure. Alice could choose, if she wants to go on this way - unsecure - which will still go through the ZRTP connector but with normal RTP traffic, or to drop the call. Let's say Alice really really wants to talk to Bob and accepts the unsecure option. After a while Alice tells Bob that she has a big secret :slight_smile: to tell him, and absolutely needs securing the call. Bob wants to know the secret, presses his secure preference setting button, and startZrtp is called, which starts the engine (which was initialized as I told before), and re-initiates ZRTP exchange.

I actually didn't look deeper into the ZRTP implementation, but according to the standard all this scenario should be possible as I recall. (Actually I think it's really recommended to be possible in order to add the necessary flexibility in the eventuality of further development for the GoClear message, which adds even more toggle on/off secure mode dinamically during the call) The big assumption I made, without looking deeper into the ZRTP implementation is that when Alice's ZRTP fails for the first time and switches to normal RTP, it should be able to start again the ZRTP exchange when Bob re-initiates it. If this is possible, what I don't know is if Alice needs to call startZrtp for it (she had autosensing on the first time but failed with ZRTP because of Bob, so I think it should be started). In case it isn't I probably should move the startZrtp call from the NewReceivedStreamEvent to more general ReceivedStreamEvent. It is checked anyway before it is called if the zrtpEngine isn't already started.

Well, if all this isn't possible at the current time in the ZRTP implementation, or I'm wrong about it complies with the standard, or it's bad from other points of view, I really don't have any problem to start both peers with autosensing :slight_smile: (but like I said this will start Bob's ZRTP also automatically, so I should redesign the role of the button). I just hope I made the whole approach clear this time, I don't want to insist with it if it's wrong or innapropriate at some point :). I know I'm far less experienced with ZRTP and JMF than Werner is, so if he says it's not ok I'll change it.

About the overview of the ZRTP4J integration, this seems OK to me on the SC side, and I'll trust Werner if he thinks his implementation is correctly used :slight_smile: For the SRTP part, you can use Werner's modifications as I'll eventually push them to the main SC repository.

Right at this moment, I'm going on with some package structure changing unfortunately because of the problem I pointed out in the final of the blog entry. I didn't find yet an explanation so I'll try moving them from the gnu folder to the net one. I know it sounds stupid and it shouldn't be done, but it seems to work (until now.. at least). I'll point again that the problem is at exec time with NoClassDefFoundError. Yes, it sounds like a classpath problem but I really don't know what to change. In the Eclipse .classpath file I have <classpathentry kind="src" path="src"/> and <classpathentry kind="output" path="bin"/> and I added the gnu folder in src at the same level as net folder is. All imports go well, the build goes well and the compiled classes are at the path they should be in the bin folder, but at exec happens what I told before and explained in detail on the blog. I'll go this way - changing package structure a little bit for now - to be able to go forward with the debugging, and eventually I'll refactor it later if I find out what causes this to happen.

Cheers,
Emanuel

Keep up the good work!

Cheers,
romain

On 2008/06/12, at 19:29, Onica S. Emanuel wrote:

On Thu, 12 Jun 2008, Werner Dittmann wrote:

Thank you for the answer!

The twinkle SIP client that already uses ZRTP (based on C++) conatins
only one active button in form of a padlock. This button is shown after
ZRTP reports it has switched to secure mode. Just after this button there
is a small textfield that displays the SAS so the user can read and
verfiy this. The padlock button has a tooltip that displays the used
encryption method and streng if the user positions the mouse on top of
the padlock button. I'll try to manage to get a screenshot of it after
ZRTP entered secure mode..

Don't bother with the screenshot, anymore :). I had a pretty similar vision for this part. The difference is that the button has more the role of the checkbox you've mentioned below and not of a notifier for ZRTP being active. The ZRTP being active or not, I thought will be indicated by the permanent SAS presence on the screen as long as the communication is secured through ZRTP but, I'll think a bit more on this part. I'll just wait for some feedback from a GUI SC dev to tell me if it's ok to add the SAS field in the toolbar near the button and if I should do this through a GUI plugin or it's ok directly adding it to the main SC GUI code.

Also in twinkle it's a sort of a configuration option. The user may select
if he/she wants to use ZRTP. It's a check box in the configuration part
of the twinkle GUI. As long as the box is checked ZRTP is enabled and tries
to detect if the other client supports ZRTP - using autosensing mode.

The role of the checkbox is actually maintained by the padlock button as I said before. If it's not pressed it's equivalent with the mentioned check box not being checked. In this case ZRTP engine will initialize but won't start at the same time with the call (no autosensing). This way it's maintained anyway the option to start it if the user presses the button during the call by calling startZrtp. After the call the button remains pressed, unless the user doesn't toggle ZRTP off by pressing it again.
In case the button is pressed before the call (or remains pressed from a previous call) - same thing with the checkbox in Twinkle being checked,
ZRTP will start with autosensing mode on.

Anyway, to summarize it in less words :slight_smile: the button in my interface has the same role as the checkbox in Twinkle has, according to your description, regarding the ZRTP activation.

Regards,
Emanuel

I implemented it this way because as far as I recall from the standard it is said that the Discovery phase can start anytime - though usually at the session start; and after all I think it adds more flexibility in the user actions; otherwise - if I initialize the ZRTP engine with autosensing on at every call I don't know how the user could renounce at the secure comm - if for some reason desires it. In the way I've done the implementation the ZRTP connector is used for any call as long as ZRTP is registered as
a key management solution and has the top priority (which it does)- so the only other way to make unsecured comm calls would be to lower it and consequently choose normal RTP for transport - but in this case the user won't be able to toggle secure comm on during the call not having the connector present. So I think the described/implemented solution is better, having the communication made through the ZRTP connector and letting it pass normal RTP traffic as long secure comm is toggled off = engine not started (hope I'm correct about how it works internally :slight_smile: ).

About the overall path you describe in your blog this seems
ok to me. Also to bring back SRTP into SC is good, I planned to
provide a patch to bring back the modifications I did. There
were a design problem in the InputSource as far as I can remember,
also some optimizations with respect to byte array handling.

I only hope I'll manage to pass the problem with the NoClassDef exception at exec time without modifying much more the packages structure.

I can remember there were some problems when using an unmodified
BouncyCastle library, AFAIK Romain addresse this problem - and
it also wasn't it also an issues with class loading or alike?

Yes, there were. I've tried around a month ago to use the last version of BouncyCastle and as far as I remember from the logs resulted that the entire SC media bundle didn't start (hope I remember correctly...). I think it's an OSGi/Felix related problem to how the bundles/jars are packed. If I'll got the time (though until this project I had 0 experience with OSGi :slight_smile: ) I'll try to take another look at it. But for now I'll focus more on what is to do directly related with the ZRTP integration.
In the end, thank you very much again for your feedback!
Regards,
Emanuel

Regards,
Werner
Onica S. Emanuel schrieb:

Hello Romain, Werner and Yana,
I've posted a new entry on my blog http://sipcommkeysharing.blogspot.com/ related to the progress I made since last week with Werner's library integration. Also the last sources version are there. I'll try moving them on the svn branch (thank you Emil for it) this week.
I know it's a long entry :slight_smile: but when you got the time please take a look at it, as I need a bit of feedback on some issues.
To Werner: some feedback needed about the GUI components ZRTP4J should use
and some feedback needed on the way I "bound" SC to ZRTP4J at this moment
To Romain: some feedback needed also on the current approach of how SC integrates and uses ZRTP4J
To Yana : sorry to bother you too :slight_smile: but I really need some feedback on some GUI issues (some of them already done and some of them needed to do);
I know all that long entry probably wouldn't be of much interest to you so to get it shorter: the GUI problems are discussed in the first part (above the picture) and immediately after the long bulleted list
To all : I'm stuck at this moment at a classpath/import/or something like that I think issue, which is described at the end of the entry; hopefully I'll go past it soon, but if someone has an idea about the reason for it until I figure it out myself will surely speed up the process :slight_smile:
All these detailed on the blog.
Regards,
Emanuel

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

--
--------------------------------------------------------------------

"Life is full of unexpected but nothing happens without a reason..."

--
--------------------------------------------------------------------

"Life is full of unexpected but nothing happens without a reason..."

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#9

See some comments inline regarding ZRTP start etc.

Werner

Onica S. Emanuel schrieb:

Hello,

Hi Emanuel,

Sorry to jump in the discussion so late, I was travelling the whole day today.
Thank you for this extensive overview of your work, I'm quite impressed :slight_smile:
Some comments on the various points you raise in your mails and posts:

The GUI part: actually the location of the toggle button can be misleading for the user. The is intended for VoIP calls only (i.e. not for instant messaging nor any other communication type), so I was wondering if we could put it somewhere else. Maybe the place where the call buttons (bottom part of the SC gui) are located could be used to put such toggle button, and later the SAS stuff also. I think I'll discuss that with Emil and Yana and come back to you.

About the fact that it could be misleading being related to only VoIP calls, I also gave it a thought before adding it. In the end I decided to do it based on the fact the sound on/off is placed also there :slight_smile: but I agree that isn't the best reason for the placement. So, it's no problem, I think I can move it from there to where the call buttons are. I suppose it won't be very different from the quick menu positioning and handling related code. If that's the decision after you'll talk to Emil and Yana please let me know. Also it would be helpful if they can eventually point me directly for the class where this should be done (in the case of the quick menu there is an extended quick menu also which seems to have the same buttons and I didn't know where to add the secure button until I put some breakpoints to see how the code flows).

I was also wondering what happens if one peer does not have the secure button toggled and the other peer has. Is the communication encrypted only on one-way, or is the communication automatically encrypted for both way? (it seems that the "autosensing" mode Werner describes would allow the latter).

This is a good observation, as I don't recall to explaining the situation. Anyway, I think the whole button idea as i imagined isn't very clear yet, so I'll try to break it down again :slight_smile: on this case in particular:

First of all, the communication is of course encrypted both way, if the ZRTP
exchange is succesfull. If not, RTP normal stream should be supported between the two peers.

For the actual purpose of the button is not to actually inform that a secure session is on - this notification will be handled by the
SAS label presence, eventually colored in green :slight_smile: and displaying "Secure
comm ON as tooltip". The purpose of the button is to indicate/command SC to try using ZRTP (or maybe other management systems in the future) to secure a session. For clarity, I think I'll attach a tooltip to the button which will say "Try secure comm" when it's toggled on, and "No secure comm" when it's toggled off.

Now, let's say whe have user Alice who has secure toggled ON and user Bob who hase secure toggled OFF. This means Alice wants to communicate secure and BOB doesn't. Let's say for now that this preference setting is done when they both start ZRTP, prior to any call they make. Alice's endpoint attempts to start a call to Bob. Because Alice prefers secure comm and she toggled the button accordingly, her ZRTP implementation will start with the autosensing mode on, and try to establish the ZRTP communication with Bob. Bob doesn't want secure comm - so his call session will not start with autosensing on (but the ZRTP engine is anyway initialized), because we don't want to force Bob to secure the session automatically if he really doesn't want it. What will happen next ? Alice's attempts to secure the session will fail, because Bob's ZRTP engine isn't started, and Alice will be anounced that the communication isn't secure. Alice could choose, if she wants to go on this way - unsecure - which will still go through the ZRTP connector but with normal RTP traffic, or to drop the call. Let's say Alice really really wants to talk to Bob and accepts the unsecure option. After a while Alice tells Bob that she has a big secret :slight_smile: to tell him, and absolutely needs securing the call. Bob wants to know the secret, presses his secure preference setting button, and startZrtp is called, which starts the engine (which was initialized as I told before), and re-initiates ZRTP exchange.

I actually didn't look deeper into the ZRTP implementation, but according to the standard all this scenario should be possible as I recall. (Actually I think it's really recommended to be possible in order to add the necessary flexibility in the eventuality of further development for the GoClear message, which adds even more toggle on/off secure mode dinamically during the call) The big assumption I made, without looking deeper into the ZRTP implementation is that when Alice's ZRTP fails for the first time and switches to normal RTP, it should be able to start again the ZRTP exchange when Bob re-initiates it. If this is possible, what I don't know is if Alice needs to call startZrtp for it (she had autosensing on the first time but failed with ZRTP because of Bob, so I think it should be started). In case it isn't I probably should move the startZrtp call from the NewReceivedStreamEvent to more general ReceivedStreamEvent. It is checked anyway before it is called if the zrtpEngine isn't already started.

After Alices's ZRTP engine detects that Bob's client does not support ZRTP
(because Bob didn't enable it) then Alice's ZRTP engine goes back into
"Detect" state. If Bob sometime during the call decides to enable secure
call and the toggles the security button the the action method of this
button shall call startZrtp(..). Assuming that ZRTP was already initialized
(with autosensing mode off) the Bob's ZRTP engione would immediately start
the ZRTP handshake. Alice's engine would responde to it because it is
in the Detect state. Thus security is switch on (usually such a handshake
takes about 1-2 seconds, depending on the bandwidtw etc).

Well, if all this isn't possible at the current time in the ZRTP implementation, or I'm wrong about it complies with the standard, or it's bad from other points of view, I really don't have any problem to start both peers with autosensing :slight_smile: (but like I said this will start Bob's ZRTP also automatically, so I should redesign the role of the button). I just hope I made the whole approach clear this time, I don't want to insist with it if it's wrong or innapropriate at some point :). I know I'm far less experienced with ZRTP and JMF than Werner is, so if he says it's not ok I'll change it.

About the overview of the ZRTP4J integration, this seems OK to me on the SC side, and I'll trust Werner if he thinks his implementation is correctly used :slight_smile: For the SRTP part, you can use Werner's modifications as I'll eventually push them to the main SC repository.

Right at this moment, I'm going on with some package structure changing unfortunately because of the problem I pointed out in the final of the blog entry. I didn't find yet an explanation so I'll try moving them from the gnu folder to the net one. I know it sounds stupid and it shouldn't be done, but it seems to work (until now.. at least). I'll point again that the problem is at exec time with NoClassDefFoundError. Yes, it sounds like a classpath problem but I really don't know what to change. In the Eclipse .classpath file I have <classpathentry kind="src" path="src"/> and <classpathentry kind="output" path="bin"/> and I added the gnu folder in src at the same level as net folder is. All imports go well, the build goes well and the compiled classes are at the path they should be in the bin folder, but at exec happens what I told before and explained in detail on the blog. I'll go this way - changing package structure a little bit for now - to be able to go forward with the debugging, and eventually I'll refactor it later if I find out what causes this to happen.

Cheers,
Emanuel

<SNIP ---- SNAP>

路路路

On Thu, 12 Jun 2008, Romain KUNTZ wrote:

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#10

Hi Emanuel,

I discussed a bit with Emil and Yana about the location of the button & label.

About the fact that it could be misleading being related to only VoIP calls, I also gave it a thought before adding it. In the end I decided to do it based on the fact the sound on/off is placed also there :slight_smile: but I agree that isn't the best reason for the placement. So, it's no problem, I think I can move it from there to where the call buttons are. I suppose it won't be very different from the quick menu positioning and handling related code. If that's the decision after you'll talk to Emil and Yana please let me know. Also it would be helpful if they can eventually point me directly for the class where this should be done (in the case of the quick menu there is an extended quick menu also which seems to have the same buttons and I didn't know where to add the secure button until I put some breakpoints to see how the code flows).

We are thinking about adding the "secure" button in the panel where the call buttons are, at the right of the input text entry. About the label, I suppose it is only displayed once the call is established right? In that case we think about putting it in the new tabbed window that appear when you call someone (the one that displays the time of the call).

This is for the theory :slight_smile:
In practice, we would like that such buttons/label are added as a plugin in the location I mentioned, and not directly in the main GUI sources. This is not possible at the moment, but Yana will take care of making that possible. Once this is done, she told me that it would be very easy to create a plugin that adds the button in the correct place.

So, at the moment, keep them where they are, and add the label where you initially planned. We will move them later, once Yana will have time to take care of making the panels plugin-friendly.

Cheers,
romain

路路路

On 2008/06/13, at 0:21, Onica S. Emanuel wrote:

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net