[sip-comm-dev] SIP communicator on Solaris


#1

Hi all,

There are a couple of topics about SIP communicator on (Open)Solaris
I'd like to share with you.

I work on integration of SIP communicator into OpenSolaris
distribution. Technical part of this work is finished. Now it has to
go through review processes and get approvals. You know, it does not
related to quality of SIP communicator's code or its work under
Solaris, but is about a number of subjects like possible export
restrictions (is subject to encryption's strength), licensing, and
some others. I'll keep you informed once it's done.

In the meanwhile, I would finish my work on Solaris installation
packages for nightly builds. It's almost done and produces Solaris
packages in data stream format (a native form for Solaris and
OpenSolaris s/w distributions). Conventions regarding getting sources
and distributing packages are still left to be cleared up, so please
let me know if you think it is reasonable to maintain Solaris
distribution format for SIP communicator.

regards,
dmeetry

···

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


#2

Hey Dmeetry,

Dmeetry Degrave wrote:

Hi all,

There are a couple of topics about SIP communicator on (Open)Solaris
I'd like to share with you.

I work on integration of SIP communicator into OpenSolaris
distribution. Technical part of this work is finished. Now it has to
go through review processes and get approvals. You know, it does not
related to quality of SIP communicator's code or its work under
Solaris, but is about a number of subjects like possible export
restrictions (is subject to encryption's strength), licensing, and
some others. I'll keep you informed once it's done.

This is really great news! Thanks for the note!

In the meanwhile, I would finish my work on Solaris installation
packages for nightly builds. It's almost done and produces Solaris
packages in data stream format (a native form for Solaris and
OpenSolaris s/w distributions). Conventions regarding getting sources
and distributing packages are still left to be cleared up, so please
let me know if you think it is reasonable to maintain Solaris
distribution format for SIP communicator.

It definitely is and we'd be happy add a link on our downloads page.
Would you be attaching your build process to our trunk? If yes, then we
could probably trigger it for you from our continuous build system so
that it has the same versioning as the other packages that we provide
ourselves. Let us know if that interests you.

Cheers,
Emil

···

---------------------------------------------------------------------
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 Dmeetry,

I work on integration of SIP communicator into OpenSolaris
distribution. Technical part of this work is finished. Now it has to
go through review processes and get approvals. You know, it does not
related to quality of SIP communicator's code or its work under
Solaris, but is about a number of subjects like possible export
restrictions (is subject to encryption's strength), licensing, and
some others. I'll keep you informed once it's done.

About the export restrictions, in trunk we have the bouncycastle
bundle (lib/installer-exclude/bouncycastle.jar) that provides strong
encryption in otr4j and zrtp4j, two libraries used in SIP
Communicator.

The bouncycastle.jar we use is not the complete bouncycastle
lightweight API, we have trimmed it down to squeeze it's size, source
is located here:
http://svn.savannah.gnu.org/viewvc/trunk/ccrtp/contributions/cryptolib/?root=ccrtp

Essentially the algorithms we use are SHA1, SHA256, AES, DSA and DH
(Diffie Hellman)

I am by faaar not an export in legal subjects such as the U.S.
encryption export control regulations, but let me know if you need
further details on the algorithms.

Best,
George

···

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


#4

s/not an export/not an expert

···

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


#5

Hi George,

About the export restrictions, in trunk we have the bouncycastle
bundle (lib/installer-exclude/bouncycastle.jar) that provides strong
encryption in otr4j and zrtp4j, two libraries used in SIP
Communicator.

Thanks for information ! Are these the only libraries that use an
encryption ? I remember ssh plugin has been mentioned in discussions,
and probably IM uses encryption also ? I haven't made a detailed
search in sources on this subject yet.

The bouncycastle.jar we use is not the complete bouncycastle
lightweight API, we have trimmed it down to squeeze it's size, source
is located here:
http://svn.savannah.gnu.org/viewvc/trunk/ccrtp/contributions/cryptolib/?root=ccrtp

Essentially the algorithms we use are SHA1, SHA256, AES, DSA and DH
(Diffie Hellman)

I am by faaar not an export in legal subjects such as the U.S.
encryption export control regulations, but let me know if you need
further details on the algorithms.

I'm not a lawyer as well and I'm not a person who will take a final
decision. The information you have provided is valuable, and I will
definitely ask you in case of any questions arise.

Best,
George

thanks,
dmeetry

···

---------------------------------------------------------------------
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 Dmeetry,

There is also the dict4j package that use MD5 encryption.

The source is available here :
https://dict4j.dev.java.net/

Cheers,

Damien

···

2009/9/20 Dmeetry Degrave <dmeetry@gmail.com>:

Hi George,

About the export restrictions, in trunk we have the bouncycastle
bundle (lib/installer-exclude/bouncycastle.jar) that provides strong
encryption in otr4j and zrtp4j, two libraries used in SIP
Communicator.

Thanks for information ! Are these the only libraries that use an
encryption ? I remember ssh plugin has been mentioned in discussions,
and probably IM uses encryption also ? I haven't made a detailed
search in sources on this subject yet.

The bouncycastle.jar we use is not the complete bouncycastle
lightweight API, we have trimmed it down to squeeze it's size, source
is located here:
http://svn.savannah.gnu.org/viewvc/trunk/ccrtp/contributions/cryptolib/?root=ccrtp

Essentially the algorithms we use are SHA1, SHA256, AES, DSA and DH
(Diffie Hellman)

I am by faaar not an export in legal subjects such as the U.S.
encryption export control regulations, but let me know if you need
further details on the algorithms.

I'm not a lawyer as well and I'm not a person who will take a final
decision. The information you have provided is valuable, and I will
definitely ask you in case of any questions arise.

Best,
George

thanks,
dmeetry

---------------------------------------------------------------------
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


#7

Hello Dmeetry,

Thanks for information ! Are these the only libraries that use an
encryption ? I remember ssh plugin has been mentioned in discussions,
and probably IM uses encryption also ? I haven't made a detailed
search in sources on this subject yet.

You are absolutely right, the SSH protocol uses the jsch library
(http://www.jcraft.com/jsch/) and from a quick glance at the source it
is obvious that it does not fully rely on Java Cryptographic Extension
(JCE).

JCE reliance is important because if a piece of code relies only on
the JCE, there should be no problem, Java comes "U.S.
encryption export control regulations" compliant, i.e. strong
encryption features are disabled and, in order to enable them, you
must download and install the "Unlimited Strength Jurisdiction Policy
Files" (http://java.sun.com/javase/downloads/index.jsp, in the
bottom).

···

-

As for IM encryption, we use the Off-the-Record protocol wherever
possible, provided by otr4j which, as with jsch and zrtp4j, it does
not rely on JCE.

otr4j (Off-the-Record protocol library) operates at the message layer,
i.e. it manipulates message strings, various IM protocol libraries
(e.g we use JML for MSN, jYMSG for Yahoo! e.t.c.) may have their own
mechanisms to establish a secure connection with the server.

Have a nice week everybody!

Kind regards,
George

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


#8

Hi Damien,

There is also the dict4j package that use MD5 encryption.

The source is available here :
https://dict4j.dev.java.net/

Thank you, Damien.

Dict4j should not be a cause for any issue. At first glance rfc2229
uses MD5 for authentication only, so usage of any strong hash function
should be ok. And MD5 is known as cryptographically broken and is not
considered as strong.

regards,
dmeetry

···

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


#9

Hi George,

Very much appreciated ! Thank you.

regards,
dmeetry

···

You are absolutely right, the SSH protocol uses the jsch library
(http://www.jcraft.com/jsch/) and from a quick glance at the source it
is obvious that it does not fully rely on Java Cryptographic Extension
(JCE).

JCE reliance is important because if a piece of code relies only on
the JCE, there should be no problem, Java comes "U.S.
encryption export control regulations" compliant, i.e. strong
encryption features are disabled and, in order to enable them, you
must download and install the "Unlimited Strength Jurisdiction Policy
Files" (http://java.sun.com/javase/downloads/index.jsp, in the
bottom).

-

As for IM encryption, we use the Off-the-Record protocol wherever
possible, provided by otr4j which, as with jsch and zrtp4j, it does
not rely on JCE.

otr4j (Off-the-Record protocol library) operates at the message layer,
i.e. it manipulates message strings, various IM protocol libraries
(e.g we use JML for MSN, jYMSG for Yahoo! e.t.c.) may have their own
mechanisms to establish a secure connection with the server.

Have a nice week everybody!

Kind regards,
George

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