Java Reference
In-Depth Information
Ciphers can differ in how they handle their input; some, like DES, are
block
ciphers
, which require the input to come in regularly sized blocks, such as blocks of
64 bytes. When using block ciphers, you must pad the input to block aligned bound-
aries; complicating this, some block ciphers are asymmetric, meaning that the input
block size and output block size are different. Other ciphers, like RC4, are stream
ciphers: they just take a stream of bytes (plaintext or encrypted text) and work their
magic. When using a block cipher, be sure you pass whole blocks to the
update
and
doFinal
methods.
A number of things can happen when encrypting or decrypting using the
Cipher
interface; these are signaled using one of the following exceptions:
• The API throws
BadPaddingException
or
IllegalBlockSizeException
for block ciphers
when the input is not padded correctly or occurs in the wrong-sized block.
• The API throws
InvalidKeyException
when an invalid key is used with a cipher.
• The API throws
IllegalStateException
when you attempt to use the cipher to
encrypt or decrypt a message before initializing it.
• The API throws
NoSuchAlgorithmException
if you attempt to get an instance of
Cipher
for an algorithm that is not supported.
■
Caution
In the real world, you shouldn't be so cavalier with a cipher's private key as to embed it in
source code or another easily read resource such as a component of your JAR file. Malicious users could
find the key by decompiling your application or JAR. Instead, you could create the secret key at distribution
time using a different key for each application, and only distribute the application JAD using secure HTTP.
However, this would mean that your application couldn't be signed and verified by participants of the Java
Verified Program. You could also provide a web service that provides secure key generation and delivery over
HTTPS to your application.
Exploring the Bouncy Castle Solution
to Security Challenges
While optional solutions like SATSA can solve problems for many devices, relying on an
optional solution doesn't fulfill the write-once, run-anywhere promise that Java holds.
Fortunately, there's a solution that runs on Java ME: the Bouncy Castle Java cryptogra-
phy API. Developed in Australia and available under a liberal open source license, the
API provides clean-room implementations of a provider for JCE and JCA for Java SE,
