Java Reference
In-Depth Information
The SATSA-CRYPTO API provides the
MessageDigest
class, which provides both a
static factory for creating message-digest algorithm implementations as well as an inter-
face to the message-digest algorithm. You can obtain a concrete instance of
MessageDigest
by invoking its
getInstance
function and passing the name of the digest function (one of
"MD5"
or
"SHA-1"
) whose implementation you want. The resulting
MessageDigest
object
consumes arrays of bytes you pass to it by calling its
update
method, providing the result-
ing message digest and resetting the algorithm when you invoke its
digest
method.
This code opens assuming that you have a web request in hand for which you'd like
to generate an MD5 digest in
webRequest
. Because the
MessageDigest
interface works with
arrays of bytes, the code first gets the representation of the web request as an array of
bytes and then declares variables to contain the resulting digest. With this done, it gets an
instance of the MD5
MessageDigest
implementation and passes it the bytes that make up
the
webRequest
by invoking
md.update
. For a long document, you could invoke this multi-
ple times. Once the
MessageDigest
instance has been fed the message using
update
, the
code asks it to compute the digest using the
digest
method, which takes an array of bytes
to store the output and the number of bytes in the array.
The
MessageDigest
implementation that SATSA-CRYPTO provides typically includes
both the MD5 and SHA-1 algorithms, but there's no guarantee of either being available.
Consequently, your application should be prepared to handle the
NoSuchAlgorithmException
.
You can also use the SATSA-CRYPTO API to verify message digests by creating a
message digest of a source document and comparing it with a provided message digest.
There's no API for comparing message digests; simply loop over the bytes in each digest
and compare individual bytes to determine if the message digests are equivalent.
Encrypting and Decrypting Using the SATSA-CRYPTO API
Under most circumstances, the only time to encrypt data is when it leaves a device for
transmission on the network. In this case, HTTPS is generally sufficient for your data
security needs; occasionally you may find a need to store data locally in an encrypted
form or exchange data using a protocol other than HTTPS. The SATSA-CRYPTO API pro-
vides interfaces for encrypting and decrypting data, with one limitation: while you can
use public-key (also called
asymmetric
) cryptography to encrypt data using the SATSA-
CRYPTO API, you cannot decrypt data encrypted using public-key cryptography.
It's best to think of the SATSA-CRYPTO API for ciphers as an interface and not as a
concrete implementation. For a given target, there's no clear guarantee of
which
cipher
implementations you'll encounter; one device may support Data Encryption Standard
(DES), Rivest Cipher 4 (RC4), and the Encryption Standard (AES), while another might
only support DES. Regardless of what's supported, the general approach to using the
SATSA-CRYPTO cipher interface remains the same:
