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
contributes to the overall size of the Jitsi package. Will this be changed
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
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 . 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
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  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  for more (in
So, while certainly useful, I wouldn't take this as a point to stick with
lcrypto for Debian.
Am 19.03.2013 10:54, schrieb Ingo Bauersachs: