[sip-comm-dev] GSoC 09 - OTR + BouncyCastle


#1

Hello all,

I'm trying to incorporate otr4j into SIP Communicator, but I'm having some
troubles..

*I have a dummy bundle bundling it with this in build.xml*
<!-- BUNDLE-PLUGIN-OTR -->
<target name="bundle-plugin-otr">
  <!-- Creates a bundle for the plugin OTR.-->
  <jar compress="false" destfile="${bundles.dest}/otr.jar"

manifest="${src}/net/java/sip/communicator/plugin/otr/otr.manifest.mf">

        <zipfileset dir="\{dest\}/net/java/sip/communicator/plugin/otr&quot; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;prefix=&quot;net/java/sip/communicator/plugin/otr&quot;/&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;zipfileset src=&quot;{lib.noinst}/bcprov-jdk16-143.jar" prefix=""/>
  </jar>
</target>

*and this is the manifest*
Bundle-Activator: net.java.sip.communicator.plugin.otr.OtrActivator
Bundle-Name: OTR (Off-the-Record) Messaging
Bundle-Description: Support for secure, Off The Record messaging in SIP
Communicator.
Bundle-Vendor: sip-communicator.org
Bundle-Version: 0.0.1
System-Bundle: yes
Export-Package: net.java.sip.communicator.plugin.otr
Import-Package: net.java.sip.communicator.service.protocol,
net.java.sip.communicator.service.protocol.event,
net.java.sip.communicator.util,
org.osgi.framework,

I have a breakpoint inside OtrActivator.start() to see if it starts. If I
build the bundle *with* BouncyCastle the breakpoint is never reached and I
also get the exception bellow, but if I build without the BouncyCastle (i.e.
If I remove <zipfileset src="${lib.noinst}/bcprov-jdk16-143.jar"
prefix=""/>), execution stops at the breakpoint just fine...

This is the exception but it is not very informative. Is there a way to
debug this?
java.lang.NullPointerException
    at java.util.jar.Manifest$FastInputStream.fill(Unknown Source)
    at java.util.jar.Manifest$FastInputStream.readLine(Unknown Source)
    at java.util.jar.Manifest$FastInputStream.readLine(Unknown Source)
    at java.util.jar.Attributes.read(Unknown Source)
    at java.util.jar.Manifest.read(Unknown Source)
    at java.util.jar.Manifest.<init>(Unknown Source)
    at
org.apache.felix.framework.searchpolicy.ContentLoaderImpl.calculateContentPath(ContentLoaderImpl.java:344)
    at
org.apache.felix.framework.searchpolicy.ContentLoaderImpl.initializeContentPath(ContentLoaderImpl.java:315)
    at
org.apache.felix.framework.searchpolicy.ContentLoaderImpl.getClassPath(ContentLoaderImpl.java:90)
    at
org.apache.felix.framework.searchpolicy.ContentClassLoader.findClass(ContentClassLoader.java:154)
    at
org.apache.felix.framework.searchpolicy.ContentClassLoader.loadClassFromModule(ContentClassLoader.java:94)
    at
org.apache.felix.framework.searchpolicy.ContentLoaderImpl.getClass(ContentLoaderImpl.java:166)
    at
org.apache.felix.framework.searchpolicy.R4Wire.getClass(R4Wire.java:105)
    at
org.apache.felix.framework.searchpolicy.R4SearchPolicyCore.searchImports(R4SearchPolicyCore.java:505)
    at
org.apache.felix.framework.searchpolicy.R4SearchPolicyCore.findClassOrResource(R4SearchPolicyCore.java:466)
    at
org.apache.felix.framework.searchpolicy.R4SearchPolicyCore.findClass(R4SearchPolicyCore.java:185)
    at
org.apache.felix.framework.searchpolicy.R4SearchPolicy.findClass(R4SearchPolicy.java:45)
    at
org.apache.felix.moduleloader.ModuleImpl.getClass(ModuleImpl.java:216)
    at
org.apache.felix.framework.Felix.createBundleActivator(Felix.java:3468)
    at org.apache.felix.framework.Felix._startBundle(Felix.java:1649)
    at org.apache.felix.framework.Felix.startBundle(Felix.java:1578)
    at
org.apache.felix.framework.Felix.setFrameworkStartLevel(Felix.java:1172)
    at
org.apache.felix.framework.StartLevelImpl.run(StartLevelImpl.java:265)
    at java.lang.Thread.run(Unknown Source)
java.lang.NullPointerException
    at
org.apache.felix.framework.searchpolicy.ContentClassLoader.findClass(ContentClassLoader.java:154)
    at
org.apache.felix.framework.searchpolicy.ContentClassLoader.loadClassFromModule(ContentClassLoader.java:94)
    at
org.apache.felix.framework.searchpolicy.ContentLoaderImpl.getClass(ContentLoaderImpl.java:166)
    at
org.apache.felix.framework.searchpolicy.R4Wire.getClass(R4Wire.java:105)
    at
org.apache.felix.framework.searchpolicy.R4SearchPolicyCore.searchImports(R4SearchPolicyCore.java:505)
    at
org.apache.felix.framework.searchpolicy.R4SearchPolicyCore.findClassOrResource(R4SearchPolicyCore.java:466)
    at
org.apache.felix.framework.searchpolicy.R4SearchPolicyCore.findClass(R4SearchPolicyCore.java:185)
    at
org.apache.felix.framework.searchpolicy.R4SearchPolicy.findClass(R4SearchPolicy.java:45)
    at
org.apache.felix.moduleloader.ModuleImpl.getClass(ModuleImpl.java:216)
    at
org.apache.felix.framework.Felix.createBundleActivator(Felix.java:3468)
    at org.apache.felix.framework.Felix._startBundle(Felix.java:1649)
    at org.apache.felix.framework.Felix.startBundle(Felix.java:1578)
    at
org.apache.felix.framework.Felix.setFrameworkStartLevel(Felix.java:1172)
    at
org.apache.felix.framework.StartLevelImpl.run(StartLevelImpl.java:265)
    at java.lang.Thread.run(Unknown Source)


#2

Ok, we were discussing this problem and assume it has something to do
with static classes in BouncyCastle. George took a look at the zrtp
code and saw that there just some classes have been extracted from
BouncyCastle - maybe to avoid just the problem we had?

Is there some kind of global secure random source in sip-communicator
or is it in zrtp?

Any comments to this issue from the zrtp guys?

Cheers,
Uli

···

On Sun, Jun 28, 2009 at 10:52 PM, Geekius Caesar<geekius.caesar@gmail.com> wrote:

Hello all,

I'm trying to incorporate otr4j into SIP Communicator, but I'm having some
troubles..

I have a dummy bundle bundling it with this in build.xml
<!-- BUNDLE-PLUGIN-OTR -->
<target name="bundle-plugin-otr">
<!-- Creates a bundle for the plugin OTR.-->
<jar compress="false" destfile="${bundles.dest}/otr.jar"

manifest="${src}/net/java/sip/communicator/plugin/otr/otr.manifest.mf">

    &lt;zipfileset dir=&quot;$\{dest\}/net/java/sip/communicator/plugin/otr&quot;
      prefix=&quot;net/java/sip/communicator/plugin/otr&quot;/&gt;
    &lt;zipfileset src=&quot;$\{lib\.noinst\}/bcprov\-jdk16\-143\.jar&quot; prefix=&quot;&quot;/&gt;

</jar>
</target>

and this is the manifest
Bundle-Activator: net.java.sip.communicator.plugin.otr.OtrActivator
Bundle-Name: OTR (Off-the-Record) Messaging
Bundle-Description: Support for secure, Off The Record messaging in SIP
Communicator.
Bundle-Vendor: sip-communicator.org
Bundle-Version: 0.0.1
System-Bundle: yes
Export-Package: net.java.sip.communicator.plugin.otr
Import-Package: net.java.sip.communicator.service.protocol,
net.java.sip.communicator.service.protocol.event,
net.java.sip.communicator.util,
org.osgi.framework,

I have a breakpoint inside OtrActivator.start() to see if it starts. If I
build the bundle with BouncyCastle the breakpoint is never reached and I
also get the exception bellow, but if I build without the BouncyCastle (i.e.
If I remove <zipfileset src="${lib.noinst}/bcprov-jdk16-143.jar"
prefix=""/>), execution stops at the breakpoint just fine...

This is the exception but it is not very informative. Is there a way to
debug this?
java.lang.NullPointerException
at java.util.jar.Manifest$FastInputStream.fill(Unknown Source)
at java.util.jar.Manifest$FastInputStream.readLine(Unknown Source)
at java.util.jar.Manifest$FastInputStream.readLine(Unknown Source)
at java.util.jar.Attributes.read(Unknown Source)
at java.util.jar.Manifest.read(Unknown Source)
at java.util.jar.Manifest.<init>(Unknown Source)
at
org.apache.felix.framework.searchpolicy.ContentLoaderImpl.calculateContentPath(ContentLoaderImpl.java:344)
at
org.apache.felix.framework.searchpolicy.ContentLoaderImpl.initializeContentPath(ContentLoaderImpl.java:315)
at
org.apache.felix.framework.searchpolicy.ContentLoaderImpl.getClassPath(ContentLoaderImpl.java:90)
at
org.apache.felix.framework.searchpolicy.ContentClassLoader.findClass(ContentClassLoader.java:154)
at
org.apache.felix.framework.searchpolicy.ContentClassLoader.loadClassFromModule(ContentClassLoader.java:94)
at
org.apache.felix.framework.searchpolicy.ContentLoaderImpl.getClass(ContentLoaderImpl.java:166)
at
org.apache.felix.framework.searchpolicy.R4Wire.getClass(R4Wire.java:105)
at
org.apache.felix.framework.searchpolicy.R4SearchPolicyCore.searchImports(R4SearchPolicyCore.java:505)
at
org.apache.felix.framework.searchpolicy.R4SearchPolicyCore.findClassOrResource(R4SearchPolicyCore.java:466)
at
org.apache.felix.framework.searchpolicy.R4SearchPolicyCore.findClass(R4SearchPolicyCore.java:185)
at
org.apache.felix.framework.searchpolicy.R4SearchPolicy.findClass(R4SearchPolicy.java:45)
at
org.apache.felix.moduleloader.ModuleImpl.getClass(ModuleImpl.java:216)
at
org.apache.felix.framework.Felix.createBundleActivator(Felix.java:3468)
at org.apache.felix.framework.Felix._startBundle(Felix.java:1649)
at org.apache.felix.framework.Felix.startBundle(Felix.java:1578)
at
org.apache.felix.framework.Felix.setFrameworkStartLevel(Felix.java:1172)
at
org.apache.felix.framework.StartLevelImpl.run(StartLevelImpl.java:265)
at java.lang.Thread.run(Unknown Source)
java.lang.NullPointerException
at
org.apache.felix.framework.searchpolicy.ContentClassLoader.findClass(ContentClassLoader.java:154)
at
org.apache.felix.framework.searchpolicy.ContentClassLoader.loadClassFromModule(ContentClassLoader.java:94)
at
org.apache.felix.framework.searchpolicy.ContentLoaderImpl.getClass(ContentLoaderImpl.java:166)
at
org.apache.felix.framework.searchpolicy.R4Wire.getClass(R4Wire.java:105)
at
org.apache.felix.framework.searchpolicy.R4SearchPolicyCore.searchImports(R4SearchPolicyCore.java:505)
at
org.apache.felix.framework.searchpolicy.R4SearchPolicyCore.findClassOrResource(R4SearchPolicyCore.java:466)
at
org.apache.felix.framework.searchpolicy.R4SearchPolicyCore.findClass(R4SearchPolicyCore.java:185)
at
org.apache.felix.framework.searchpolicy.R4SearchPolicy.findClass(R4SearchPolicy.java:45)
at
org.apache.felix.moduleloader.ModuleImpl.getClass(ModuleImpl.java:216)
at
org.apache.felix.framework.Felix.createBundleActivator(Felix.java:3468)
at org.apache.felix.framework.Felix._startBundle(Felix.java:1649)
at org.apache.felix.framework.Felix.startBundle(Felix.java:1578)
at
org.apache.felix.framework.Felix.setFrameworkStartLevel(Felix.java:1172)
at
org.apache.felix.framework.StartLevelImpl.run(StartLevelImpl.java:265)
at java.lang.Thread.run(Unknown Source)

--
title+name: Dr. Ulrich Norbisrath
web: http://ulno.net; address+phone+fax: http://ulno.net/contact
google:unorbisrath@gmail.com; icq:46786247
mailto:ulno@ulno.net

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


#3

The main problem was that the BouncyCastle jar file is signed, so when
we do: <zipfileset src="${lib.noinst}/bcprov-
jdk16-143.jar" /> we also copy META-INF/BCKEY.DSA and META-INF/BCKEY.SF.

Apparently, if the class loader finds those 2 files, it expects a
signed jar, but our bundle is not signed, so it fails loading it.

If instead of <zipfileset src="${lib.noinst}/bcprov-jdk16-143.jar" /> we do

<zipfileset src="${lib.noinst}/bcprov-jdk16-143.jar">
    <exclude name="**/*BCKEY*"/>
</zipfileset>

Then the bundle loads fine.

···

On Mon, Jun 29, 2009 at 2:02 PM, Ulrich Norbisrath<sipcom@ulno.net> wrote:

Ok, we were discussing this problem and assume it has something to do
with static classes in BouncyCastle. George took a look at the zrtp
code and saw that there just some classes have been extracted from
BouncyCastle - maybe to avoid just the problem we had?

Is there some kind of global secure random source in sip-communicator
or is it in zrtp?

Any comments to this issue from the zrtp guys?

Cheers,
Uli

On Sun, Jun 28, 2009 at 10:52 PM, Geekius > Caesar<geekius.caesar@gmail.com> wrote:

Hello all,

I'm trying to incorporate otr4j into SIP Communicator, but I'm having some
troubles..

I have a dummy bundle bundling it with this in build.xml
<!-- BUNDLE-PLUGIN-OTR -->
<target name="bundle-plugin-otr">
<!-- Creates a bundle for the plugin OTR.-->
<jar compress="false" destfile="${bundles.dest}/otr.jar"

manifest="${src}/net/java/sip/communicator/plugin/otr/otr.manifest.mf">

    &lt;zipfileset dir=&quot;$\{dest\}/net/java/sip/communicator/plugin/otr&quot;
      prefix=&quot;net/java/sip/communicator/plugin/otr&quot;/&gt;
    &lt;zipfileset src=&quot;$\{lib\.noinst\}/bcprov\-jdk16\-143\.jar&quot; prefix=&quot;&quot;/&gt;

</jar>
</target>

and this is the manifest
Bundle-Activator: net.java.sip.communicator.plugin.otr.OtrActivator
Bundle-Name: OTR (Off-the-Record) Messaging
Bundle-Description: Support for secure, Off The Record messaging in SIP
Communicator.
Bundle-Vendor: sip-communicator.org
Bundle-Version: 0.0.1
System-Bundle: yes
Export-Package: net.java.sip.communicator.plugin.otr
Import-Package: net.java.sip.communicator.service.protocol,
net.java.sip.communicator.service.protocol.event,
net.java.sip.communicator.util,
org.osgi.framework,

I have a breakpoint inside OtrActivator.start() to see if it starts. If I
build the bundle with BouncyCastle the breakpoint is never reached and I
also get the exception bellow, but if I build without the BouncyCastle (i.e.
If I remove <zipfileset src="${lib.noinst}/bcprov-jdk16-143.jar"
prefix=""/>), execution stops at the breakpoint just fine...

This is the exception but it is not very informative. Is there a way to
debug this?
java.lang.NullPointerException
at java.util.jar.Manifest$FastInputStream.fill(Unknown Source)
at java.util.jar.Manifest$FastInputStream.readLine(Unknown Source)
at java.util.jar.Manifest$FastInputStream.readLine(Unknown Source)
at java.util.jar.Attributes.read(Unknown Source)
at java.util.jar.Manifest.read(Unknown Source)
at java.util.jar.Manifest.<init>(Unknown Source)
at
org.apache.felix.framework.searchpolicy.ContentLoaderImpl.calculateContentPath(ContentLoaderImpl.java:344)
at
org.apache.felix.framework.searchpolicy.ContentLoaderImpl.initializeContentPath(ContentLoaderImpl.java:315)
at
org.apache.felix.framework.searchpolicy.ContentLoaderImpl.getClassPath(ContentLoaderImpl.java:90)
at
org.apache.felix.framework.searchpolicy.ContentClassLoader.findClass(ContentClassLoader.java:154)
at
org.apache.felix.framework.searchpolicy.ContentClassLoader.loadClassFromModule(ContentClassLoader.java:94)
at
org.apache.felix.framework.searchpolicy.ContentLoaderImpl.getClass(ContentLoaderImpl.java:166)
at
org.apache.felix.framework.searchpolicy.R4Wire.getClass(R4Wire.java:105)
at
org.apache.felix.framework.searchpolicy.R4SearchPolicyCore.searchImports(R4SearchPolicyCore.java:505)
at
org.apache.felix.framework.searchpolicy.R4SearchPolicyCore.findClassOrResource(R4SearchPolicyCore.java:466)
at
org.apache.felix.framework.searchpolicy.R4SearchPolicyCore.findClass(R4SearchPolicyCore.java:185)
at
org.apache.felix.framework.searchpolicy.R4SearchPolicy.findClass(R4SearchPolicy.java:45)
at
org.apache.felix.moduleloader.ModuleImpl.getClass(ModuleImpl.java:216)
at
org.apache.felix.framework.Felix.createBundleActivator(Felix.java:3468)
at org.apache.felix.framework.Felix._startBundle(Felix.java:1649)
at org.apache.felix.framework.Felix.startBundle(Felix.java:1578)
at
org.apache.felix.framework.Felix.setFrameworkStartLevel(Felix.java:1172)
at
org.apache.felix.framework.StartLevelImpl.run(StartLevelImpl.java:265)
at java.lang.Thread.run(Unknown Source)
java.lang.NullPointerException
at
org.apache.felix.framework.searchpolicy.ContentClassLoader.findClass(ContentClassLoader.java:154)
at
org.apache.felix.framework.searchpolicy.ContentClassLoader.loadClassFromModule(ContentClassLoader.java:94)
at
org.apache.felix.framework.searchpolicy.ContentLoaderImpl.getClass(ContentLoaderImpl.java:166)
at
org.apache.felix.framework.searchpolicy.R4Wire.getClass(R4Wire.java:105)
at
org.apache.felix.framework.searchpolicy.R4SearchPolicyCore.searchImports(R4SearchPolicyCore.java:505)
at
org.apache.felix.framework.searchpolicy.R4SearchPolicyCore.findClassOrResource(R4SearchPolicyCore.java:466)
at
org.apache.felix.framework.searchpolicy.R4SearchPolicyCore.findClass(R4SearchPolicyCore.java:185)
at
org.apache.felix.framework.searchpolicy.R4SearchPolicy.findClass(R4SearchPolicy.java:45)
at
org.apache.felix.moduleloader.ModuleImpl.getClass(ModuleImpl.java:216)
at
org.apache.felix.framework.Felix.createBundleActivator(Felix.java:3468)
at org.apache.felix.framework.Felix._startBundle(Felix.java:1649)
at org.apache.felix.framework.Felix.startBundle(Felix.java:1578)
at
org.apache.felix.framework.Felix.setFrameworkStartLevel(Felix.java:1172)
at
org.apache.felix.framework.StartLevelImpl.run(StartLevelImpl.java:265)
at java.lang.Thread.run(Unknown Source)

--
title+name: Dr. Ulrich Norbisrath
web: http://ulno.net; address+phone+fax: http://ulno.net/contact
google:unorbisrath@gmail.com; icq:46786247
mailto:ulno@ulno.net

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


#4

George,

This was also a problem with the ZRTP implementation at one point. If
you want to use the bc jar as it is you need to add it in the
org.osgi.framework.system.packages.extra list in the
felix.client.run.properties and make sure it's in the class path. This
should resolve your problem (at least temporarily).

Werner, do you have a tip for a better solution?

Cheers
Emil

Geekius Caesar wrote:

···

The main problem was that the BouncyCastle jar file is signed, so when
we do: <zipfileset src="${lib.noinst}/bcprov-
jdk16-143.jar" /> we also copy META-INF/BCKEY.DSA and META-INF/BCKEY.SF.

Apparently, if the class loader finds those 2 files, it expects a
signed jar, but our bundle is not signed, so it fails loading it.

If instead of <zipfileset src="${lib.noinst}/bcprov-jdk16-143.jar" /> we do

<zipfileset src="${lib.noinst}/bcprov-jdk16-143.jar">
    <exclude name="**/*BCKEY*"/>
</zipfileset>

Then the bundle loads fine.

On Mon, Jun 29, 2009 at 2:02 PM, Ulrich Norbisrath<sipcom@ulno.net> wrote:

Ok, we were discussing this problem and assume it has something to do
with static classes in BouncyCastle. George took a look at the zrtp
code and saw that there just some classes have been extracted from
BouncyCastle - maybe to avoid just the problem we had?

Is there some kind of global secure random source in sip-communicator
or is it in zrtp?

Any comments to this issue from the zrtp guys?

Cheers,
Uli

On Sun, Jun 28, 2009 at 10:52 PM, Geekius >> Caesar<geekius.caesar@gmail.com> wrote:

Hello all,

I'm trying to incorporate otr4j into SIP Communicator, but I'm having some
troubles..

I have a dummy bundle bundling it with this in build.xml
<!-- BUNDLE-PLUGIN-OTR -->
<target name="bundle-plugin-otr">
  <!-- Creates a bundle for the plugin OTR.-->
  <jar compress="false" destfile="${bundles.dest}/otr.jar"

manifest="${src}/net/java/sip/communicator/plugin/otr/otr.manifest.mf">

        <zipfileset dir="\{dest\}/net/java/sip/communicator/plugin/otr&quot; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;prefix=&quot;net/java/sip/communicator/plugin/otr&quot;/&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;zipfileset src=&quot;{lib.noinst}/bcprov-jdk16-143.jar" prefix=""/>
  </jar>
</target>

and this is the manifest
Bundle-Activator: net.java.sip.communicator.plugin.otr.OtrActivator
Bundle-Name: OTR (Off-the-Record) Messaging
Bundle-Description: Support for secure, Off The Record messaging in SIP
Communicator.
Bundle-Vendor: sip-communicator.org
Bundle-Version: 0.0.1
System-Bundle: yes
Export-Package: net.java.sip.communicator.plugin.otr
Import-Package: net.java.sip.communicator.service.protocol,
net.java.sip.communicator.service.protocol.event,
net.java.sip.communicator.util,
org.osgi.framework,

I have a breakpoint inside OtrActivator.start() to see if it starts. If I
build the bundle with BouncyCastle the breakpoint is never reached and I
also get the exception bellow, but if I build without the BouncyCastle (i.e.
If I remove <zipfileset src="${lib.noinst}/bcprov-jdk16-143.jar"
prefix=""/>), execution stops at the breakpoint just fine...

This is the exception but it is not very informative. Is there a way to
debug this?
java.lang.NullPointerException
    at java.util.jar.Manifest$FastInputStream.fill(Unknown Source)
    at java.util.jar.Manifest$FastInputStream.readLine(Unknown Source)
    at java.util.jar.Manifest$FastInputStream.readLine(Unknown Source)
    at java.util.jar.Attributes.read(Unknown Source)
    at java.util.jar.Manifest.read(Unknown Source)
    at java.util.jar.Manifest.<init>(Unknown Source)
    at
org.apache.felix.framework.searchpolicy.ContentLoaderImpl.calculateContentPath(ContentLoaderImpl.java:344)
    at
org.apache.felix.framework.searchpolicy.ContentLoaderImpl.initializeContentPath(ContentLoaderImpl.java:315)
    at
org.apache.felix.framework.searchpolicy.ContentLoaderImpl.getClassPath(ContentLoaderImpl.java:90)
    at
org.apache.felix.framework.searchpolicy.ContentClassLoader.findClass(ContentClassLoader.java:154)
    at
org.apache.felix.framework.searchpolicy.ContentClassLoader.loadClassFromModule(ContentClassLoader.java:94)
    at
org.apache.felix.framework.searchpolicy.ContentLoaderImpl.getClass(ContentLoaderImpl.java:166)
    at
org.apache.felix.framework.searchpolicy.R4Wire.getClass(R4Wire.java:105)
    at
org.apache.felix.framework.searchpolicy.R4SearchPolicyCore.searchImports(R4SearchPolicyCore.java:505)
    at
org.apache.felix.framework.searchpolicy.R4SearchPolicyCore.findClassOrResource(R4SearchPolicyCore.java:466)
    at
org.apache.felix.framework.searchpolicy.R4SearchPolicyCore.findClass(R4SearchPolicyCore.java:185)
    at
org.apache.felix.framework.searchpolicy.R4SearchPolicy.findClass(R4SearchPolicy.java:45)
    at
org.apache.felix.moduleloader.ModuleImpl.getClass(ModuleImpl.java:216)
    at
org.apache.felix.framework.Felix.createBundleActivator(Felix.java:3468)
    at org.apache.felix.framework.Felix._startBundle(Felix.java:1649)
    at org.apache.felix.framework.Felix.startBundle(Felix.java:1578)
    at
org.apache.felix.framework.Felix.setFrameworkStartLevel(Felix.java:1172)
    at
org.apache.felix.framework.StartLevelImpl.run(StartLevelImpl.java:265)
    at java.lang.Thread.run(Unknown Source)
java.lang.NullPointerException
    at
org.apache.felix.framework.searchpolicy.ContentClassLoader.findClass(ContentClassLoader.java:154)
    at
org.apache.felix.framework.searchpolicy.ContentClassLoader.loadClassFromModule(ContentClassLoader.java:94)
    at
org.apache.felix.framework.searchpolicy.ContentLoaderImpl.getClass(ContentLoaderImpl.java:166)
    at
org.apache.felix.framework.searchpolicy.R4Wire.getClass(R4Wire.java:105)
    at
org.apache.felix.framework.searchpolicy.R4SearchPolicyCore.searchImports(R4SearchPolicyCore.java:505)
    at
org.apache.felix.framework.searchpolicy.R4SearchPolicyCore.findClassOrResource(R4SearchPolicyCore.java:466)
    at
org.apache.felix.framework.searchpolicy.R4SearchPolicyCore.findClass(R4SearchPolicyCore.java:185)
    at
org.apache.felix.framework.searchpolicy.R4SearchPolicy.findClass(R4SearchPolicy.java:45)
    at
org.apache.felix.moduleloader.ModuleImpl.getClass(ModuleImpl.java:216)
    at
org.apache.felix.framework.Felix.createBundleActivator(Felix.java:3468)
    at org.apache.felix.framework.Felix._startBundle(Felix.java:1649)
    at org.apache.felix.framework.Felix.startBundle(Felix.java:1578)
    at
org.apache.felix.framework.Felix.setFrameworkStartLevel(Felix.java:1172)
    at
org.apache.felix.framework.StartLevelImpl.run(StartLevelImpl.java:265)
    at java.lang.Thread.run(Unknown Source)

--
title+name: Dr. Ulrich Norbisrath
web: http://ulno.net; address+phone+fax: http://ulno.net/contact
google:unorbisrath@gmail.com; icq:46786247
mailto:ulno@ulno.net

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

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
SIP Communicator
emcho@sip-communicator.org PHONE: +33.1.77.62.43.30
http://sip-communicator.org FAX: +33.1.77.62.47.31

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


#5

George,

I couldn't look at the code right now, thus a question first:

- do you use Bouncycastle lightweight or the Java JCE and the BC
  implementation?
- I don't see where the JCE classes are imported, if you use the
  the standard JCE then some of them are imported in the Felix runtime
  properties and you might need to check if this is all you use
. If you use the BC lightweight classes then you must list them
  as import classes in the OTR manifest. You may have a look into
  the ant build file and look for the ZRTP library. The import
  is part of the library ant commands.

Regards,
Werner

Emil Ivov schrieb:

···

George,

This was also a problem with the ZRTP implementation at one point. If
you want to use the bc jar as it is you need to add it in the
org.osgi.framework.system.packages.extra list in the
felix.client.run.properties and make sure it's in the class path. This
should resolve your problem (at least temporarily).

Werner, do you have a tip for a better solution?

Cheers
Emil

Geekius Caesar wrote:

The main problem was that the BouncyCastle jar file is signed, so when
we do: <zipfileset src="${lib.noinst}/bcprov-
jdk16-143.jar" /> we also copy META-INF/BCKEY.DSA and META-INF/BCKEY.SF.

Apparently, if the class loader finds those 2 files, it expects a
signed jar, but our bundle is not signed, so it fails loading it.

If instead of <zipfileset src="${lib.noinst}/bcprov-jdk16-143.jar" /> we do

<zipfileset src="${lib.noinst}/bcprov-jdk16-143.jar">
    <exclude name="**/*BCKEY*"/>
</zipfileset>

Then the bundle loads fine.

On Mon, Jun 29, 2009 at 2:02 PM, Ulrich Norbisrath<sipcom@ulno.net> wrote:

Ok, we were discussing this problem and assume it has something to do
with static classes in BouncyCastle. George took a look at the zrtp
code and saw that there just some classes have been extracted from
BouncyCastle - maybe to avoid just the problem we had?

Is there some kind of global secure random source in sip-communicator
or is it in zrtp?

Any comments to this issue from the zrtp guys?

Cheers,
Uli

On Sun, Jun 28, 2009 at 10:52 PM, Geekius >>> Caesar<geekius.caesar@gmail.com> wrote:

Hello all,

I'm trying to incorporate otr4j into SIP Communicator, but I'm having some
troubles..

I have a dummy bundle bundling it with this in build.xml
<!-- BUNDLE-PLUGIN-OTR -->
<target name="bundle-plugin-otr">
  <!-- Creates a bundle for the plugin OTR.-->
  <jar compress="false" destfile="${bundles.dest}/otr.jar"

manifest="${src}/net/java/sip/communicator/plugin/otr/otr.manifest.mf">

        <zipfileset dir="${dest}/net/java/sip/communicator/plugin/otr"
          prefix="net/java/sip/communicator/plugin/otr"/>
        <zipfileset src="${lib.noinst}/bcprov-jdk16-143.jar" prefix=""/>
  </jar>
</target>

and this is the manifest
Bundle-Activator: net.java.sip.communicator.plugin.otr.OtrActivator
Bundle-Name: OTR (Off-the-Record) Messaging
Bundle-Description: Support for secure, Off The Record messaging in SIP
Communicator.
Bundle-Vendor: sip-communicator.org
Bundle-Version: 0.0.1
System-Bundle: yes
Export-Package: net.java.sip.communicator.plugin.otr
Import-Package: net.java.sip.communicator.service.protocol,
net.java.sip.communicator.service.protocol.event,
net.java.sip.communicator.util,
org.osgi.framework,

I have a breakpoint inside OtrActivator.start() to see if it starts. If I
build the bundle with BouncyCastle the breakpoint is never reached and I
also get the exception bellow, but if I build without the BouncyCastle (i.e.
If I remove <zipfileset src="${lib.noinst}/bcprov-jdk16-143.jar"
prefix=""/>), execution stops at the breakpoint just fine...

This is the exception but it is not very informative. Is there a way to
debug this?
java.lang.NullPointerException
    at java.util.jar.Manifest$FastInputStream.fill(Unknown Source)
    at java.util.jar.Manifest$FastInputStream.readLine(Unknown Source)
    at java.util.jar.Manifest$FastInputStream.readLine(Unknown Source)
    at java.util.jar.Attributes.read(Unknown Source)
    at java.util.jar.Manifest.read(Unknown Source)
    at java.util.jar.Manifest.<init>(Unknown Source)
    at
org.apache.felix.framework.searchpolicy.ContentLoaderImpl.calculateContentPath(ContentLoaderImpl.java:344)
    at
org.apache.felix.framework.searchpolicy.ContentLoaderImpl.initializeContentPath(ContentLoaderImpl.java:315)
    at
org.apache.felix.framework.searchpolicy.ContentLoaderImpl.getClassPath(ContentLoaderImpl.java:90)
    at
org.apache.felix.framework.searchpolicy.ContentClassLoader.findClass(ContentClassLoader.java:154)
    at
org.apache.felix.framework.searchpolicy.ContentClassLoader.loadClassFromModule(ContentClassLoader.java:94)
    at
org.apache.felix.framework.searchpolicy.ContentLoaderImpl.getClass(ContentLoaderImpl.java:166)
    at
org.apache.felix.framework.searchpolicy.R4Wire.getClass(R4Wire.java:105)
    at
org.apache.felix.framework.searchpolicy.R4SearchPolicyCore.searchImports(R4SearchPolicyCore.java:505)
    at
org.apache.felix.framework.searchpolicy.R4SearchPolicyCore.findClassOrResource(R4SearchPolicyCore.java:466)
    at
org.apache.felix.framework.searchpolicy.R4SearchPolicyCore.findClass(R4SearchPolicyCore.java:185)
    at
org.apache.felix.framework.searchpolicy.R4SearchPolicy.findClass(R4SearchPolicy.java:45)
    at
org.apache.felix.moduleloader.ModuleImpl.getClass(ModuleImpl.java:216)
    at
org.apache.felix.framework.Felix.createBundleActivator(Felix.java:3468)
    at org.apache.felix.framework.Felix._startBundle(Felix.java:1649)
    at org.apache.felix.framework.Felix.startBundle(Felix.java:1578)
    at
org.apache.felix.framework.Felix.setFrameworkStartLevel(Felix.java:1172)
    at
org.apache.felix.framework.StartLevelImpl.run(StartLevelImpl.java:265)
    at java.lang.Thread.run(Unknown Source)
java.lang.NullPointerException
    at
org.apache.felix.framework.searchpolicy.ContentClassLoader.findClass(ContentClassLoader.java:154)
    at
org.apache.felix.framework.searchpolicy.ContentClassLoader.loadClassFromModule(ContentClassLoader.java:94)
    at
org.apache.felix.framework.searchpolicy.ContentLoaderImpl.getClass(ContentLoaderImpl.java:166)
    at
org.apache.felix.framework.searchpolicy.R4Wire.getClass(R4Wire.java:105)
    at
org.apache.felix.framework.searchpolicy.R4SearchPolicyCore.searchImports(R4SearchPolicyCore.java:505)
    at
org.apache.felix.framework.searchpolicy.R4SearchPolicyCore.findClassOrResource(R4SearchPolicyCore.java:466)
    at
org.apache.felix.framework.searchpolicy.R4SearchPolicyCore.findClass(R4SearchPolicyCore.java:185)
    at
org.apache.felix.framework.searchpolicy.R4SearchPolicy.findClass(R4SearchPolicy.java:45)
    at
org.apache.felix.moduleloader.ModuleImpl.getClass(ModuleImpl.java:216)
    at
org.apache.felix.framework.Felix.createBundleActivator(Felix.java:3468)
    at org.apache.felix.framework.Felix._startBundle(Felix.java:1649)
    at org.apache.felix.framework.Felix.startBundle(Felix.java:1578)
    at
org.apache.felix.framework.Felix.setFrameworkStartLevel(Felix.java:1172)
    at
org.apache.felix.framework.StartLevelImpl.run(StartLevelImpl.java:265)
    at java.lang.Thread.run(Unknown Source)

--
title+name: Dr. Ulrich Norbisrath
web: http://ulno.net; address+phone+fax: http://ulno.net/contact
google:unorbisrath@gmail.com; icq:46786247
mailto:ulno@ulno.net

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

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


#6

Hello Werner, Emil, Ulrich

The otr4j implementation uses BouncyCastle as an alternate provider,
when I try to generate the D-H key pair (I explain why here:
http://otr4sipcomm.blogspot.com/2009/06/progress-by-june-04.html).

For the time being I followed Emil's advice. After the midterm maybe I
will make the cryptographic handling a little more abstract so it
won't be necessary to use BouncyCastle as alternate JCE provider.

I have also made a blog post with our experiences here:

···

On Mon, Jun 29, 2009 at 7:11 PM, Werner Dittmann<Werner.Dittmann@t-online.de> wrote:

George,

I couldn't look at the code right now, thus a question first:

- do you use Bouncycastle lightweight or the Java JCE and the BC
implementation?
- I don't see where the JCE classes are imported, if you use the
the standard JCE then some of them are imported in the Felix runtime
properties and you might need to check if this is all you use
. If you use the BC lightweight classes then you must list them
as import classes in the OTR manifest. You may have a look into
the ant build file and look for the ZRTP library. The import
is part of the library ant commands.

Regards,
Werner

Emil Ivov schrieb:

George,

This was also a problem with the ZRTP implementation at one point. If
you want to use the bc jar as it is you need to add it in the
org.osgi.framework.system.packages.extra list in the
felix.client.run.properties and make sure it's in the class path. This
should resolve your problem (at least temporarily).

Werner, do you have a tip for a better solution?

Cheers
Emil

Geekius Caesar wrote:

The main problem was that the BouncyCastle jar file is signed, so when
we do: <zipfileset src="${lib.noinst}/bcprov-
jdk16-143.jar" /> we also copy META-INF/BCKEY.DSA and META-INF/BCKEY.SF.

Apparently, if the class loader finds those 2 files, it expects a
signed jar, but our bundle is not signed, so it fails loading it.

If instead of <zipfileset src="${lib.noinst}/bcprov-jdk16-143.jar" /> we do

<zipfileset src="${lib.noinst}/bcprov-jdk16-143.jar">
<exclude name="**/*BCKEY*"/>
</zipfileset>

Then the bundle loads fine.

On Mon, Jun 29, 2009 at 2:02 PM, Ulrich Norbisrath<sipcom@ulno.net> wrote:

Ok, we were discussing this problem and assume it has something to do
with static classes in BouncyCastle. George took a look at the zrtp
code and saw that there just some classes have been extracted from
BouncyCastle - maybe to avoid just the problem we had?

Is there some kind of global secure random source in sip-communicator
or is it in zrtp?

Any comments to this issue from the zrtp guys?

Cheers,
Uli

On Sun, Jun 28, 2009 at 10:52 PM, Geekius >>>> Caesar<geekius.caesar@gmail.com> wrote:

Hello all,

I'm trying to incorporate otr4j into SIP Communicator, but I'm having some
troubles..

I have a dummy bundle bundling it with this in build.xml
<!-- BUNDLE-PLUGIN-OTR -->
<target name="bundle-plugin-otr">
<!-- Creates a bundle for the plugin OTR.-->
<jar compress="false" destfile="${bundles.dest}/otr.jar"

manifest="${src}/net/java/sip/communicator/plugin/otr/otr.manifest.mf">

    &lt;zipfileset dir=&quot;$\{dest\}/net/java/sip/communicator/plugin/otr&quot;
      prefix=&quot;net/java/sip/communicator/plugin/otr&quot;/&gt;
    &lt;zipfileset src=&quot;$\{lib\.noinst\}/bcprov\-jdk16\-143\.jar&quot; prefix=&quot;&quot;/&gt;

</jar>
</target>

and this is the manifest
Bundle-Activator: net.java.sip.communicator.plugin.otr.OtrActivator
Bundle-Name: OTR (Off-the-Record) Messaging
Bundle-Description: Support for secure, Off The Record messaging in SIP
Communicator.
Bundle-Vendor: sip-communicator.org
Bundle-Version: 0.0.1
System-Bundle: yes
Export-Package: net.java.sip.communicator.plugin.otr
Import-Package: net.java.sip.communicator.service.protocol,
net.java.sip.communicator.service.protocol.event,
net.java.sip.communicator.util,
org.osgi.framework,

I have a breakpoint inside OtrActivator.start() to see if it starts. If I
build the bundle with BouncyCastle the breakpoint is never reached and I
also get the exception bellow, but if I build without the BouncyCastle (i.e.
If I remove <zipfileset src="${lib.noinst}/bcprov-jdk16-143.jar"
prefix=""/>), execution stops at the breakpoint just fine...

This is the exception but it is not very informative. Is there a way to
debug this?
java.lang.NullPointerException
at java.util.jar.Manifest$FastInputStream.fill(Unknown Source)
at java.util.jar.Manifest$FastInputStream.readLine(Unknown Source)
at java.util.jar.Manifest$FastInputStream.readLine(Unknown Source)
at java.util.jar.Attributes.read(Unknown Source)
at java.util.jar.Manifest.read(Unknown Source)
at java.util.jar.Manifest.<init>(Unknown Source)
at
org.apache.felix.framework.searchpolicy.ContentLoaderImpl.calculateContentPath(ContentLoaderImpl.java:344)
at
org.apache.felix.framework.searchpolicy.ContentLoaderImpl.initializeContentPath(ContentLoaderImpl.java:315)
at
org.apache.felix.framework.searchpolicy.ContentLoaderImpl.getClassPath(ContentLoaderImpl.java:90)
at
org.apache.felix.framework.searchpolicy.ContentClassLoader.findClass(ContentClassLoader.java:154)
at
org.apache.felix.framework.searchpolicy.ContentClassLoader.loadClassFromModule(ContentClassLoader.java:94)
at
org.apache.felix.framework.searchpolicy.ContentLoaderImpl.getClass(ContentLoaderImpl.java:166)
at
org.apache.felix.framework.searchpolicy.R4Wire.getClass(R4Wire.java:105)
at
org.apache.felix.framework.searchpolicy.R4SearchPolicyCore.searchImports(R4SearchPolicyCore.java:505)
at
org.apache.felix.framework.searchpolicy.R4SearchPolicyCore.findClassOrResource(R4SearchPolicyCore.java:466)
at
org.apache.felix.framework.searchpolicy.R4SearchPolicyCore.findClass(R4SearchPolicyCore.java:185)
at
org.apache.felix.framework.searchpolicy.R4SearchPolicy.findClass(R4SearchPolicy.java:45)
at
org.apache.felix.moduleloader.ModuleImpl.getClass(ModuleImpl.java:216)
at
org.apache.felix.framework.Felix.createBundleActivator(Felix.java:3468)
at org.apache.felix.framework.Felix._startBundle(Felix.java:1649)
at org.apache.felix.framework.Felix.startBundle(Felix.java:1578)
at
org.apache.felix.framework.Felix.setFrameworkStartLevel(Felix.java:1172)
at
org.apache.felix.framework.StartLevelImpl.run(StartLevelImpl.java:265)
at java.lang.Thread.run(Unknown Source)
java.lang.NullPointerException
at
org.apache.felix.framework.searchpolicy.ContentClassLoader.findClass(ContentClassLoader.java:154)
at
org.apache.felix.framework.searchpolicy.ContentClassLoader.loadClassFromModule(ContentClassLoader.java:94)
at
org.apache.felix.framework.searchpolicy.ContentLoaderImpl.getClass(ContentLoaderImpl.java:166)
at
org.apache.felix.framework.searchpolicy.R4Wire.getClass(R4Wire.java:105)
at
org.apache.felix.framework.searchpolicy.R4SearchPolicyCore.searchImports(R4SearchPolicyCore.java:505)
at
org.apache.felix.framework.searchpolicy.R4SearchPolicyCore.findClassOrResource(R4SearchPolicyCore.java:466)
at
org.apache.felix.framework.searchpolicy.R4SearchPolicyCore.findClass(R4SearchPolicyCore.java:185)
at
org.apache.felix.framework.searchpolicy.R4SearchPolicy.findClass(R4SearchPolicy.java:45)
at
org.apache.felix.moduleloader.ModuleImpl.getClass(ModuleImpl.java:216)
at
org.apache.felix.framework.Felix.createBundleActivator(Felix.java:3468)
at org.apache.felix.framework.Felix._startBundle(Felix.java:1649)
at org.apache.felix.framework.Felix.startBundle(Felix.java:1578)
at
org.apache.felix.framework.Felix.setFrameworkStartLevel(Felix.java:1172)
at
org.apache.felix.framework.StartLevelImpl.run(StartLevelImpl.java:265)
at java.lang.Thread.run(Unknown Source)

--
title+name: Dr. Ulrich Norbisrath
web: http://ulno.net; address+phone+fax: http://ulno.net/contact
google:unorbisrath@gmail.com; icq:46786247
mailto:ulno@ulno.net

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

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

Hi all,

about this issue again, I will probably need to refactor otr4j to use the
BouncyCastle Lightweight API, as I'm facing problems using the JCE Provider.
In this link<http://otr4sipcomm.blogspot.com/2009/07/osgi-bouncycastle-round-2.html>I
discuss those problems and what I expect to gain from switching over
the
Lightweight API.

If anyone has any ideas on how to overcome the problems please let me know.

Link: http://otr4sipcomm.blogspot.com/2009/07/osgi-bouncycastle-round-2.html(in
case of text-ification of the hyperlink)

···

-
George

On Tue, Jun 30, 2009 at 1:49 AM, Geekius Caesar <geekius.caesar@gmail.com>wrote:

Hello Werner, Emil, Ulrich

The otr4j implementation uses BouncyCastle as an alternate provider,
when I try to generate the D-H key pair (I explain why here:
http://otr4sipcomm.blogspot.com/2009/06/progress-by-june-04.html).

For the time being I followed Emil's advice. After the midterm maybe I
will make the cryptographic handling a little more abstract so it
won't be necessary to use BouncyCastle as alternate JCE provider.

I have also made a blog post with our experiences here:

http://otr4sipcomm.blogspot.com/2009/06/osgi-bundle-of-bouncycastle-alternate.html

On Mon, Jun 29, 2009 at 7:11 PM, Werner > Dittmann<Werner.Dittmann@t-online.de> wrote:
> George,
>
> I couldn't look at the code right now, thus a question first:
>
> - do you use Bouncycastle lightweight or the Java JCE and the BC
> implementation?
> - I don't see where the JCE classes are imported, if you use the
> the standard JCE then some of them are imported in the Felix runtime
> properties and you might need to check if this is all you use
> . If you use the BC lightweight classes then you must list them
> as import classes in the OTR manifest. You may have a look into
> the ant build file and look for the ZRTP library. The import
> is part of the library ant commands.
>
>
> Regards,
> Werner
>
> Emil Ivov schrieb:
>> George,
>>
>> This was also a problem with the ZRTP implementation at one point. If
>> you want to use the bc jar as it is you need to add it in the
>> org.osgi.framework.system.packages.extra list in the
>> felix.client.run.properties and make sure it's in the class path. This
>> should resolve your problem (at least temporarily).
>>
>> Werner, do you have a tip for a better solution?
>>
>> Cheers
>> Emil
>>
>> Geekius Caesar wrote:
>>> The main problem was that the BouncyCastle jar file is signed, so when
>>> we do: <zipfileset src="\{lib\.noinst\}/bcprov\- &gt;&gt;&gt; jdk16\-143\.jar&quot; /&gt; we also copy META\-INF/BCKEY\.DSA and META\-INF/BCKEY\.SF\. &gt;&gt;&gt; &gt;&gt;&gt; Apparently, if the class loader finds those 2 files, it expects a &gt;&gt;&gt; signed jar, but our bundle is not signed, so it fails loading it\. &gt;&gt;&gt; &gt;&gt;&gt; If instead of &lt;zipfileset src=&quot;{lib.noinst}/bcprov-jdk16-143.jar" />
we do
>>>
>>> <zipfileset src="\{lib\.noinst\}/bcprov\-jdk16\-143\.jar&quot;&gt; &gt;&gt;&gt; &lt;exclude name=&quot;\*\*/\*BCKEY\*&quot;/&gt; &gt;&gt;&gt; &lt;/zipfileset&gt; &gt;&gt;&gt; &gt;&gt;&gt; Then the bundle loads fine\. &gt;&gt;&gt; &gt;&gt;&gt; On Mon, Jun 29, 2009 at 2:02 PM, Ulrich Norbisrath&lt;sipcom@ulno\.net&gt; &gt; wrote: &gt;&gt;&gt;&gt; Ok, we were discussing this problem and assume it has something to do &gt;&gt;&gt;&gt; with static classes in BouncyCastle\. George took a look at the zrtp &gt;&gt;&gt;&gt; code and saw that there just some classes have been extracted from &gt;&gt;&gt;&gt; BouncyCastle \- maybe to avoid just the problem we had? &gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt; Is there some kind of global secure random source in sip\-communicator &gt;&gt;&gt;&gt; or is it in zrtp? &gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt; Any comments to this issue from the zrtp guys? &gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt; Cheers, &gt;&gt;&gt;&gt; Uli &gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt; On Sun, Jun 28, 2009 at 10:52 PM, Geekius &gt; &gt;&gt;&gt;&gt; Caesar&lt;geekius\.caesar@gmail\.com&gt; wrote: &gt;&gt;&gt;&gt;&gt; Hello all, &gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt; I&#39;m trying to incorporate otr4j into SIP Communicator, but I&#39;m having some &gt;&gt;&gt;&gt;&gt; troubles\.\. &gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt; I have a dummy bundle bundling it with this in build\.xml &gt;&gt;&gt;&gt;&gt; &lt;\!\-\- BUNDLE\-PLUGIN\-OTR \-\-&gt; &gt;&gt;&gt;&gt;&gt; &lt;target name=&quot;bundle\-plugin\-otr&quot;&gt; &gt;&gt;&gt;&gt;&gt; &lt;\!\-\- Creates a bundle for the plugin OTR\.\-\-&gt; &gt;&gt;&gt;&gt;&gt; &lt;jar compress=&quot;false&quot; destfile=&quot;{bundles.dest}/otr.jar"
>>>>>
>>>>>
manifest="\{src\}/net/java/sip/communicator/plugin/otr/otr\.manifest\.mf&quot;&gt; &gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt; &lt;zipfileset dir=&quot;{dest}/net/java/sip/communicator/plugin/otr"
>>>>> prefix="net/java/sip/communicator/plugin/otr"/>
>>>>> <zipfileset src="\{lib\.noinst\}/bcprov\-jdk16\-143\.jar&quot; prefix=&quot;&quot;/&gt; &gt;&gt;&gt;&gt;&gt; &lt;/jar&gt; &gt;&gt;&gt;&gt;&gt; &lt;/target&gt; &gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt; and this is the manifest &gt;&gt;&gt;&gt;&gt; Bundle\-Activator: net\.java\.sip\.communicator\.plugin\.otr\.OtrActivator &gt;&gt;&gt;&gt;&gt; Bundle\-Name: OTR \(Off\-the\-Record\) Messaging &gt;&gt;&gt;&gt;&gt; Bundle\-Description: Support for secure, Off The Record messaging in SIP &gt;&gt;&gt;&gt;&gt; Communicator\. &gt;&gt;&gt;&gt;&gt; Bundle\-Vendor: sip\-communicator\.org &gt;&gt;&gt;&gt;&gt; Bundle\-Version: 0\.0\.1 &gt;&gt;&gt;&gt;&gt; System\-Bundle: yes &gt;&gt;&gt;&gt;&gt; Export\-Package: net\.java\.sip\.communicator\.plugin\.otr &gt;&gt;&gt;&gt;&gt; Import\-Package: net\.java\.sip\.communicator\.service\.protocol, &gt;&gt;&gt;&gt;&gt; net\.java\.sip\.communicator\.service\.protocol\.event, &gt;&gt;&gt;&gt;&gt; net\.java\.sip\.communicator\.util, &gt;&gt;&gt;&gt;&gt; org\.osgi\.framework, &gt;&gt;&gt;&gt;&gt; &gt;&gt;&gt;&gt;&gt; I have a breakpoint inside OtrActivator\.start\(\) to see if it starts\. If I &gt;&gt;&gt;&gt;&gt; build the bundle with BouncyCastle the breakpoint is never reached and I &gt;&gt;&gt;&gt;&gt; also get the exception bellow, but if I build without the BouncyCastle \(i\.e\. &gt;&gt;&gt;&gt;&gt; If I remove &lt;zipfileset src=&quot;{lib.noinst}/bcprov-jdk16-143.jar"
>>>>> prefix=""/>), execution stops at the breakpoint just fine...
>>>>>
>>>>> This is the exception but it is not very informative. Is there a way
to
>>>>> debug this?
>>>>> java.lang.NullPointerException
>>>>> at java.util.jar.Manifest$FastInputStream.fill(Unknown Source)
>>>>> at java.util.jar.Manifest$FastInputStream.readLine(Unknown
Source)
>>>>> at java.util.jar.Manifest$FastInputStream.readLine(Unknown
Source)
>>>>> at java.util.jar.Attributes.read(Unknown Source)
>>>>> at java.util.jar.Manifest.read(Unknown Source)
>>>>> at java.util.jar.Manifest.<init>(Unknown Source)
>>>>> at
>>>>>
org.apache.felix.framework.searchpolicy.ContentLoaderImpl.calculateContentPath(ContentLoaderImpl.java:344)
>>>>> at
>>>>>
org.apache.felix.framework.searchpolicy.ContentLoaderImpl.initializeContentPath(ContentLoaderImpl.java:315)
>>>>> at
>>>>>
org.apache.felix.framework.searchpolicy.ContentLoaderImpl.getClassPath(ContentLoaderImpl.java:90)
>>>>> at
>>>>>
org.apache.felix.framework.searchpolicy.ContentClassLoader.findClass(ContentClassLoader.java:154)
>>>>> at
>>>>>
org.apache.felix.framework.searchpolicy.ContentClassLoader.loadClassFromModule(ContentClassLoader.java:94)
>>>>> at
>>>>>
org.apache.felix.framework.searchpolicy.ContentLoaderImpl.getClass(ContentLoaderImpl.java:166)
>>>>> at
>>>>>
org.apache.felix.framework.searchpolicy.R4Wire.getClass(R4Wire.java:105)
>>>>> at
>>>>>
org.apache.felix.framework.searchpolicy.R4SearchPolicyCore.searchImports(R4SearchPolicyCore.java:505)
>>>>> at
>>>>>
org.apache.felix.framework.searchpolicy.R4SearchPolicyCore.findClassOrResource(R4SearchPolicyCore.java:466)
>>>>> at
>>>>>
org.apache.felix.framework.searchpolicy.R4SearchPolicyCore.findClass(R4SearchPolicyCore.java:185)
>>>>> at
>>>>>
org.apache.felix.framework.searchpolicy.R4SearchPolicy.findClass(R4SearchPolicy.java:45)
>>>>> at
>>>>>
org.apache.felix.moduleloader.ModuleImpl.getClass(ModuleImpl.java:216)
>>>>> at
>>>>>
org.apache.felix.framework.Felix.createBundleActivator(Felix.java:3468)
>>>>> at org.apache.felix.framework.Felix._startBundle(Felix.java:1649)
>>>>> at org.apache.felix.framework.Felix.startBundle(Felix.java:1578)
>>>>> at
>>>>>
org.apache.felix.framework.Felix.setFrameworkStartLevel(Felix.java:1172)
>>>>> at
>>>>>
org.apache.felix.framework.StartLevelImpl.run(StartLevelImpl.java:265)
>>>>> at java.lang.Thread.run(Unknown Source)
>>>>> java.lang.NullPointerException
>>>>> at
>>>>>
org.apache.felix.framework.searchpolicy.ContentClassLoader.findClass(ContentClassLoader.java:154)
>>>>> at
>>>>>
org.apache.felix.framework.searchpolicy.ContentClassLoader.loadClassFromModule(ContentClassLoader.java:94)
>>>>> at
>>>>>
org.apache.felix.framework.searchpolicy.ContentLoaderImpl.getClass(ContentLoaderImpl.java:166)
>>>>> at
>>>>>
org.apache.felix.framework.searchpolicy.R4Wire.getClass(R4Wire.java:105)
>>>>> at
>>>>>
org.apache.felix.framework.searchpolicy.R4SearchPolicyCore.searchImports(R4SearchPolicyCore.java:505)
>>>>> at
>>>>>
org.apache.felix.framework.searchpolicy.R4SearchPolicyCore.findClassOrResource(R4SearchPolicyCore.java:466)
>>>>> at
>>>>>
org.apache.felix.framework.searchpolicy.R4SearchPolicyCore.findClass(R4SearchPolicyCore.java:185)
>>>>> at
>>>>>
org.apache.felix.framework.searchpolicy.R4SearchPolicy.findClass(R4SearchPolicy.java:45)
>>>>> at
>>>>>
org.apache.felix.moduleloader.ModuleImpl.getClass(ModuleImpl.java:216)
>>>>> at
>>>>>
org.apache.felix.framework.Felix.createBundleActivator(Felix.java:3468)
>>>>> at org.apache.felix.framework.Felix._startBundle(Felix.java:1649)
>>>>> at org.apache.felix.framework.Felix.startBundle(Felix.java:1578)
>>>>> at
>>>>>
org.apache.felix.framework.Felix.setFrameworkStartLevel(Felix.java:1172)
>>>>> at
>>>>>
org.apache.felix.framework.StartLevelImpl.run(StartLevelImpl.java:265)
>>>>> at java.lang.Thread.run(Unknown Source)
>>>>>
>>>>>
>>>>
>>>> --
>>>> title+name: Dr. Ulrich Norbisrath
>>>> web: http://ulno.net; address+phone+fax: http://ulno.net/contact
>>>> google:unorbisrath@gmail.com <google%3Aunorbisrath@gmail.com>;
icq:46786247
>>>> mailto:ulno@ulno.net
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
>>>
>>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
> For additional commands, e-mail: dev-help@sip-communicator.dev.java.net
>
>


#8

George,

after I had a look at the blog (round 2) and a look to the mentioned
issue it could be that this is a problem of the encryption methods that
otr4j uses. Thus: does otr4j uses strong symmetrical encryption with
a key length > 128 bit?

If this is the case then the standard JCE throws exceptions as seen
in issue 647 (javax.crypto.SunJCE.*). This is independent if you use
BC or any other JCE compliant crypto provider. To test this you need
to install the "unlimited strength crypto policies" from Sun. Please
have a look here: <http://java.sun.com/javase/downloads/index.jsp>,
at the end of the page you'll find "Other downloads" where you can
download the policy file. There are also instruction how to install
this file (please keep the oribinal poilicy files somewhere you may
need them again).

Thus I would suggest some steps to quickly narrow down the problem:
- download and install the crypto policy file
- resest the felix property files to include the JCE classes only (as
  it was before your changes), it is not necessary to include the BC
  classes, they are used indirectly, but BC must be on the class path.
- same for build.xml - start with the "standard" way
- then test to see if it works - with respect to crypto stuff :slight_smile:

If you solved the crypto stuff problems you may go on and test/integrate
otr4j as planned.

However, if otr4j uses strong crypto (see above) then we may need to
use the BC lightweight to get rid of the crypto policy files. This
was the main reason to refactor zrtp4j to use BC lightweight.
Only the superuser (Windows administrator) can install the policy
files thus a simple installation of SC by any other user is not possible.

If the refactoring step is necessary then I would do it after the
integration of otr4j and the function tests run well. Otherwise you need
to test/debug two problems at once: integration/functions and the
refactoring. As Donald Knuth once said: "premature optimization is
the root of all evil". :wink:

Regards,
Werner

Geekius Caesar schrieb:

Hi all,

about this issue again, I will probably need to refactor otr4j to use the
BouncyCastle Lightweight API, as I'm facing problems using the JCE Provider.
In this link<http://otr4sipcomm.blogspot.com/2009/07/osgi-bouncycastle-round-2.html>I
discuss those problems and what I expect to gain from switching over
the
Lightweight API.

If anyone has any ideas on how to overcome the problems please let me know.

Link: http://otr4sipcomm.blogspot.com/2009/07/osgi-bouncycastle-round-2.html(in
case of text-ification of the hyperlink)
-
George

Hello Werner, Emil, Ulrich

The otr4j implementation uses BouncyCastle as an alternate provider,
when I try to generate the D-H key pair (I explain why here:
http://otr4sipcomm.blogspot.com/2009/06/progress-by-june-04.html).

For the time being I followed Emil's advice. After the midterm maybe I
will make the cryptographic handling a little more abstract so it
won't be necessary to use BouncyCastle as alternate JCE provider.

I have also made a blog post with our experiences here:

http://otr4sipcomm.blogspot.com/2009/06/osgi-bundle-of-bouncycastle-alternate.html

George,

I couldn't look at the code right now, thus a question first:

- do you use Bouncycastle lightweight or the Java JCE and the BC
implementation?
- I don't see where the JCE classes are imported, if you use the
the standard JCE then some of them are imported in the Felix runtime
properties and you might need to check if this is all you use
. If you use the BC lightweight classes then you must list them
as import classes in the OTR manifest. You may have a look into
the ant build file and look for the ZRTP library. The import
is part of the library ant commands.

Regards,
Werner

<SNIP --- SNAP>

···

On Tue, Jun 30, 2009 at 1:49 AM, Geekius Caesar <geekius.caesar@gmail.com>wrote:

On Mon, Jun 29, 2009 at 7:11 PM, Werner >> Dittmann<Werner.Dittmann@t-online.de> wrote:

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


#9

George,

some additional info: I've seen issue reports that even a AES 128bit
could lead to the security exception as shown in the console
screen shot. Thus it may be necessary to install the crypto policies
in any case (see below).

Regards,
Werner

Werner Dittmann schrieb:

George,

after I had a look at the blog (round 2) and a look to the mentioned
issue it could be that this is a problem of the encryption methods that
otr4j uses. Thus: does otr4j uses strong symmetrical encryption with
a key length > 128 bit?

If this is the case then the standard JCE throws exceptions as seen
in issue 647 (javax.crypto.SunJCE.*). This is independent if you use
BC or any other JCE compliant crypto provider. To test this you need
to install the "unlimited strength crypto policies" from Sun. Please
have a look here: <http://java.sun.com/javase/downloads/index.jsp>,
at the end of the page you'll find "Other downloads" where you can
download the policy file. There are also instruction how to install
this file (please keep the oribinal poilicy files somewhere you may
need them again).

Thus I would suggest some steps to quickly narrow down the problem:
- download and install the crypto policy file
- resest the felix property files to include the JCE classes only (as
  it was before your changes), it is not necessary to include the BC
  classes, they are used indirectly, but BC must be on the class path.
- same for build.xml - start with the "standard" way
- then test to see if it works - with respect to crypto stuff :slight_smile:

If you solved the crypto stuff problems you may go on and test/integrate
otr4j as planned.

However, if otr4j uses strong crypto (see above) then we may need to
use the BC lightweight to get rid of the crypto policy files. This
was the main reason to refactor zrtp4j to use BC lightweight.
Only the superuser (Windows administrator) can install the policy
files thus a simple installation of SC by any other user is not possible.

If the refactoring step is necessary then I would do it after the
integration of otr4j and the function tests run well. Otherwise you need
to test/debug two problems at once: integration/functions and the
refactoring. As Donald Knuth once said: "premature optimization is
the root of all evil". :wink:

Regards,
Werner

Geekius Caesar schrieb:

Hi all,

about this issue again, I will probably need to refactor otr4j to use the
BouncyCastle Lightweight API, as I'm facing problems using the JCE Provider.
In this link<http://otr4sipcomm.blogspot.com/2009/07/osgi-bouncycastle-round-2.html>I
discuss those problems and what I expect to gain from switching over
the
Lightweight API.

If anyone has any ideas on how to overcome the problems please let me know.

Link: http://otr4sipcomm.blogspot.com/2009/07/osgi-bouncycastle-round-2.html(in
case of text-ification of the hyperlink)
-
George

<SNIP --- SNAP>

···

On Tue, Jun 30, 2009 at 1:49 AM, Geekius Caesar <geekius.caesar@gmail.com>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

Hello Werner, thank you very much for your extensive reply.

Thus I would suggest some steps to quickly narrow down the problem:
- download and install the crypto policy file

After installing the policy files, __Problem A__ is gone :smiley:

A weird thing to note is that the problem does not manifest during
otr4j tests running (either from the command line, or from within
Eclipse). Those tests cover all of the encryption/decryption
functionality (OTR protocol uses AES128-CTR and Diffie-Hellman with
1536 bit modulus).

- resest the felix property files to include the JCE classes only (as
it was before your changes), it is not necessary to include the BC
classes, they are used indirectly, but BC must be on the class path.
- same for build.xml - start with the "standard" way

I removed all of the BouncyCastle classes from
org.osgi.framework.system.packages.extra and from the Package-Import
property of the otr plugin bundle (and made sure BouncyCastle is in my
classpath, a dummy class with import org.bouncycastle.* compiled
successfully).

As soon as I did that, I started getting NoClassDefFoundError
exceptions. I think some stuff needs to be in the
org.osgi.framework.system.packages.extra and in the Package-Import
property in order to get access to the bootstraping classpath from
OSGi (I'm not sure if I understood correctly:
http://blog.springsource.com/2009/01/19/exposing-the-boot-classpath-in-osgi/)

- then test to see if it works - with respect to crypto stuff :slight_smile:

Having done the above things, __Problem A__ is solved, but __Problem
B__ and __Problem C__ are still there and essentially prevent
debugging (they are manifested only when I launch SIP Communicator
from withing Eclipse as I describe in the blog post).

__Problem B__ seems to be a class loader problem
(http://osdir.com/ml/encryption.bouncy-castle.devel/2007/msg00157.html).
This guess makes sense, because when Eclipse launches SIP Communicator
sets the classpath to whatever the buildpath is. The buildpath
contains both bouncycastle and zrtp which both export
org.bouncycastle.crypto.*, so chances are there is a conflict there
and thus I get the SecurityException __class
"org.bouncycastle.crypto.CipherParameters"'s signer information does
not match signer information of other classes in the same package__.

As I said before, this problem manifests only when we run SIP
Communicator from within Eclipse, but this is essential for debugging.

__Problem C__ cannot be resolved since we cannot modify the
bouncycastle signed jar file.

(a few minutes later...)

I just removed zrtp4j-light from Eclipse build path, and this fixes
__Problem B__. Maybe we should consider building a BouncyCastle
lightweight API bundle and both zrtp4j and otr4j use it's packages or
ship the BouncyCastle provider and add it in
org.osgi.framework.system.packages.extra.

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


#11

George,

good to hear that at least one problem is solved. Pls keep pind mind
that if you do an update of Java you need to re-install the
policy files again.

Regarding the other problems: I never use Eclipse to start and
debug SC, I always use the old-fashioned way and use
ant rebuild (or ant make) and then ant run and have println
statements ate the right places. I mainly did this because
of two reasons: first to have a clean start and no class-loading
problems, I had problems in other projects in that respect. The
second reason is more ZRTP orientd: ZRTP is a protcol with
fairly strict timing requirements, thus a breakpoint would
cause more trouble then it helps.

Can you first test if SC works (starts without classloader problems)
using ant and without Eclispe before you start to use Eclipse?
Maybe this way you can narrow down the problems a bit.

AFAIK to MSN protocol uses JCE as well, maybe you can have a look
at its manifest to see what it imports with respect to crypto
stuff.

Regads,
Werner

Geekius Caesar schrieb:

···

Hello Werner, thank you very much for your extensive reply.

Thus I would suggest some steps to quickly narrow down the problem:
- download and install the crypto policy file

After installing the policy files, __Problem A__ is gone :smiley:

A weird thing to note is that the problem does not manifest during
otr4j tests running (either from the command line, or from within
Eclipse). Those tests cover all of the encryption/decryption
functionality (OTR protocol uses AES128-CTR and Diffie-Hellman with
1536 bit modulus).

- resest the felix property files to include the JCE classes only (as
it was before your changes), it is not necessary to include the BC
classes, they are used indirectly, but BC must be on the class path.
- same for build.xml - start with the "standard" way

I removed all of the BouncyCastle classes from
org.osgi.framework.system.packages.extra and from the Package-Import
property of the otr plugin bundle (and made sure BouncyCastle is in my
classpath, a dummy class with import org.bouncycastle.* compiled
successfully).

As soon as I did that, I started getting NoClassDefFoundError
exceptions. I think some stuff needs to be in the
org.osgi.framework.system.packages.extra and in the Package-Import
property in order to get access to the bootstraping classpath from
OSGi (I'm not sure if I understood correctly:
http://blog.springsource.com/2009/01/19/exposing-the-boot-classpath-in-osgi/)

- then test to see if it works - with respect to crypto stuff :slight_smile:

Having done the above things, __Problem A__ is solved, but __Problem
B__ and __Problem C__ are still there and essentially prevent
debugging (they are manifested only when I launch SIP Communicator
from withing Eclipse as I describe in the blog post).

__Problem B__ seems to be a class loader problem
(http://osdir.com/ml/encryption.bouncy-castle.devel/2007/msg00157.html).
This guess makes sense, because when Eclipse launches SIP Communicator
sets the classpath to whatever the buildpath is. The buildpath
contains both bouncycastle and zrtp which both export
org.bouncycastle.crypto.*, so chances are there is a conflict there
and thus I get the SecurityException __class
"org.bouncycastle.crypto.CipherParameters"'s signer information does
not match signer information of other classes in the same package__.

As I said before, this problem manifests only when we run SIP
Communicator from within Eclipse, but this is essential for debugging.

__Problem C__ cannot be resolved since we cannot modify the
bouncycastle signed jar file.

(a few minutes later...)

I just removed zrtp4j-light from Eclipse build path, and this fixes
__Problem B__. Maybe we should consider building a BouncyCastle
lightweight API bundle and both zrtp4j and otr4j use it's packages or
ship the BouncyCastle provider and add it in
org.osgi.framework.system.packages.extra.

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

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


#12

Hey George,

(a few minutes later...)

I just removed zrtp4j-light from Eclipse build path, and this fixes
__Problem B__. Maybe we should consider building a BouncyCastle
lightweight API bundle and both zrtp4j and otr4j use it's packages

I am not sure I understand your suggestion. Providing a separate
bundle for the BouncyCastle lightweight API does make sense from a
general perspective, but I don't quite see how it would resolve your
issue. What would be the difference between that new bundle and what's
already in (and exported by) zrtp4j-light?

or ship the BouncyCastle provider and add it in
org.osgi.framework.system.packages.extra.

I'd really prefer to keeping non-bundle-ized dependencies to a
minimum. Adding packages in there is fine for testing but makes things
somewhat messier otherwise, so I'd prefer to avoid it if possible.

Cheers
Emil

···

On Sat, Jul 4, 2009 at 3:22 PM, Geekius Caesar<geekius.caesar@gmail.com> wrote:


#13

George,

Emil Ivov schrieb:

Hey George,

(a few minutes later...)

I just removed zrtp4j-light from Eclipse build path, and this fixes
__Problem B__. Maybe we should consider building a BouncyCastle
lightweight API bundle and both zrtp4j and otr4j use it's packages

hmm - not sure if this works out. Beause the number of classes and
and functions that OTR needs is small (compared to a full blown
JCE libs :slight_smile: ) it could make sense that you extract only those
that OTR requires and put it into the ORT lib, similar as it was
done for zrtp4j. This keeps the libs independent of each other because
as far as I understand otr4j coulkd be used in other projects as
well (similar as zrtp4j can be used in other projects).

Todfa I'll do a complete checkout of your SVN tree in and keep
it updated so that we have the same base to discuss

Regards,
Werner

···

On Sat, Jul 4, 2009 at 3:22 PM, Geekius Caesar<geekius.caesar@gmail.com> wrote:

I am not sure I understand your suggestion. Providing a separate
bundle for the BouncyCastle lightweight API does make sense from a
general perspective, but I don't quite see how it would resolve your
issue. What would be the difference between that new bundle and what's
already in (and exported by) zrtp4j-light?

or ship the BouncyCastle provider and add it in
org.osgi.framework.system.packages.extra.

I'd really prefer to keeping non-bundle-ized dependencies to a
minimum. Adding packages in there is fine for testing but makes things
somewhat messier otherwise, so I'd prefer to avoid it if possible.

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

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


#14

I agree we don't really need all the BouncyCastle, because of it's huge size
(Emil made this very clear to me!).

I think that even without the full set of BouncyCastle classes, we could
still have a trimmed down BouncyCastle bundle (like very-light-bc.jar) which
will contain the functionality needed by otr4j and zrtp4j. There is even the
org.sip.commmunicator.util.Base64 which essentially is the BouncyCastle
encoder/decoder (it is mentioned in the class file off course), but maybe we
could import that too from the very-light-bc.jar, (a Base64 encoded/decoder
is essential for the otr protocol so we will have to include that in
very-light-bc.jar).

That said, if I added the required BouncyCastle classes directly in otr4j it
might work, but still there are some very fundamental interfaces that both
zrtp4j and otr4j should contain -like the
org.bouncycastle.crypto.CipherParameters interface-, which could lead to the
same problems again (Problem B in the post).

Best regards,
George

···

On Sun, Jul 5, 2009 at 9:22 AM, Werner Dittmann <Werner.Dittmann@t-online.de > wrote:

George,

Emil Ivov schrieb:
> Hey George,
>
> On Sat, Jul 4, 2009 at 3:22 PM, Geekius Caesar<geekius.caesar@gmail.com> > wrote:
>> (a few minutes later...)
>>
>> I just removed zrtp4j-light from Eclipse build path, and this fixes
>> __Problem B__. Maybe we should consider building a BouncyCastle
>> lightweight API bundle and both zrtp4j and otr4j use it's packages

hmm - not sure if this works out. Beause the number of classes and
and functions that OTR needs is small (compared to a full blown
JCE libs :slight_smile: ) it could make sense that you extract only those
that OTR requires and put it into the ORT lib, similar as it was
done for zrtp4j. This keeps the libs independent of each other because
as far as I understand otr4j coulkd be used in other projects as
well (similar as zrtp4j can be used in other projects).

Todfa I'll do a complete checkout of your SVN tree in and keep
it updated so that we have the same base to discuss

Regards,
Werner

>
> I am not sure I understand your suggestion. Providing a separate
> bundle for the BouncyCastle lightweight API does make sense from a
> general perspective, but I don't quite see how it would resolve your
> issue. What would be the difference between that new bundle and what's
> already in (and exported by) zrtp4j-light?
>
>> or ship the BouncyCastle provider and add it in
>> org.osgi.framework.system.packages.extra.
>
> I'd really prefer to keeping non-bundle-ized dependencies to a
> minimum. Adding packages in there is fine for testing but makes things
> somewhat messier otherwise, so I'd prefer to avoid it if possible.
>
> 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
>
>

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


#15

Hey George,

George Politis wrote:

I agree we don't really need all the BouncyCastle, because of it's huge
size (Emil made this very clear to me!).

I think that even without the full set of BouncyCastle classes, we could
still have a trimmed down BouncyCastle bundle (like very-light-bc.jar)
which will contain the functionality needed by otr4j and zrtp4j.

This would indeed make sense if there's a substantial set of classes
needed by both.

There
is even the org.sip.commmunicator.util.Base64 which essentially is the
BouncyCastle encoder/decoder (it is mentioned in the class file off
course), but maybe we could import that too from the very-light-bc.jar,
(a Base64 encoded/decoder is essential for the otr protocol so we will
have to include that in very-light-bc.jar).

I wouldn't worry about Base64 and keep it where it is. Its use goes
beyond cryptography and bc so we could keep it where it is.

That said, if I added the required BouncyCastle classes directly in
otr4j it might work, but still there are some very fundamental
interfaces that both zrtp4j and otr4j should contain -like the
org.bouncycastle.crypto.CipherParameters interface-, which could lead to
the same problems again (Problem B in the post).

As a matter of fact that won't really be a problem since if both libs
contain it, their respective bundles won't be exporting it and hence no
class would be able to reference both of them. The only reasons to have
a very-light-bc.jar would be to avoid duplication and improve
organization (which doesn't mean they aren't good enough).

Cheers
Emil

···

Best regards,
George

On Sun, Jul 5, 2009 at 9:22 AM, Werner Dittmann > <Werner.Dittmann@t-online.de <mailto:Werner.Dittmann@t-online.de>> wrote:

    George,

    Emil Ivov schrieb:
    > Hey George,
    >
    > On Sat, Jul 4, 2009 at 3:22 PM, Geekius > Caesar<geekius.caesar@gmail.com <mailto:geekius.caesar@gmail.com>> > wrote:
    >> (a few minutes later...)
    >>
    >> I just removed zrtp4j-light from Eclipse build path, and this fixes
    >> __Problem B__. Maybe we should consider building a BouncyCastle
    >> lightweight API bundle and both zrtp4j and otr4j use it's packages

    hmm - not sure if this works out. Beause the number of classes and
    and functions that OTR needs is small (compared to a full blown
    JCE libs :slight_smile: ) it could make sense that you extract only those
    that OTR requires and put it into the ORT lib, similar as it was
    done for zrtp4j. This keeps the libs independent of each other because
    as far as I understand otr4j coulkd be used in other projects as
    well (similar as zrtp4j can be used in other projects).

    Todfa I'll do a complete checkout of your SVN tree in and keep
    it updated so that we have the same base to discuss

    Regards,
    Werner

    >
    > I am not sure I understand your suggestion. Providing a separate
    > bundle for the BouncyCastle lightweight API does make sense from a
    > general perspective, but I don't quite see how it would resolve your
    > issue. What would be the difference between that new bundle and what's
    > already in (and exported by) zrtp4j-light?
    >
    >> or ship the BouncyCastle provider and add it in
    >> org.osgi.framework.system.packages.extra.
    >
    > I'd really prefer to keeping non-bundle-ized dependencies to a
    > minimum. Adding packages in there is fine for testing but makes things
    > somewhat messier otherwise, so I'd prefer to avoid it if possible.
    >
    > Cheers
    > Emil
    >
    > ---------------------------------------------------------------------
    > To unsubscribe, e-mail:
    dev-unsubscribe@sip-communicator.dev.java.net
    <mailto:dev-unsubscribe@sip-communicator.dev.java.net>
    > For additional commands, e-mail:
    dev-help@sip-communicator.dev.java.net
    <mailto:dev-help@sip-communicator.dev.java.net>
    >
    >

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

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
SIP Communicator
emcho@sip-communicator.org PHONE: +33.1.77.62.43.30
http://sip-communicator.org FAX: +33.1.77.62.47.31

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


#16

George, Emil,

Emil Ivov schrieb:

Hey George,

George Politis wrote:

I agree we don't really need all the BouncyCastle, because of it's huge
size (Emil made this very clear to me!).

I think that even without the full set of BouncyCastle classes, we could
still have a trimmed down BouncyCastle bundle (like very-light-bc.jar)
which will contain the functionality needed by otr4j and zrtp4j.

This would indeed make sense if there's a substantial set of classes
needed by both.

There
is even the org.sip.commmunicator.util.Base64 which essentially is the
BouncyCastle encoder/decoder (it is mentioned in the class file off
course), but maybe we could import that too from the very-light-bc.jar,
(a Base64 encoded/decoder is essential for the otr protocol so we will
have to include that in very-light-bc.jar).

I wouldn't worry about Base64 and keep it where it is. Its use goes
beyond cryptography and bc so we could keep it where it is.

That said, if I added the required BouncyCastle classes directly in
otr4j it might work, but still there are some very fundamental
interfaces that both zrtp4j and otr4j should contain -like the
org.bouncycastle.crypto.CipherParameters interface-, which could lead to
the same problems again (Problem B in the post).

As a matter of fact that won't really be a problem since if both libs
contain it, their respective bundles won't be exporting it and hence no
class would be able to reference both of them. The only reasons to have
a very-light-bc.jar would be to avoid duplication and improve
organization (which doesn't mean they aren't good enough).

As a matter of fact the zrtp4j bundle exports the BC part because the
the SRTP classes need these BC classes as well. That was the reason to export
them. Thus IMHO it would make sense to build the very lightweight BC lib for
ZRTP, OTR, and SRTP and later on maybe others as well.

I've all the necessary sources on my system and also have the build files
around. What I can offer is to create a small project and create
the lib. This would be a system lib and thus we need to import the classes
in the felix properties file.

George, can you provide me with a short list of crypto functions that
OTR requires? I know the following:

- DH
- HMAC (which digest to use with the HMAC? SHA256?)
- SHA256 digest
- AES Counter mode (CTR)

anything else?

Regards,
Werner

Cheers
Emil

<SNIP --- SNAP>

···

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


#17

Hey Werner,

Werner Dittmann wrote:

As a matter of fact the zrtp4j bundle exports the BC part because the
the SRTP classes need these BC classes as well. That was the reason to export
them. Thus IMHO it would make sense to build the very lightweight BC lib for
ZRTP, OTR, and SRTP and later on maybe others as well.

Oh yes indeed. Well, then the very-light-bc.jar just sounds better and
better.

I've all the necessary sources on my system and also have the build files
around. What I can offer is to create a small project and create
the lib. This would be a system lib and thus we need to import the classes
in the felix properties file.

Is there any reason not to have this as a bundle?

Having it as a system lib would require modifying startup scripts, run
targets, and some of the platform installers to explicitly include it.
Turning it into a bundle during the build process (just like we turn
zrtp4j-light.jar into the zrtp4j.jar bundle) would be better. Do you see
a problem with this?

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


#18

George, can you provide me with a short list of crypto functions that
OTR requires? I know the following:

- DH
- HMAC (which digest to use with the HMAC? SHA256?)
- SHA256 digest
- AES Counter mode (CTR)

anything else?

Hello Werner,

I think it's Base64 encoding/decoding as well, also both SHA256 and SHA1 HMAC.

In my branch I have already created the bc bundle but it's not light
yet, I would like to have complete OTR functionality first (for this
purpose I recompiled zrtp4j without the bc classes).

Best 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


#19

Emil, George,

Emil Ivov schrieb:

Hey Werner,

Is there any reason not to have this as a bundle?

Having it as a system lib would require modifying startup scripts, run
targets, and some of the platform installers to explicitly include it.
Turning it into a bundle during the build process (just like we turn
zrtp4j-light.jar into the zrtp4j.jar bundle) would be better. Do you see
a problem with this?

Actually no problem - just didn't thought about a bundle :slight_smile:

Regards,
Werner

···

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

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


#20

George,

Geekius Caesar schrieb:

George, can you provide me with a short list of crypto functions that
OTR requires? I know the following:

- DH
- HMAC (which digest to use with the HMAC? SHA256?)
- SHA256 digest
- AES Counter mode (CTR)

anything else?

Hello Werner,

I think it's Base64 encoding/decoding as well, also both SHA256 and SHA1 HMAC.

Fine. Then only the AES-Counter mode (called SIC mode in BC light) and
Base64 is missing from the current BC funtions contained in zrtp4j. All
the rest should be available because ZRTP and SRTP also use plain SHA256
and SHA1 as well as for HMAC. Thus we can use this as the basis to create
the bc-very-light.

As for DH: zrtp4j contains DH functions that use a specific, crypto-secure
variant of BigInteger. After you finalized the OTR functions we can discuss
if you like to use them as well (it's the same functionality, just other
class names/packages).

In my branch I have already created the bc bundle but it's not light
yet, I would like to have complete OTR functionality first (for this
purpose I recompiled zrtp4j without the bc classes).

Ok, first the full OTR functions. After you've done this we can coordinate
how to integrate the bc-very-light.

Regards,
Werner

···

Best 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

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