Slashdot Mirror

This isn't a good omen for The Legion of The Bouncy Castle..

The name is a bit crazy but its easy enough to use. http://www.bouncycastle.org/java.html

"Bouncy Castle?"

But, seriously, all this tells me is that open source geeks use open source. Duh.

OK, that's three. We've only got 197 to go. If the point of this exercise is trying to determine how many applications are being used, then from that perspective they're all instances of Firefox.

Your approach answers one particular question, how many different versions of how many different applications are we using? That obviously matters in some cases like license management, but if the question is more along the lines of "how many open-sourced applications are we running," then I don't think versioning is all that relevant.

I'm not trying to argue about what's "fair," I'm just wondering how we get to 200. Let's suppose that your company has three or four different versions of every open-sourced application running. That still works out to something like 50-70 different applications which seems to me to be pretty high number. Particularly when most anecdotal evidence suggests that open-sourced applications are a rarity in many companies. It's taken me quite a while to convince my (small business/nonprofit) clients to adopt one or two of the most commonly-used open-sourced applications like Firefox, Thunderbird, and OpenOffice.

The only way I see getting to a number like 200 is if you count *nix servers. And, then, 200 is probably too small a number especially in Linux shops.

BTW, their list of discoverable software (XLS) doesn't include any versions of Firefox before 2.0.0 and doesn't list Thunderbird at all. On the other hand, they do list a number of different versions of server software like Apache (8 versions) and MySQL (17). This tends to confirm my original conjecture that a lot of the software counted toward this 200 figure is running on servers, and yes, they're probably counting different versions as different instances. There are also a lot of packages that are likely to be relevant only to development shops. Just going through the A's and B's required me to look up some things like activemq (about 80 versions), berkano (about 100 versions), and bouncycastle (about a dozen).

So I guess I'd conclude that this product might be highly relevant to development shops and server managers, but much less relevant for determining what's running on the desktops of firms outside the IT industry.

Rich Sands, community marketing manager for OpenJDK community at Sun, would not say what percentage of Java's 6.5 million lines of code are encumbered, but explained that it is largely Java 2D graphics technology, such as font and graphics rasterizing.

I'm guessing some of the product's will get cut off. Going out on a limb here, but I'm guessing Most of the Keon family will get cut off, at least the toolkits with openssl and boncycastle as options for customers.
The big question is if the CA too will be cut-off... there is lots of viable options here too Ejbca for example <shameless plug>There is commercial support available</shameless plug>.

Scott Silver, one of the first EF developers, originally wanted to codename the project "Sexual Chocolate". (I'm not making this up.) That name was rejected, presumably because it would confuse Netscape's managers: "So, this Sexual Chocolate project actually has nothing to do with chocolate ?" Instead, Silver proposed "Electrical Fire" (two separate words). For the open-source release, Scott Furman coalesced the two words into one: "ElectricalFire", to make it apparent that the project was not to be confused with a safety hazard. A word of advice for the wise: if you end up working on a project with Scott Silver, do not allow him to handle the project codename.

Some opensource projects require that they be signed - one that comes to mind is the BouncyCastle Crypto API for Java - its got a BSD-style licence, but in order to use it in a JVM without hassle, then the .jar has to be signed with a key that has gone through some sort of process with Sun.

There's nothing stopping you from going through this process yourself, but it's apparently painful and long-winded.

BouncyCastle have done this, thus making it easy for the rest of us.

Perhaps the poster could ask them what they do?

I've had problems with Bouncy Castle, yes, and again it was simpler to extract the classes I needed from the Bouncy Castle library and include them directly. I'd do that. I don't remember what it was exactly, but it was easier to just package what I needed directly with the app.

For those who are confused: Bouncy Castle refers to an open source Java cryptography library developed by the Legion of the Bouncy Castle. (Dumb name, but good code. Better than the reverse!)

I looked around - if you're looking for open source JCE and related code (like ASN.1 IO), try http://www.bouncycastle.org/

There are more than a few out there already (not surprisingly!):

RSA Crypto-J

BouncyCastle

Cryptix

Flexiprovider

There's a bunch more too - just google for them.

Some of these are free, some are Free and some are neither. Personally, I've written banking software using the RSA libs (I tried to get use BouncyCastle but management didn't like the name!).

Bouncycastle Crypto APIs support atleast Elliptic Curve DSA and Elliptic Curve basic Diffie-Hellman (according to release notes). Possible other ECC algorithms too.

They should use Bouncy Castle instead. I'm pretty sure it has all the cryptographic tools they could need. Good stuff and pure java.

I was under the impression that the BouncyCastle license was less than free, but I was mistaken. It is a great package, and it's good to know that there are a variety of open implementations of strong crypto under Java.

Cryptix is quite late with JCE compatibility.

When I saw it, I nearly had a heart attack, I write freely available Java crypto BouncyCastle.org and thought of the horrible problems that we're going to have keeping SAf off the site.

I spent the 2 seconds actually reading the paragraph at the SAf Gov Site and it says:

All Cryptography Providers providing services or products in South Africa are required to register their services or products with the register maintained by the Department of Communications.

Note, the wording is in.

There are lots of free-and-ready-to-reuse java libraries for almost everything but the difference is that you have to do the search. For MD5 you probably should the standard crypto api from Sun and the open source implementation from BouncyCastle. In any case Java comes with lots of api that you should investigate.

The AES has selected the variable key lengths of 128, 192, 256 to be used with a 128 bit block

BouncyCastle has had a full implementation of Rijndael since 1.0 beta 4 (now at 1.10)

Disclaimer: I'm a BouncyCastle author.

Build your own certs that import into IE and Netscape easily..

The best JCE on the planet..

BouncyCastle

The choice for what algorithm to use depends on a number of factors%2C and in my experience, it certainly helps to understand where it is going to be deployed (in hardware, small device like a Palm or a general purpose computer) and what is going to be protected (passwords, documents, streaming media).

As a great example, Blowfish is a mighty fine algorithm, but the key schedule setup takes the equivalent time of encrypting about 5k of data. If you're going to be encrypting lots of small things with different keys then Blowfish probably isn't all that suitable. Blowfish's key schedule arrays are quite large, so in devices with limited memory (like the Palm) it isn't suitable.

Twofish on the other hand has been designed to overcome a number of those limitations (pretty much because of the AES requirements).

So, understand what problems the alrithms were designed to solve, and find one that matches yours.

As has been stated many times, encrypting the data is only one link in the chain. If your key generation or exchange is weak, then you may as well not bother encrypting at all.