Java Cryptography : A Bird’s Eye View

Cryptography in Java has been a topic of interest for quite some time.
Several hurdles had to be crossed before Java cryptography reached the
state of maturity and popularity it enjoys today. In this article we
will look at the origins of Java cryptography, the challenges faced and
where things stands today.

Java Cryptography Challenges

1) Java cryptography had to be made available to all applications,
client-server or Web-based. In other words, the first challenge was to
ensure that regardless of the underlying communication mechanisms (HTTP
or RMI) the same cryptographic APIs should work.

2) The US government had put restrictions on exporting
software including strong cryptography. Strong cryptography generally
meant encrypting plain text with a key of more than 40 bits. Its
counterpart, weak cryptography got its name from the belief that 40-bit
keys could be broken with some amount of work, but anything over 40-bit
keys were tough to crack. This challenge was tougher one to overcome,
since it was not in the scope of Java cryptography designers.

Many western countries, especially the US and NATO allies used to fear
that terrorists could use strong cryptography to encrypt secrets that
could not be understood by the US National Security Agency (NSA).
Therefore, the argument was simple: ban export of strong cryptography!
This was subsequently questioned by several security experts, who
claimed that banning strong cryptography was not the answer to the
problem. Moreover, what one meant by export was not clear. If a person
used strong cryptography to encrypt something in the US and send it out
via an email to another country, would that be considered as export? Or
was carrying a floppy or CD-ROM export? Nobody knew! Consequently,
strong cryptography was allowed.

However, when Java cryptography was born, it was still in the
disallowed state.

Cryptography in Web-based applications

Until Java