[jitsi-dev] Re: Comment posted on jitsi


#1

Hi guys,

I'm resending one of the last comments we got when trying to include
the jitsi debian package into the official repositories.
I already answered there about dnsjava, we have created an updated
package and already has a mentor for the package.
But what about the other two: bouncycastle and portaudio.
Can we easily use the repository packages and just miss some of the
functionalities, like hotplug when using portaudio.
Will the ZRTP/SRTP work with the bouncycastle from the Debian
repository (1.46), will there be any other problems?
WDYT?

Thanks
damencho

···

On Mon, Mar 18, 2013 at 11:39 PM, mentors.debian.net <support@mentors.debian.net> wrote:

A comment has been posted on a package that you are subscribed to.

Kurt Roeckx made the following comment about the jitsi package:

I think the biggest concern now is libraries that are forked and in Debian. I count 3 of those:
- bouncycastle
- dnsjava
- portaudio

I think bouncycastle is on the top of that list because it has an open security issue, and an other open release critical bug. And I really like to avoid having 2 copies of that library in Debian.

You can view information on the package by visiting:

http://mentors.debian.net/package/jitsi

You can change your subscription by visiting your user account settings.

Thanks,

--
mentors.debian.net

.


#2

I guess we could simply explain that portaudio is a fork and not equivalent
to the one on debian.

I believe that bouncycastle was modified for size concerns only, so we may
just work with the original version now changes. Werner, Ingo, please
correct me if I am wrong.

--sent from my mobile

···

On Mar 19, 2013 8:39 AM, "Damian Minkov" <damencho@jitsi.org> wrote:

Hi guys,

I'm resending one of the last comments we got when trying to include
the jitsi debian package into the official repositories.
I already answered there about dnsjava, we have created an updated
package and already has a mentor for the package.
But what about the other two: bouncycastle and portaudio.
Can we easily use the repository packages and just miss some of the
functionalities, like hotplug when using portaudio.
Will the ZRTP/SRTP work with the bouncycastle from the Debian
repository (1.46), will there be any other problems?
WDYT?

Thanks
damencho

On Mon, Mar 18, 2013 at 11:39 PM, mentors.debian.net > <support@mentors.debian.net> wrote:
> A comment has been posted on a package that you are subscribed to.
>
> Kurt Roeckx made the following comment about the jitsi package:
>
> I think the biggest concern now is libraries that are forked and in
Debian. I count 3 of those:
> - bouncycastle
> - dnsjava
> - portaudio
>
> I think bouncycastle is on the top of that list because it has an open
security issue, and an other open release critical bug. And I really like
to avoid having 2 copies of that library in Debian.
>
>
>
> You can view information on the package by visiting:
>
> http://mentors.debian.net/package/jitsi
>
> You can change your subscription by visiting your user account settings.
>
> Thanks,
>
> --
> mentors.debian.net


#3

I believe that bouncycastle was modified for size concerns only, so we
may just work with the original version now changes. Werner, Ingo,
please correct me if I am wrong.

Yes and no:
- SDES uses standard crypto stuff only
- The certificate stuff would be fine with regular BC too
- SRTP and ZRTP include code for the Skein and Threefish algorithms, both
are not included in the standard BC lib. Werner wanted to contribute them
years ago, but it apparently never made it [1]. Given that the NIST now has
chosen Keccak over Skein for SHA3, I don't really see the point of including
it (but the ZRTP RFC suggests to support it). There's however no reason this
has to be inside a modified BC library.

Then there was also something about a "BigInteger better suited for crypto".
All I could find [2] is that this thing lives inside ZRTP4j, so it should
not be an issue for using the regular BC.

Ingo

[1]
http://bouncy-castle.1462172.n4.nabble.com/Skein-and-Threefish-for-Bouncy-Ca
stle-td3169174.html
[2]
https://github.com/search?p=4&q=BigIntegerCrypto+%40wernerd+extension%3Ajava
&ref=searchresults&type=Code


#4

Sorry that I respond somewhat late - the subject line of the e-mails didn't
trigger my attention :slight_smile:

I believe that bouncycastle was modified for size concerns only, so we
may just work with the original version now changes. Werner, Ingo,
please correct me if I am wrong.

yes, that was the main motivation when I created the smaller lib. The size
of the normal BC lib (1.48) is ~2.2MB whereas the reduced lib is < 200KB,
thus a factor of 10. AFAIK the lib is packaged together with Jitsi and thus
contributes to the overall size of the Jitsi package. Will this be changed
for Debian?

Yes and no:
- SDES uses standard crypto stuff only
- The certificate stuff would be fine with regular BC too
- SRTP and ZRTP include code for the Skein and Threefish algorithms, both
are not included in the standard BC lib. Werner wanted to contribute them
years ago, but it apparently never made it [1]. Given that the NIST now has
chosen Keccak over Skein for SHA3, I don't really see the point of including
it (but the ZRTP RFC suggests to support it). There's however no reason this
has to be inside a modified BC library.

Actually we have two extensions:
- Skein/Threefish as a additional Hash algorithm
- Fortuna random number generator

Both extensions use some BC base class to be compliant to the standard BC
look-and-feel. Some remarks about these extensions:
  As Ingo pointed out above Skein was proposed by RFC6189 and thus implemented.
Also Skein is faster than the standard SHA256/SHA384 based MAC. Nevertheless
we could even remove Skein and are still ZRTP compatible.
  More important is the random number generator. The Diffie-Helman algorithms
(both normal and ECC) and AFAIK also SDES require some very good random number
generator. The current BC PRNG implementations are not considered as
cryptographically strong random generators. The standard Java Random implementation
falls into the same class (only 48-bit seed). Fortuna is a much better generator
and we seed it with a lot of random data that we gather from the microphone during
start up of Jitsi.

Removing the Fortuna would be more critical. I may be able to move it into the
ZRTP lib without to many modifications (need to check this).

Then there was also something about a "BigInteger better suited for crypto".
All I could find [2] is that this thing lives inside ZRTP4j, so it should
not be an issue for using the regular BC.

Some background on this: the standard Java BigInteger class is non-mutable, similar
to Java String. Thus you cannot clear the contents of a BigInteger object even if
you don't use it anymore.
But most important is the fact that we cannot clear the data after we computed the
results, for example DH results. To make it more clear: with standard BigInteger
the DH results would stay for some time on the Java heap until some GC mechanism
decides to reuse the memory. This opens a window to snoop and analyze memory and
thus one could recover the DH results which breaks security. I did some modifications
on the GNU (Classpath) BigInteger class to provide at least the "clear data" function.
Thus this class performs some "clear data" internally and has a method that the ZRTP
classes use to clear the DH results and keys before it releases the BigInteger objects.

Werner

···

Am 19.03.2013 10:54, schrieb Ingo Bauersachs:

Ingo

[1]
http://bouncy-castle.1462172.n4.nabble.com/Skein-and-Threefish-for-Bouncy-Ca
stle-td3169174.html
[2]
https://github.com/search?p=4&q=BigIntegerCrypto+%40wernerd+extension%3Ajava
&ref=searchresults&type=Code

--
----------------------------------------------
Werner Dittmann Werner.Dittmann@t-online.de
Tel +49 173 44 37 659
PGP key: 82EF5E8B


#5

I believe that bouncycastle was modified for size concerns only, so we
may just work with the original version now changes. Werner, Ingo,
please correct me if I am wrong.

yes, that was the main motivation when I created the smaller lib. The size
of the normal BC lib (1.48) is ~2.2MB whereas the reduced lib is < 200KB,
thus a factor of 10. AFAIK the lib is packaged together with Jitsi and

thus

contributes to the overall size of the Jitsi package. Will this be changed
for Debian?

The Debian-package is going to have a dependency on some libbc*-java
packages, so it's not directly Jitsi's size that increases, but yes for the
overall installation.

Yes and no: - SDES uses standard crypto stuff only - The certificate
stuff would be fine with regular BC too - SRTP and ZRTP include code
for the Skein and Threefish algorithms, both are not included in the
standard BC lib. Werner wanted to contribute them years ago, but it
apparently never made it [1]. Given that the NIST now has chosen Keccak
over Skein for SHA3, I don't really see the point of including it (but
the ZRTP RFC suggests to support it). There's however no reason this
has to be inside a modified BC library.

Actually we have two extensions:
- Skein/Threefish as a additional Hash algorithm
- Fortuna random number generator

Both extensions use some BC base class to be compliant to the standard BC
look-and-feel.

Are these base classes package protected? If not, couldn't we just create a
small jar, like "bc-contrib"?

[...]

Removing the Fortuna would be more critical. I may be able to move it
into the ZRTP lib without to many modifications (need to check this).

Fortuna is critical (also for performance reasons on some systems), but I'd
prefer it also in some bc-contrib instead of zrtp4j.

Then there was also something about a "BigInteger better suited for
crypto". All I could find [2] is that this thing lives inside ZRTP4j,
so it should not be an issue for using the regular BC.

Some background on this: the standard Java BigInteger class is
non-mutable, similar to Java String. Thus you cannot clear the contents
of a BigInteger object even if you don't use it anymore. But most
important is the fact that we cannot clear the data after we computed
the results, for example DH results. To make it more clear: with
standard BigInteger the DH results would stay for some time on the Java
heap until some GC mechanism decides to reuse the memory. This opens a
window to snoop and analyze memory and thus one could recover the DH
results which breaks security. I did some modifications on the GNU
(Classpath) BigInteger class to provide at least the "clear data"
function. Thus this class performs some "clear data" internally and has
a method that the ZRTP classes use to clear the DH results and keys
before it releases the BigInteger objects.

Hmm. You're right in the general observation and it is indeed a good idea to
do so. However, as long as the BigInteger isn't gc-pinned to a fixed
memory-location BEFORE it is initialized, it could be moved around in the
memory and thus creating copies that 0-setting wouldn't catch. The operating
system could also move the underlying pages around or do swapping , so that
the thing would be in multiple physical locations. See [1] for more (in
German).
So, while certainly useful, I wouldn't take this as a point to stick with
lcrypto for Debian.

Werner

Ingo

Ingo

[1]
http://www.android-user.de/Apps/Sicheres-Loeschen-von-Passwoertern-aus-dem-H
auptspeicher

···

Am 19.03.2013 10:54, schrieb Ingo Bauersachs:


#6

Hi Werner,

Sorry that I respond somewhat late - the subject line of the e-mails didn't
trigger my attention :slight_smile:

I believe that bouncycastle was modified for size concerns only, so we
may just work with the original version now changes. Werner, Ingo,
please correct me if I am wrong.

yes, that was the main motivation when I created the smaller lib. The size
of the normal BC lib (1.48) is ~2.2MB whereas the reduced lib is < 200KB,
thus a factor of 10. AFAIK the lib is packaged together with Jitsi and thus
contributes to the overall size of the Jitsi package. Will this be changed
for Debian?

We are asking can we use the lib that ships with debian instead the
one that we currently package in Jitsi. And yes the libraries which
are already available in debian we need to use them, as it is one of
the requirements we need to follow to include the package in the
official repository.

Yes and no:
- SDES uses standard crypto stuff only
- The certificate stuff would be fine with regular BC too
- SRTP and ZRTP include code for the Skein and Threefish algorithms, both
are not included in the standard BC lib. Werner wanted to contribute them
years ago, but it apparently never made it [1]. Given that the NIST now has
chosen Keccak over Skein for SHA3, I don't really see the point of including
it (but the ZRTP RFC suggests to support it). There's however no reason this
has to be inside a modified BC library.

Actually we have two extensions:
- Skein/Threefish as a additional Hash algorithm
- Fortuna random number generator

Both extensions use some BC base class to be compliant to the standard BC
look-and-feel. Some remarks about these extensions:
  As Ingo pointed out above Skein was proposed by RFC6189 and thus implemented.
Also Skein is faster than the standard SHA256/SHA384 based MAC. Nevertheless
we could even remove Skein and are still ZRTP compatible.
  More important is the random number generator. The Diffie-Helman algorithms
(both normal and ECC) and AFAIK also SDES require some very good random number
generator. The current BC PRNG implementations are not considered as
cryptographically strong random generators. The standard Java Random implementation
falls into the same class (only 48-bit seed). Fortuna is a much better generator
and we seed it with a lot of random data that we gather from the microphone during
start up of Jitsi.

Removing the Fortuna would be more critical. I may be able to move it into the
ZRTP lib without to many modifications (need to check this).

Then there was also something about a "BigInteger better suited for crypto".
All I could find [2] is that this thing lives inside ZRTP4j, so it should
not be an issue for using the regular BC.

Some background on this: the standard Java BigInteger class is non-mutable, similar
to Java String. Thus you cannot clear the contents of a BigInteger object even if
you don't use it anymore.
But most important is the fact that we cannot clear the data after we computed the
results, for example DH results. To make it more clear: with standard BigInteger
the DH results would stay for some time on the Java heap until some GC mechanism
decides to reuse the memory. This opens a window to snoop and analyze memory and
thus one could recover the DH results which breaks security. I did some modifications
on the GNU (Classpath) BigInteger class to provide at least the "clear data" function.
Thus this class performs some "clear data" internally and has a method that the ZRTP
classes use to clear the DH results and keys before it releases the BigInteger objects.

Werner

So as I understand, we can use the original bouncy-castle and zrtp
will work, except that the random generator will not so good as the
currently used one, and also there will be some security memory
problem which you mention with BigInteger and not clearing data,
right?

Regards
damencho

···

On Mon, Mar 25, 2013 at 9:39 AM, Werner Dittmann <Werner.Dittmann@t-online.de> wrote:

Am 19.03.2013 10:54, schrieb Ingo Bauersachs:

Ingo

[1]
http://bouncy-castle.1462172.n4.nabble.com/Skein-and-Threefish-for-Bouncy-Ca
stle-td3169174.html
[2]
https://github.com/search?p=4&q=BigIntegerCrypto+%40wernerd+extension%3Ajava
&ref=searchresults&type=Code

--
----------------------------------------------
Werner Dittmann Werner.Dittmann@t-online.de
Tel +49 173 44 37 659
PGP key: 82EF5E8B


#7

Hi Werner,

...

We are asking can we use the lib that ships with debian instead the
one that we currently package in Jitsi. And yes the libraries which
are already available in debian we need to use them, as it is one of
the requirements we need to follow to include the package in the
official repository.

Wouldn't this require some modification during Jitsi packet creation? Just
because I'm curious :slight_smile:

...

Some background on this: the standard Java BigInteger class is non-mutable, similar
to Java String. Thus you cannot clear the contents of a BigInteger object even if
you don't use it anymore.
But most important is the fact that we cannot clear the data after we computed the
results, for example DH results. To make it more clear: with standard BigInteger
the DH results would stay for some time on the Java heap until some GC mechanism
decides to reuse the memory. This opens a window to snoop and analyze memory and
thus one could recover the DH results which breaks security. I did some modifications
on the GNU (Classpath) BigInteger class to provide at least the "clear data" function.
Thus this class performs some "clear data" internally and has a method that the ZRTP
classes use to clear the DH results and keys before it releases the BigInteger objects.

Werner

So as I understand, we can use the original bouncy-castle and zrtp
will work, except that the random generator will not so good as the
currently used one, and also there will be some security memory
problem which you mention with BigInteger and not clearing data,
right?

The modified BigInteger is part of the ZTRP library and not part of the reduced BC library.
Thus there is no need to remove this modified BigInteger which actually replaces the
standard Java BigInteger for some specific cases. The modified DH and ECC-DH classes that
use these modified stuff are also part of the ZRTP lib (zrtp-light.jar).

Well, removing the random number generator would introduce some additional changes in
some other Jitsi classes because of the initial seeding of the generator. A cryptographically
strong random number generator is of paramount importance for many security/crypto related
code, in particular for Diffie-Helman based key exchanges.

If Debian requests that we remove every class that
- use BC as its base but modifies it (DH and ECC-DH with modified BigInteger)
- enhance the standard BC functionality (Random Generator)
then I would not recommend to follow these requests because this may lead to security related
issues.

Werner

···

Am 25.03.2013 08:56, schrieb Damian Minkov:

Regards
damencho

--
----------------------------------------------
Werner Dittmann Werner.Dittmann@t-online.de
Tel +49 173 44 37 659
PGP key: 82EF5E8B


#8

...

Actually we have two extensions:
- Skein/Threefish as a additional Hash algorithm
- Fortuna random number generator

Both extensions use some BC base class to be compliant to the standard BC
look-and-feel.

Are these base classes package protected? If not, couldn't we just create a
small jar, like "bc-contrib"?

Had a similar idea, just need to check how it works out.

[...]

Removing the Fortuna would be more critical. I may be able to move it
into the ZRTP lib without to many modifications (need to check this).

Fortuna is critical (also for performance reasons on some systems), but I'd
prefer it also in some bc-contrib instead of zrtp4j.

Hmm. You're right in the general observation and it is indeed a good idea to
do so. However, as long as the BigInteger isn't gc-pinned to a fixed
memory-location BEFORE it is initialized, it could be moved around in the
memory and thus creating copies that 0-setting wouldn't catch. The operating
system could also move the underlying pages around or do swapping , so that
the thing would be in multiple physical locations. See [1] for more (in
German).
So, while certainly useful, I wouldn't take this as a point to stick with
lcrypto for Debian.

These modified BigInteger and the DH and ECC-DH that use it are not part of lcrypto
but of zrtp-light.jar. It's sort of a "poor-man's" solution to make it at least a little
bit harder for the bad guys :slight_smile: .

Thanks for the link which proves some decisions made for another project. I participated
in the development of an Android VoIP client and this client uses the C++ based ZRTP
implementation via some JNI wrappers. Thus I have much more and better control about the data.
And its really faster than the Java based implementation, in particular for the DH algorithms.

Werner

···

Am 25.03.2013 09:03, schrieb Ingo Bauersachs:

Werner

Ingo

Ingo

[1]
http://www.android-user.de/Apps/Sicheres-Loeschen-von-Passwoertern-aus-dem-H
auptspeicher

--
----------------------------------------------
Werner Dittmann Werner.Dittmann@t-online.de
Tel +49 173 44 37 659
PGP key: 82EF5E8B


#9

Hi again,

Hi Werner,

...

We are asking can we use the lib that ships with debian instead the
one that we currently package in Jitsi. And yes the libraries which
are already available in debian we need to use them, as it is one of
the requirements we need to follow to include the package in the
official repository.

Wouldn't this require some modification during Jitsi packet creation? Just
because I'm curious :slight_smile:

Yes we already put a great effort on it, and we are close to the
finish :slight_smile: There is ant target which creates the debian source package
and uses libsrc to include some sources, then the deb package is build
using these sources by depending the libs provided by other debian
packages and for java there are normally placed in /usr/share/java/...

...

Some background on this: the standard Java BigInteger class is non-mutable, similar
to Java String. Thus you cannot clear the contents of a BigInteger object even if
you don't use it anymore.
But most important is the fact that we cannot clear the data after we computed the
results, for example DH results. To make it more clear: with standard BigInteger
the DH results would stay for some time on the Java heap until some GC mechanism
decides to reuse the memory. This opens a window to snoop and analyze memory and
thus one could recover the DH results which breaks security. I did some modifications
on the GNU (Classpath) BigInteger class to provide at least the "clear data" function.
Thus this class performs some "clear data" internally and has a method that the ZRTP
classes use to clear the DH results and keys before it releases the BigInteger objects.

Werner

So as I understand, we can use the original bouncy-castle and zrtp
will work, except that the random generator will not so good as the
currently used one, and also there will be some security memory
problem which you mention with BigInteger and not clearing data,
right?

The modified BigInteger is part of the ZTRP library and not part of the reduced BC library.
Thus there is no need to remove this modified BigInteger which actually replaces the
standard Java BigInteger for some specific cases. The modified DH and ECC-DH classes that
use these modified stuff are also part of the ZRTP lib (zrtp-light.jar).

Well, removing the random number generator would introduce some additional changes in
some other Jitsi classes because of the initial seeding of the generator. A cryptographically
strong random number generator is of paramount importance for many security/crypto related
code, in particular for Diffie-Helman based key exchanges.

If Debian requests that we remove every class that
- use BC as its base but modifies it (DH and ECC-DH with modified BigInteger)
- enhance the standard BC functionality (Random Generator)
then I would not recommend to follow these requests because this may lead to security related
issues.

No, we just need to use the lib provided by Debian from
/usr/share/java and skip the one we have
lib/installer-exclude/lcrypto-jdk16-143.jar. Extending and enhancing
the standard BC functionality from within Jitsi or its libs is ok.
Debian guys just want to minimize duplicate libraries distribution.

Regards
damencho

···

On Mon, Mar 25, 2013 at 10:28 AM, Werner Dittmann <Werner.Dittmann@t-online.de> wrote:

Am 25.03.2013 08:56, schrieb Damian Minkov:

Werner

Regards
damencho

--
----------------------------------------------
Werner Dittmann Werner.Dittmann@t-online.de
Tel +49 173 44 37 659
PGP key: 82EF5E8B


#10

Yes we already put a great effort on it, and we are close to the
finish :slight_smile: There is ant target which creates the debian source package
and uses libsrc to include some sources, then the deb package is build
using these sources by depending the libs provided by other debian
packages and for java there are normally placed in /usr/share/java/...

Speaking of libsrc: Werner, did you update the zrtp source jar? I haven't
seen it in the r10639 commit.

Ingo


#11

...

These modified BigInteger and the DH and ECC-DH that use it are not part
of lcrypto but of zrtp-light.jar. It's sort of a "poor-man's" solution
to make it at least a little bit harder for the bad guys :slight_smile: .

So when your BigInteger is only in zrtp, it's actually a non-issue. This
leaves us with moving Skein/Threefish/Fortuna from lcrypto into something of
its own. Right?

Ingo


#12

Yes we already put a great effort on it, and we are close to the
finish :slight_smile: There is ant target which creates the debian source package
and uses libsrc to include some sources, then the deb package is build
using these sources by depending the libs provided by other debian
packages and for java there are normally placed in /usr/share/java/...

Speaking of libsrc: Werner, did you update the zrtp source jar? I haven't
seen it in the r10639 commit.

Ahh - forgot to check this. Will do it later today.

Werner

···

Am 25.03.2013 10:07, schrieb Ingo Bauersachs:

Ingo

--
----------------------------------------------
Werner Dittmann Werner.Dittmann@t-online.de
Tel +49 173 44 37 659
PGP key: 82EF5E8B


#13

...

These modified BigInteger and the DH and ECC-DH that use it are not part
of lcrypto but of zrtp-light.jar. It's sort of a "poor-man's" solution
to make it at least a little bit harder for the bad guys :slight_smile: .

So when your BigInteger is only in zrtp, it's actually a non-issue. This
leaves us with moving Skein/Threefish/Fortuna from lcrypto into something of
its own. Right?

Yes. I'll check this later today when my dev system is up and running again.

Werner

···

Am 25.03.2013 10:10, schrieb Ingo Bauersachs:

Ingo

--
----------------------------------------------
Werner Dittmann Werner.Dittmann@t-online.de
Tel +49 173 44 37 659
PGP key: 82EF5E8B


#14

Hi guys,

I am a bit late on this topic, but I wanted to say this: please don't
package jitsi in debian without fortuna.
Of course, being able to apt-get install jitsi is great. However, without
good crypto, it's not that useful (and potentially detrimental?).

But that's just my 2c, of course.

Jean

···

On Mon, Mar 25, 2013 at 6:28 PM, Werner Dittmann < Werner.Dittmann@t-online.de> wrote:

Am 25.03.2013 10:10, schrieb Ingo Bauersachs:
> ...
>> These modified BigInteger and the DH and ECC-DH that use it are not part
>> of lcrypto but of zrtp-light.jar. It's sort of a "poor-man's" solution
>> to make it at least a little bit harder for the bad guys :slight_smile: .
>
> So when your BigInteger is only in zrtp, it's actually a non-issue. This
> leaves us with moving Skein/Threefish/Fortuna from lcrypto into
something of
> its own. Right?

Yes. I'll check this later today when my dev system is up and running
again.

Werner

>
> Ingo
>
>

--
----------------------------------------------
Werner Dittmann Werner.Dittmann@t-online.de
Tel +49 173 44 37 659
PGP key: 82EF5E8B


#15

Hey guys,

It seems like the bouncy castle fork is now officially the last and only
show stopper for Jitsi's acceptance in Debian.

Youhouu! Almost there! :slight_smile:

Werner, do you think you'd be able to have a look at this and move the
changes outside of lcrypto in the following weeks?

Cheers,
Emil

···

On 25.03.13, 10:28, Werner Dittmann wrote:

Am 25.03.2013 10:10, schrieb Ingo Bauersachs:

...

These modified BigInteger and the DH and ECC-DH that use it are not part
of lcrypto but of zrtp-light.jar. It's sort of a "poor-man's" solution
to make it at least a little bit harder for the bad guys :slight_smile: .

So when your BigInteger is only in zrtp, it's actually a non-issue. This
leaves us with moving Skein/Threefish/Fortuna from lcrypto into something of
its own. Right?

Yes. I'll check this later today when my dev system is up and running again.

Werner

Ingo

--
https://jitsi.org


#16

Hey

So, I stripped the lcrypto apart:
- libjitsi basically needs just new libraries (see libjitsi.patch for the
classpath changes)
- Jitsi needs a little tweak in the certificate service, updates in the
build process and manifest mangling (-> jitsi.patch)

With these changes, Jitsi uses the vanilla Bouncycastle
(bcprov-jdk15on-148.jar), and BCContrib (bccontrib-1.0-SNAPSHOT.jar) which
contains the classes that were in lcrypto (Skein/Threefish/Fortuna).

BCContrib:
- Source: https://github.com/ibauersachs/bccontrib
- Create eclipse project: mvn eclipse:eclipse
- Create .jar: mvn package (take target/bccontrib-1.0-SNAPSHOT.jar)

ZRTP4J that uses BCContrib:
- Source: https://github.com/ibauersachs/ZRTP4J
- Crate .jar: ant jar (take dist/zrtp4j-light.jar)

Now Werner, I guess you don't particularly like the org.jitsi.bccontrib.*
namespace I chose inside ZRTP4J. Any suggestions on how we avoid forking
ZRTP4J?

Regards,
Ingo

From: Emil Ivov [mailto:emcho@jitsi.org]
Sent: Sonntag, 7. April 2013 17:20
To: dev@jitsi.java.net
Cc: Werner Dittmann; Raphaël Hertzog
Subject: [jitsi-dev] Un-forking Bouncycastle (Was: Comment posted on

jitsi)

Hey guys,

It seems like the bouncy castle fork is now officially the last and only
show stopper for Jitsi's acceptance in Debian.

Youhouu! Almost there! :slight_smile:

Werner, do you think you'd be able to have a look at this and move the
changes outside of lcrypto in the following weeks?

Cheers,
Emil

...

These modified BigInteger and the DH and ECC-DH that use it are not

part

libjitsi.patch (1017 Bytes)

jitsi.patch (8.56 KB)

···

-----Original Message-----
On 25.03.13, 10:28, Werner Dittmann wrote:

Am 25.03.2013 10:10, schrieb Ingo Bauersachs:

of lcrypto but of zrtp-light.jar. It's sort of a "poor-man's" solution
to make it at least a little bit harder for the bad guys :slight_smile: .

So when your BigInteger is only in zrtp, it's actually a non-issue.
This leaves us with moving Skein/Threefish/Fortuna from lcrypto into
something of its own. Right?

Yes. I'll check this later today when my dev system is up and running
again.

Werner

Ingo


#17

I believe we need update the source package we last sent and poke the
Debian guys through their tracker. Damencho could you please confirm?

Is there anything else?

Emil

···

On 26.05.13, 14:41, Ingo Bauersachs wrote:

Hey

What's the current state here?
BouncyCastle is unforked for a while now and the missing license headers in
bccontrib are applied. Is there anything else left to clean up?

Ingo

-----Original Message-----
From: Emil Ivov [mailto:emcho@jitsi.org]
Sent: Sonntag, 7. April 2013 17:20
To: dev@jitsi.java.net
Cc: Werner Dittmann; Raphaël Hertzog
Subject: [jitsi-dev] Un-forking Bouncycastle (Was: Comment posted on

jitsi)

Hey guys,

It seems like the bouncy castle fork is now officially the last and only
show stopper for Jitsi's acceptance in Debian.

Youhouu! Almost there! :slight_smile:

Werner, do you think you'd be able to have a look at this and move the
changes outside of lcrypto in the following weeks?

Cheers,
Emil

On 25.03.13, 10:28, Werner Dittmann wrote:

Am 25.03.2013 10:10, schrieb Ingo Bauersachs:

...

These modified BigInteger and the DH and ECC-DH that use it are not

part

of lcrypto but of zrtp-light.jar. It's sort of a "poor-man's" solution
to make it at least a little bit harder for the bad guys :slight_smile: .

So when your BigInteger is only in zrtp, it's actually a non-issue.
This leaves us with moving Skein/Threefish/Fortuna from lcrypto into
something of its own. Right?

Yes. I'll check this later today when my dev system is up and running
again.

Werner

Ingo

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

--
https://jitsi.org


#18

Thnaks Ingo - now I need to revert my changes :slight_smile: .

Acutally no problem with the namespace. When I did the changes I stayed
with the BC namespace to because that required less changes and shows
that we use the BC style API. Otherwise the same changes more or less.

If you like you may add a push/pull request to my ZRTP4PJ Github repo
and I can take over the changes.

Werner

···

Am 07.04.2013 19:30, schrieb Ingo Bauersachs:

Hey

So, I stripped the lcrypto apart:
- libjitsi basically needs just new libraries (see libjitsi.patch for the
classpath changes)
- Jitsi needs a little tweak in the certificate service, updates in the
build process and manifest mangling (-> jitsi.patch)

With these changes, Jitsi uses the vanilla Bouncycastle
(bcprov-jdk15on-148.jar), and BCContrib (bccontrib-1.0-SNAPSHOT.jar) which
contains the classes that were in lcrypto (Skein/Threefish/Fortuna).

BCContrib:
- Source: https://github.com/ibauersachs/bccontrib
- Create eclipse project: mvn eclipse:eclipse
- Create .jar: mvn package (take target/bccontrib-1.0-SNAPSHOT.jar)

ZRTP4J that uses BCContrib:
- Source: https://github.com/ibauersachs/ZRTP4J
- Crate .jar: ant jar (take dist/zrtp4j-light.jar)

Now Werner, I guess you don't particularly like the org.jitsi.bccontrib.*
namespace I chose inside ZRTP4J. Any suggestions on how we avoid forking
ZRTP4J?

Regards,
Ingo

-----Original Message-----
From: Emil Ivov [mailto:emcho@jitsi.org]
Sent: Sonntag, 7. April 2013 17:20
To: dev@jitsi.java.net
Cc: Werner Dittmann; Rapha�l Hertzog
Subject: [jitsi-dev] Un-forking Bouncycastle (Was: Comment posted on

jitsi)

Hey guys,

It seems like the bouncy castle fork is now officially the last and only
show stopper for Jitsi's acceptance in Debian.

Youhouu! Almost there! :slight_smile:

Werner, do you think you'd be able to have a look at this and move the
changes outside of lcrypto in the following weeks?

Cheers,
Emil

On 25.03.13, 10:28, Werner Dittmann wrote:

Am 25.03.2013 10:10, schrieb Ingo Bauersachs:

...

These modified BigInteger and the DH and ECC-DH that use it are not

part

of lcrypto but of zrtp-light.jar. It's sort of a "poor-man's" solution
to make it at least a little bit harder for the bad guys :slight_smile: .

So when your BigInteger is only in zrtp, it's actually a non-issue.
This leaves us with moving Skein/Threefish/Fortuna from lcrypto into
something of its own. Right?

Yes. I'll check this later today when my dev system is up and running
again.

Werner

Ingo

--
----------------------------------------------
Werner Dittmann Werner.Dittmann@t-online.de
Tel +49 173 44 37 659
PGP key: 82EF5E8B


#19

Ingo,

I tried to apply the patches but they failed after I did a svn up. Patch says
something about wrong line-ending. I saw that the file CertificateServiceImpl.java
has CR-LF (DOS) line-endings which seems strange.

Even after I completely reset to the non-patached state the the compiler complains
about an unrsolved reference at an ASN1Object.fromByteArray, line 830 (this is the
non-patched file). Any idea?

Werner

···

Am 07.04.2013 19:30, schrieb Ingo Bauersachs:

Hey

So, I stripped the lcrypto apart:
- libjitsi basically needs just new libraries (see libjitsi.patch for the
classpath changes)
- Jitsi needs a little tweak in the certificate service, updates in the
build process and manifest mangling (-> jitsi.patch)

With these changes, Jitsi uses the vanilla Bouncycastle
(bcprov-jdk15on-148.jar), and BCContrib (bccontrib-1.0-SNAPSHOT.jar) which
contains the classes that were in lcrypto (Skein/Threefish/Fortuna).

BCContrib:
- Source: https://github.com/ibauersachs/bccontrib
- Create eclipse project: mvn eclipse:eclipse
- Create .jar: mvn package (take target/bccontrib-1.0-SNAPSHOT.jar)

ZRTP4J that uses BCContrib:
- Source: https://github.com/ibauersachs/ZRTP4J
- Crate .jar: ant jar (take dist/zrtp4j-light.jar)

Now Werner, I guess you don't particularly like the org.jitsi.bccontrib.*
namespace I chose inside ZRTP4J. Any suggestions on how we avoid forking
ZRTP4J?

Regards,
Ingo

-----Original Message-----
From: Emil Ivov [mailto:emcho@jitsi.org]
Sent: Sonntag, 7. April 2013 17:20
To: dev@jitsi.java.net
Cc: Werner Dittmann; Rapha�l Hertzog
Subject: [jitsi-dev] Un-forking Bouncycastle (Was: Comment posted on

jitsi)

Hey guys,

It seems like the bouncy castle fork is now officially the last and only
show stopper for Jitsi's acceptance in Debian.

Youhouu! Almost there! :slight_smile:

Werner, do you think you'd be able to have a look at this and move the
changes outside of lcrypto in the following weeks?

Cheers,
Emil

On 25.03.13, 10:28, Werner Dittmann wrote:

Am 25.03.2013 10:10, schrieb Ingo Bauersachs:

...

These modified BigInteger and the DH and ECC-DH that use it are not

part

of lcrypto but of zrtp-light.jar. It's sort of a "poor-man's" solution
to make it at least a little bit harder for the bad guys :slight_smile: .

So when your BigInteger is only in zrtp, it's actually a non-issue.
This leaves us with moving Skein/Threefish/Fortuna from lcrypto into
something of its own. Right?

Yes. I'll check this later today when my dev system is up and running
again.

Werner

Ingo

--
----------------------------------------------
Werner Dittmann Werner.Dittmann@t-online.de
Tel +49 173 44 37 659
PGP key: 82EF5E8B


#20

Hi,

yes, only updating the debian source package left.

Regards
damencho

···

On Sun, May 26, 2013 at 2:45 PM, Emil Ivov <emcho@jitsi.org> wrote:

I believe we need update the source package we last sent and poke the
Debian guys through their tracker. Damencho could you please confirm?

Is there anything else?

Emil

On 26.05.13, 14:41, Ingo Bauersachs wrote:

Hey

What's the current state here?
BouncyCastle is unforked for a while now and the missing license headers in
bccontrib are applied. Is there anything else left to clean up?

Ingo

-----Original Message-----
From: Emil Ivov [mailto:emcho@jitsi.org]
Sent: Sonntag, 7. April 2013 17:20
To: dev@jitsi.java.net
Cc: Werner Dittmann; Raphaël Hertzog
Subject: [jitsi-dev] Un-forking Bouncycastle (Was: Comment posted on

jitsi)

Hey guys,

It seems like the bouncy castle fork is now officially the last and only
show stopper for Jitsi's acceptance in Debian.

Youhouu! Almost there! :slight_smile:

Werner, do you think you'd be able to have a look at this and move the
changes outside of lcrypto in the following weeks?

Cheers,
Emil

On 25.03.13, 10:28, Werner Dittmann wrote:

Am 25.03.2013 10:10, schrieb Ingo Bauersachs:

...

These modified BigInteger and the DH and ECC-DH that use it are not

part

of lcrypto but of zrtp-light.jar. It's sort of a "poor-man's" solution
to make it at least a little bit harder for the bad guys :slight_smile: .

So when your BigInteger is only in zrtp, it's actually a non-issue.
This leaves us with moving Skein/Threefish/Fortuna from lcrypto into
something of its own. Right?

Yes. I'll check this later today when my dev system is up and running
again.

Werner

Ingo

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

--
https://jitsi.org

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev