In OSGi + BouncyCastle Round 2 I described the problems I was facing while trying to wire up BouncyCastle in SIP Communicator, so as to be used as alternate JCE provider. There where two important problems.
Problem A is this exception [java] java.net.MalformedURLException: invalid url: reference:file:sc-bundles/protocol-msn.jar!/ (java.net.MalformedURLException: Unknown protocol: reference) during AES128-CTR encryption.
The solution to this problem was found by Werner Dittmann in this email. Briefly, I needed to install the "unlimited strength crypto policies" from Sun which are available here in the Other Downloads section. This is not an acceptable solution off course, so we will have to find an alternative (which is pretty obvious, drop the alternative JCE provider and use BouncyCastle Lightweight API).
Problem B is that running SIP Communicator from within Eclipse, and only from within Eclipse, the bundle-plugin-otr fails to generate a D-H key pair using BouncyCastle as alternate provider with class "org.bouncycastle.crypto.CipherParameters"'s signer information does not match signer information of other classes in the same package.
This email in the BouncyCastle developers mailing list mentions that the cause for this exception most likely is an incorrect installation of BouncyCastle, which in my case I guess that means a class path problem.
This guess makes sense, because when Eclipse launches SIP Communicator sets the classpath to whatever the buildpath is. The buildpath in my case contained both bouncycastle and zrtp4j which both export org.bouncycastle.crypto.*. Apparently there is a conflict there.
In this case we could have a bouncycastle bundle that both otr4j and zrtp4j will use or remove zrtp4j from the classpath (we could also update the "How to configure Eclipse to compile and debug SIP Communicator" to contain only the most required libs, like felix, in the classpath).
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment