JDK Tutorials - Herong's Tutorial Notes
Dr. Herong Yang, Version 4.32, 2006

JCA - Message Digest

Part:   1  2  

JDK Tutorials - Herong's Tutorial Notes © Dr. Herong Yang

Internationalization

Character Set and Encoding

Socket Communication

Document Object Model (DOM)

XSD Validation in Java

XSL - Transformer in Java

JCA - Private and Public Key Pairs

JCE - Secret Key

SSL (Secure Socket Layer)

SSL - Client Authentication

... Table of Contents

(Continued from previous part...)

Here is the result of my first test. It is done with JDK 1.3.1.

javac -classpath . JcaMessageDigest.java

java -cp . JcaMessageDigest JcaMessageDigest.class digest.sha SHA
MessageDigest Object Info:
Algorithm = SHA
Provider = SUN version 1.2
Digest Length = 20
toString = SHA Message Digest from SUN, <initialized>

Message Digest Processing Info:
Number of input bytes = 2060
Number of output bytes = 20

dir *.class *.sha
07:00p   2,060 JcaMessageDigest.class
07:02p      20 digest.sha

The program seems to be working:

  • Since I am not specifying the provider name, the implementation of the SHA algorithm provided in the default security package was selected. Of course, Sun is the provider of the default security package.
  • The digest length is 20 bytes for the default implementation of the SHA algorithm.
  • The program reads the input file, JcaMessageDigest.class, into a byte array buffer, then passes the buffer to the message digest object to process by calling the update(). When the entire input file is processed, digest() method is called to ouptput the digest data.
  • The number of bytes reported by the program matches well with the file sizes.

In order to see the digest data, I need to use my other program, HexWriter.java, to convert binary data to hex numbers. See chapter "Encoding Conversion" for details.

Here is how to look at the digest data in hex numbers, 16 bytes per line:

javac HexWriter.java

java -cp . HexWriter digest.sha digest_sha.hex

type digest_sha.hex
9E6BA180ED152D8F58A4C9F33161DE2A
4F9B304A

My second test is to see the digest data of the same input data, JcaMessageDigest.class, using MD5 algorithm:

java -cp . JcaMessageDigest JcaMessageDigest.class digest.md5 MD5

MessageDigest Object Info:
Algorithm = MD5
Provider = SUN version 1.2
Digest Length = 16
toString = MD5 Message Digest from SUN, <initialized>

Message Digest Processing Info:
Number of input bytes = 2060
Number of output bytes = 16

type digest_md5.hex
CADFA031B79763775D861878062ACA4F

My third test is to see how the digest data changes if I add one byte to the input data:

copy con dot.tmp
.^Z

type dot.tmp >> JcaMessageDigest.class

java -cp . JcaMessageDigest JcaMessageDigest.class digest_1.md5 MD5

MessageDigest Object Info:
Algorithm = MD5
Provider = SUN version 1.2
Digest Length = 16
toString = MD5 Message Digest from SUN, <initialized>

Message Digest Processing Info:
Number of input bytes = 2061
Number of output bytes = 16

java -cp . HexWriter digest_1.md5 digest_1_md5.hex

type digest_1_md5.hex
7772FF57E50B447FE979CAE36C520206

A couple of interesting notes here:

  • The first command is a special trick I learned from DOS system. It allows you to enter data into a file directly from keyboard without using any editor. In the command, "con" is used as a special file name to represent the console, keyboard and monitor. When entering data from keyboard, Control-Z must be used to simulate the end-of-file sign.
  • The second command adds the one-byte file, dot.tmp, to the end of the class file, JcaMessageDigest.class.
  • The third command generates MD5 digest data from the modified class file. The new digest data is very different than old digest data.
  • One surprise is that the modified class file is still working! Why JVM is not checking the class file?

Part:   1  2  

Dr. Herong Yang, updated in 2006
JDK Tutorials - Herong's Tutorial Notes - JCA - Message Digest