Java IO.pdf - Nguyen Dang Binh

Java I/O
• It should be difficult to find two documents that share a hash code. You cannot easily
find two documents with the same hash code, regardless of what that hash code is. The
previous criterion means that you can't change the document to match a hash code.
This criterion says you can't change two documents to match each other.
• Small changes in documents produce large changes in the hash code. Mathematicians
call this criterion "sensitive dependence on initial conditions." Without this
requirement, somebody attempting to create a document with a given hash code could
modify the document a little at a time until the hash code matched, much as you might
adjust the hot and cold water faucets gradually until the water reaches a desired
temperature. A hash function should act more like a faucet that can scald or freeze you
after the tiniest nudge.
• The hash code does not say anything about the document it represents. The one-way
hash function is not even partially invertible. For instance, knowing that the hash code
is even should not suggest that the document being hashed contains an even number of
bytes. Nor should it suggest that the document being hashed is 60% more likely to
contain an even number of bytes than an odd number. While one-way hash functions
need to be reproducible—that is, the same document always has the same hash code—
they should otherwise be completely random. It is extremely hard, perhaps impossible,
to prove that any function meets this criterion. Nonetheless, stronger functions come
closer than weaker functions, and years of experience among cryptographers allow
them to make reasonable guesses about what are and are not strong hash functions,
even if their hunches can't be proved to a mathematical certainty.
The proper design of one-way hash functions is a well-studied field. It's easy to create weak
one-way hash functions. However, it is much harder to create truly strong, reliable, one-way
hash functions. Nonexperts tend to make nonobvious but serious mistakes when
implementing hash functions. Therefore, this is a task that's best left to the experts.
Fortunately, the Java core API contains some hash functions designed by experts that the rest
of us can use without earning a Ph.D. in applied mathematics first.
The hash codes used by the java.util.Hashtable class and returned
by the hashCode() method of any Java object are only intended to be
used as IDs for elements of a hash table, not as cryptographically strong
digest. These sorts of hash codes have different requirements for utility.
Most of the time, they only need to meet the first two of the six criteria
given earlier, and in practice they often don't meet even that. The
hashCode() method is a hash function but not necessarily a one-way
hash function.
10.2 The MessageDigest Class
The java.security.MessageDigest class is an abstract class that represents a hash code
and its associated algorithm. Concrete subclasses (actually concrete subclasses of
java.security.MessageDigestSPI, though the difference isn't relevant from a client's point
of view) implement particular, professionally designed, well-known hash code algorithms.
Thus, rather than constructing instances of this class directly, you ask the static
MessageDigest.getInstance() factory method to provide an implementation of an
algorithm with a particular name. Table 10.1 lists the standard names for message digest
195