Types 

of Hash Functions
Hash algorithms that are in common use today include:

• Message Digest (MD) algorithms: A series of byte-oriented algorithms

that produce a 128-bit hash value from an arbitrary-length message.

- MD2 (RFC 1319): Designed for systems with limited memory, such as
smart cards.

- MD4 (RFC 1320): Developed by Rivest, similar to MD2 but designed

specifically for fast processing in software.

- MD5 (RFC 1321): Also developed by Rivest after potential weaknesses

were reported in MD4; this scheme is similar to MD4 but is slower
because more manipulation is made to the original data. MD5 has been
implemented in a large number of products although several weaknesses
in the algorithm were demonstrated by German cryptographer Hans
Dobbertin in 1996.
 Types of Hash Functions

Secure Hash Algorithm (SHA): Algorithm for NIST's Secure Hash

Standard (SHS). SHA-1 produces a 160-bit hash value

Hash functions are sometimes misunderstood and some sources

claim that no two files can have the same hash value. This is, in fact,
not correct. Consider a hash function that provides a 128-bit hash
value. There are, obviously, 2^128 possible hash values. But there
are a lot more than 2^128 possible files. Therefore, there have to be
multiple files — in fact, there have to be an infinite number of files!
— that can have the same 128-bit hash value.
 Types of Hash Functions
The difficulty is finding two files with the same hash! What is,
indeed, very hard to do is to try to create a file that has a given hash
value so as to force a hash value collision — which is the reason
that hash functions are used extensively for information security and
computer forensics applications. Alas, researchers in 2004 found
that practical collision attacks could be launched on MD5, SHA-1,
and other hash algorithms.

At this time, there is no obvious successor to MD5 and SHA-1 that

could be put into use quickly; there are so many products using
these hash functions that it could take many years to flush out all
use of 128- and 160-bit hashes. That said, NIST announced in 2007
their Cryptographic Hash Algorithm Competition to find the next-
generation secure hashing method.
 Why Three Encryption Techniques?

So, why are there so many different types of cryptographic

schemes? Why can't we do everything we need with just one?

The answer is that each scheme is optimized for some specific

application(s). Hash functions, for example, are well-suited for
ensuring data integrity because any change made to the contents of
a message will result in the receiver calculating a different hash
value than the one placed in the transmission by the sender. Since it
is highly unlikely that two different messages will yield the same
hash value, data integrity is ensured to a high degree of confidence.
 Why Three Encryption Techniques?
Secret key cryptography, on the other hand, is ideally suited to
encrypting messages, thus providing privacy and confidentiality.
The sender can generate a session key on a per-message basis to
encrypt the message; the receiver, of course, needs the same session
key to decrypt the message.

Key exchange, of course, is a key application of public-key

cryptography. Asymmetric schemes can also be used for non-
repudiation and user authentication; if the receiver can obtain the
session key encrypted with the sender's private key, then only this
sender could have sent the message. Public-key cryptography could,
theoretically, also be used to encrypt messages although this is
rarely done because secret-key cryptography operates about 1000
times faster than public-key cryptography.
Cryptographic Techniques for Secure Communication
 Cryptographic Techniques for Secure Communication
Figure 2 puts all of this together and shows how a hybrid
cryptographic scheme combines all of these functions to form a
secure transmission comprising digital signature and digital
envelope. In this example, the sender of the message is Alice and
the receiver is Bob.

A digital envelope comprises an encrypted message and an

encrypted session key. Alice uses secret key cryptography to encrypt
her message using the session key, which she generates at random
with each session. Alice then encrypts the session key using Bob's
public key. The encrypted message and encrypted session key
together form the digital envelope. Upon receipt, Bob recovers the
session secret key using his private key and then decrypts the
encrypted message.
 Cryptographic Techniques for Secure Communication

The digital signature is formed in two steps. First, Alice computes

the hash value of her message; next, she encrypts the hash value
with her private key. Upon receipt of the digital signature, Bob
recovers the hash value calculated by Alice by decrypting the digital
signature with Alice's public key. Bob can then apply the hash
function to Alice's original message, which he has already
decrypted. If the resultant hash value is not the same as the value
supplied by Alice, then Bob knows that the message has been
altered; if the hash values are the same, Bob should believe that the
message he received is identical to the one that Alice sent.
 Cryptographic Techniques for Secure Communication

This scheme also provides non-repudiation since it proves that Alice

sent the message; if the hash value recovered by Bob using Alice's
public key proves that the message has not been altered, then only
Alice could have created the digital signature. Bob also has proof
that he is the intended receiver; if he can correctly decrypt the
message, then he must have correctly decrypted the session key
meaning that his is the correct private key.
 The Significance of Key Length
In a recent article in the industry literature, a writer made the claim
that 56-bit keys do not provide as sufficient protection for DES
today as they did in 1975 because computers are 1000 times faster
today than in 1975. Therefore, the writer went on, we should be
using 56,000-bit keys today instead of 56-bit keys to provide
adequate protection. The conclusion was then drawn that because
56,000-bit keys are infeasible (true), we should accept the fact that
we have to live with weak cryptography (false!). The major error
here is that the writer did not take into account that the number of
possible key values double whenever a single bit is added to the key
length; thus, a 57-bit key has twice as many values as a 56-bit key
(because 2^57 is two times 2^56 ). In fact, a 66-bit key would have
1024 times the possible values as a 56-bit key.

But this does bring up the issue, what is the precise significance of
key length as it affects the level of protection?
 The Significance of Key Length

In cryptography, size does matter. The larger the key, the harder it is
to crack a block of encrypted data. The reason that large keys offer
more protection is almost obvious; computers have made it easier to
attack ciphertext by using brute force methods rather than by
attacking the mathematics (which are generally well-known
anyway). With a brute force attack, the attacker merely generates
every possible key and applies it to the ciphertext. Any resulting
plaintext that makes sense offers a candidate for a legitimate key.
 The Significance of Key Length
Until the mid-1990s or so, brute force attacks were beyond the
capabilities of computers that were within the budget of the attacker
community. Today, however, significant compute power is
commonly available and accessible. General purpose computers
such as PCs are already being used for brute force attacks. For
serious attackers with money to spend, such as some large
companies or governments, Field Programmable Gate Array
(FPGA) or Application-Specific Integrated Circuits (ASIC)
technology offers the ability to build specialized chips that can
provide even faster and cheaper solutions than a PC. Consider that
an AT&T ORCA chip (FPGA) costs $200 and can test 30 million
DES keys per second, while a $10 ASIC chip can test 200 million
DES keys per second (compared to a PC which might be able to test
40,000 keys per second).
 The Significance of Key Length
So, how big is big enough? DES, invented in 1975, is still in use
today, nearly 25 years later. If we take that to be a design criteria
(i.e., a 20-plus year lifetime) and we believe Moore's Law
("computing power doubles every 18 months"), then a key size
extension of 14 bits (i.e., a factor of more than 16,000) should be
adequate. The 1975 DES proposal suggested 56-bit keys; by 1995, a
70-bit key would have been required to offer equal protection and
an 85-bit key will be necessary by 2015.

The discussion above suggests that a 128- or 256-bit key for SKC
will suffice for some time because that key length keeps us ahead of
the brute force capabilities of the attackers. While a large key is
good, a huge key may not always be better. That is, many public-
key cryptosystems use 1024- or 2048- bit keys; expanding the key
to 4096 bits probably doesn't add any protection at this time but it
does add significantly to processing time.
 TRUST MODELS
Secure use of cryptography requires trust. While secret key cryptography can ensure
message confidentiality and hash codes can ensure integrity, none of this works
without trust. In SKC, Alice and Bob had to share a secret key. PKC solved the secret
distribution problem, but how does Alice really know that Bob is who he says he is?
Just because Bob has a public and private key, and purports to be "Bob," how does
Alice know that a malicious person (Mallory) is not pretending to be Bob?

There are a number of trust models employed by various cryptographic schemes. This
section will explore three of them:

The web of trust employed by Pretty Good Privacy (PGP) users, who hold their own
set of trusted public keys.

Kerberos, a secret key distribution scheme using a trusted third party.

Certificates, which allow a set of trusted third parties to authenticate each other and, by
implication, each other's users.

Each of these trust models differs in complexity, general applicability, scope, and
scalability.
 PGP Web of Trust
Pretty Good Privacy is a widely used private e-mail scheme based
on public key methods. A PGP user maintains a local keyring of all
their known and trusted public keys. The user makes their own
determination about the trustworthiness of a key using what is
called a "web of trust."

If Alice needs Bob's public key, Alice can ask Bob for it in another
e-mail or, in many cases, download the public key from an
advertised server; this server might a well-known PGP key
repository or a site that Bob maintains himself. In fact, Bob's public
key might be stored or listed in many places. Alice is prepared to
believe that Bob's public key, as stored at these locations, is valid.