Transcript A Gentle Introduction to Cryptography

A Gentle Introduction to
Cryptography
Extended quote from Bruce Schneier's book,
Secrets and Lies.
Cryptography plays a role in computer security,
but buggy computer systems and vulnerable
communications are a reality that cryptography
has not solved.
Quote from Eugene Spafford
“Using encryption on the Internet is the equivalent
of arranging an armored car to deliver credit card
information from someone living in a cardboard
box to someone living on a park bench.”
Outline of these lectures
The general goals of cryptographic systems
Vulnerabilities of cryptographic systems
Two basic categories of cryptographic algorithms:
Symmetric
Asymmetric (public key)
Methods for sharing keys (including DiffieHellman)
Outline (cont.)
Methods for ensuring data integrity (hash
algorithms)
Methods for authentication (digital signatures)
The General Goals of Cryptography
Confidentiality; assuring that only authorized
parties are able to understand the data.
Integrity; ensuring that when a message is sent
over a network, the message that arrives is the
same as the message that was originally sent.
Goals (cont.)
Authentication; ensuring that whoever supplies or
accesses sensitive data is an authorized party.
Nonrepudiation;ensuring that the intended
recipient actually received the message &
ensuring that the sender actually sent the
message.
Basic Terms
Encryption: scrambling a message or data using a
specialized cryptographic algorithm.
Plaintext: the message or data before it gets
encrypted.
Ciphertext: the encrypted (scrambled) version of
the message.
Cipher: the algorithm that does the encryption.
Basic Terms (cont.)
Decryption: the process of converting ciphertext
back to the original plaintext.
Cryptanalysis: the science of breaking
cryptographic algorithms.
Cryptanalyst: a person who breaks cryptographic
codes; also referred to as “the attacker”.
More on Confidentiality
Confidentiality means that only authorized parties
are able to understand the data (authorized from
the perspective of the party that encrypted the
data).
It is okay if unauthorized parties know that there
is data. It is even okay if they copy the data, so
long as they cannot understand it.
Authentication
How can we know that a party that provides us
with sensitive data is an authorized party?
How can we know that the party that is accessing
sensitive data is an authorized party?
This is a difficult problem on the Internet.
Two solutions are:
Passwords
Digital signatures
Integrity
This involves ensuring that when a message (or
any kind of data, including documents and
programs) is sent over a network, the data that
arrives is the same as the data that was originally
sent. It is important that the data has not been
tampered with.
Technical solutions include:
Encryption
Hashing algorithms
Nonrepudiation
Ensuring that the intended recipient actually got
the message.
Ensuring that the alleged sender actually sent the
message.
This is a difficult problem. How do we prove that
a person's cryptographic credentials have not
been compromised?
An Important Message
In theory, some crytographic algorithms seem to
be EXTREMELY secure.
Vulnerabilities arise when systems administrators
do not deploy the encryption systems securely.
A fundamental rule: DON'T CODE YOUR OWN
CRYPTOGRAPH ALGORITHMS.
Another rule: When using a cryptographic library,
use the intuitive user interfaces provided with
those libraries.
Message from Cryptlib Developer,
Peter Gutman
“The major design philosophy behind the code
[behind Cryptlib] is to give users the ability to
build secure apps without needing to spend
several years learning crypto. ... [T]he important
point is that anybody should be able to employ
them [important cryptographic algorithms]
without too much effort. ...”
Standard Algorithms are
Incredibly Secure
Using a 128 bit key for a symmetric encryption
algorithm, there are 2128 possible keys.
Even with the computing resources of the US
government, most of the software developers
alive today will be dead before the government
could break such an encryption [Viega and
McGraw]
Incredibly secure (cont.)
Most security experts believe that 256-bit keys
are good for the lifetime of the universe (many
billions of years).
The problem is that encryption is just one link in
the chain of security. Encryption is a really
strong link in that chain, but one weak link breaks
the chain.
It is usually easier for the attacker to hack your
machine and steal the plaintext than to break your
cipher.
A Simple Example
The plaintext:
0 1 0 0 0 0 1 1 0 1 0 0 0 0 0 1 0 1 0 0 0 0 1 0
The key:
1 1 0 1 0 0 0 1 0 1 0 0 0 0 0 1 0 1 0 0 0 0 1 0
The ciphertext
1 0 0 1 0 0 1 0 0 0 1 1 1 0 0 0 0 1 1 0 1 0 0 1
A Simple Encryption Example
ciphertext:
1 0 0 1 0 0 1 0 0 0 1 1 1 0 0 0 0 1 1 0 1 0 0 1
XOR’d with key
1 1 0 1 0 0 0 1 0 1 0 0 0 0 0 1 0 1 0 0 0 0 1 0
yields plaintext
0 1 0 0 0 0 1 1 0 1 0 0 0 0 0 1 0 1 0 0 0 0 1 0
Common Types of Attacks
Known cipher attacks: the attacker has the
ciphertext and she tries to decrypt the message by
generating all possible keys.
Rarely successful because the number of possible
keys is enormous.
Also, the decrypted message (for certain types of
data) may not be easy to recognize when it appears.
Common Types of Attacks (cont.)
Known plaintext attack: the attacker has both the
ciphertext and the plaintext.
Again, this is difficult because there are so many
keys, but the plaintext information may make
experimentation easier than in the previous case.
We are assuming that the attacker knows the
algorithm that was used for the encryption.
Common Types of Attacks (cont.)
Chosen plaintext attacks: The cryptanalyst
introduces the plaintext into the system and then
watches for how that plaintext will be encrypted.
The Allies used this approach in WWII by sending out
false messages about allied troop movements.
Often the attacker will try to feed a planned sequence
of messages that would reveal the most about the way
in which the data is being encrypted.
Common Types of Attacks (cont.)
Side channel attacks use seemingly incidental
information that can reveal important information
about the key being used.
Viega and McGraw mention DPA (Differential
Power Analysis) attacks on smart cards. A DPA
attack analyzes the power output from a processor
performing an encryption algorithm in order to
get information about the key being used by that
algorithm.
Symmetric Cryptography
Symmetric algorithms are used for:
Confidentiality
Data integrity
Even if an attacker captures the data, the attacker
will not be able to manipulate it in any
meaningful way.
Symmetric Cryptography (cont.)
Symmetric algorithms use a single key shared by
two communicating parties.
The shared key must remain secret to ensure the
confidentiality of the encrypted data.
The shared key problem is the main technological
challenge for this kind of encryption.
We will discuss solutions to the key exchange
problem a bit later.
Figure A-1 from Viega and McGraw
The way symmetric encryption works is shown in
Figure 1-A from Viega and McGraw.
The message and the key are provided as input to
the encryption algorithm.
The output is the ciphertext, which can then be
transferred over an insecure medium.
Figure 1-A (cont.)
On the receiver end, the secret key and the
ciphertext are inputs to the decryption algorithm.
The output is the original plaintext.
Symmetric Cryptography (cont.)
The secret key must be shared securely.
Otherwise, the most sophisticated cryptographic
algorithm is useless.
One method of distributing the key is using the
sneaker-net.
Protocols exist for exchanging keys over an
insurecure medium, but care must be taken to
assure a good authentication process.
Asymmetric cryptography is a common method
for sharing keys.
Symmetric Cryptography
Two main categories of symmetric algorithms:
Block ciphers
Stream ciphers
Most well-known and well-studied symmetric
algorithms use block ciphers.
Block ciphers break up the message into constantsize blocks and encrypt the code block by block.
Block Ciphers
Typical block sizes are 64 bits or 128 bits.
Messages are padded (with extra bits) to fit the
block size.
The simplest type of block ciphers work in ECB
(Electronic Code Book) mode. In this mode, each
block is encrypted separately, independent of the
other blocks (like in our simple XOR example).
Block Ciphers (cont.)
ECB block ciphers are not secure because given
plaintext is always encoded in the same way.
Thus, the attacker can look look for common
linguistic patterns.
These patterns can help the attacker to figure out
the algorithm and key being used.
Block Ciphers (cont.)
In CBC (Cipher Block Chaining) mode, blocks
are also encrypted one at a time, but the initial
state for each block is dependent on the ciphertext
of the previous block.
Thus, the same text will be encrypted in many
different ways. This makes it much more difficult
for the cryptanalyst to crack the cipher.
CBC mode is the default mode for many block
ciphers.
Block Ciphers (cont.)
A variety of block cipher modes exist (in addition
to CBC) for making sure that repeated plaintext is
encoded in different ways throughout the
message.
These modes are the default for the standard
secure symmetric encryption algorithms (like
DES).
Cipher Block Chaining (CBC) Mode
By adding gibberish into the middle of the
ciphertext, the attacker can interfere with the
decryption of a CBC encrypted message.
Two methods are used to defend against this kind
of gibberish attack:
Encode the length of the message at the start of the
message or elsewhere to help the receiver figure out if
the message has been tampered with.
Use a cryptographic checksum (or hash) as a
signature for your message.
Block Ciphers (cont.)
The longer the message, the better chance the
attacker has of breaking the encryption.
Bruce Shneier says that a message would have to
be at least 34 gigabytes in length for a 64-bit
cipher before this would become a genuine risk.
Block Ciphers (cont.)
Two factors influence the security of a symmetric
block cipher:
The quality of the algorithm (e.g., ECB mode ciphers
are less secure).
The length of the key (e.g., 64 bit blocks are
questionable, but 128 bit blocks are considered more
than adequate).
There is a classic trade-off between efficiency and
security.
Security is Hard to Prove
Demonstrating how secure a cryptographic
algorithm is remains an extremely hard problem.
The best test seems to be years of experience and
public exposure.
The “one-time pad” method (which has been used
in the military) is absolutely secure, but not very
practical because the key changes with each
communication.
Extended Quote from Lecture Notes
The two basic goals of a cryptographic algorithm
are (a) to make life difficult for the attacker and
(b) to produce algorithms that are efficient both in
terms of space and time. An algorithm that is too
inefficient to be used in practice is of little value
even if it were proven to be highly secure ...
Quote (cont.)
It is fairly easy for the cryptography researcher to
design an algorithm that is secure against all
KNOWN forms of attack. It is far more difficult
to design an algorithm that will be secure against
types of attacks that are still UNKNOWN. It is
nearly impossible to predict new attacks against
block ciphers that will be manifesting in future
years.
Quote (cont.)
For example, Viega and McGraw state that many
people believe that the NSA has developed
sophisticated attacks against block ciphers that
they have not shared with the rest of the world.
Block Size
A 64-bit cipher is considered too small for high
security applications. According to Bruce
Shneier (back in 1995), an organization such as
the NSA could break a 64-bit key in under one
minute.
A 256-bit key is believed to be secure enough that
a computer made of all the matter in the universe
computing for the entire lifetime of the universe
would have an infinitesimal probability of finding
a key by brute force.
Quantum Computing
But, then there is always
Quantum Computing ....
Important Commercial Algorithms
The most important symmetric algorithms from a
commercial point of view are:
DES (Data Encryption Standard)
3DES
AES (Advanced Encryption Standard)
DES
This has been a US government standard for
many years (although recently complimented
with AES).
It uses a 64-bit key (actually, only 56 bits are used
for the encryption, the other 8 bits are parity bits),
so it is no longer viable.
Increased processing speeds (in recent years) are
making brute force attacks on DES more viable.
3DES
Then, came the idea of using DES twice on a
given message.
A subtle form of attack was discovered which
made 2DES no better than DES.
3DES proved to have the properties that 2DES
was supposed to have.
3DES is a viable and popular symmetric block
algorithm.
3DES has one downside: it is inefficient.
DES According to Denning
DES According to Denning
GET THE IDEA?
3DES
Despite the fact that it is inefficient, 3DES is
considered a very good (and it is a very popular)
choice for encryption.
Several good implementations of 3DES are easily
downloaded off the Internet.
AES
The NIST (National Institute of Standards and
Technology) ran a competition for a new
encryption standard.
The winners were announced in October 2000.
They were Joan Daemen and Vincent Rijmen.
Their algorithm is called RijnDael or AES
(Advanced Encryption Standard).
AES is now an accepted federal standard and is
widely available in open source form.
Implementations are available in C++ and Java.
AES (cont.)
3DES still has the advantage that it has been
studied (in DES) form for many years.
The guestimate is that AES will be a viable
encryption standard for the next 50 years, but
there could be some surprises down the raod.
The Key Distribution Problem
For symmetric ciphers, each pair of
communicating agents needs a unique key.
If there are lots of users, this creates a key
management problem.
Key derivation algorithms are used to generate a
unique key for each communicating pair.
If the master key for the key derivation algorithm
is compromised, you've got a major problem.
Key Distribution (cont.)
Some have even attacked derived keys in a key
distribution system to get the master key.
Another approach is to use a key management
system that generates session keys for each
communication. Even for the same
communicating pair, the session keys will change
from session to session.
Kerberos, from MIT, is a highly regarded open
source computer security product that supports
symmetric key management.
The Great Philosopher, Yogi Berra
“It is difficult to make
predictions, especially about
the future.”
Asymmetric (Public Key) Cryptography
Public key cryptography is an attempt to
circumvent the key distribution problem
completely.
As it turns out, asymmetric algorithms tend to be
very inefficient.
Their main use is in solving the key exchange
problem for symmetric cryptography.
Public Key Crypto (cont.)
In asymmetric cryptography, each user has two
keys: a public key and a private key.
The public key is made public. For example, it
may be published on a Web site.
The private key must be kept secret. It is never
shared with anyone.
The security of the private key in public key
crypto is as important as key security in
symmetric crypto.
Public Key Crypto (cont.)
There is no key distribution problem in public key
cryptography.
Some people have compared public key
cryptography to a mailbox. Many people can put
mail into the mailbox (in effect, using the public
key), but only a postal worker with the
appropriate key (corresponding to the private key)
can retrieve the mail from the mailbox.
Figure A-2
Alice wants to send a message to Bob.
Alice uses Bob’s public key to encrypt the
message.
The encrypted message is sent over the insecure
medium.
Bob uses his private key to decrypt the encrypted
message.
No one but Bob knows the private key.
Public Key Crypto (cont.)
Public key encryption and decryption algorithms
tend to be incredibly slow relative to symmetric
key algorithms.
Public key algorithms tend to be about 100 times
slower than DES.
In general, encrypting large messages using
public key cryptography is not considered
practical.
Public Key Crypto (cont.)
The most important use for public key
cryptography is for solving the symmetric
cryptography key exchange problem.
Viega and McGraw say that using public key
cryptography is a more secure choice than using
key derivation algorithms.
SSL uses this strategy: public key crypto for
sharing keys and symmetric algorithms for
encrypting the message.
Rivest, Shamir, and Adelman (RSA)
RSA is the most famous public key algorithm.
RSA starts with picking two HUMONGOUS
prime numbers, p and q. Each of these prime
numbers contains hundreds to thousands of bits.
The two prime numbers remain secret (they are
the private key).
Their product, n = p * q, is the public key.
RSA (cont.)
The product (the public key) is used to encrypt
the message.
Only someone who knows the prime factors can
decrypt the message in a reasonable amount of
time.
The security of RSA is based on the difficulty of
factoring n into the prime factors p and q.
At this point in history, this is seen as a difficult
problem.
RSA (cont.)
RSA is still considered secure after twenty years
of use.
The big security problem is that some
implementations of RSA have been flawed and
had security problems of their own.
The software developer should use a well-tested
and highly-regarded implementation of RSA.
Never code your own!!!
RSA (cont.)
There are huge numbers of large prime numbers.
There are approximately 10151 primes of length
512 bits or less.
One interpretation is that there are enough primes
of up to 512 bits to assign every atom in the
universe 1074 prime numbers without ever
repeating one of those primes.
The Future of RSA
The future of RSA is hard to predict.
It depends upon what happens in prime number
factoring theory.
Not too many years ago, experts believed that no
one would ever have the resources necessary to
factor a 128 bit number.
Now, an organization with adequate resources,
can factor a 512 bit number in just a few months.
The Future of RSA (cont.)
Viega and McGraw recommend that you use no
less than a 2,048 bit key for data requiring longterm security (ten or more years).
It may be that 1,024 bit numbers may be nearing
the end of their usefulness even for short-term
security.
The longer the key, the longer it takes to encrypt
messages using public key cryptography.
Public Key Crypto Vulnerabilities
Public Key encryption algorithms are more
susceptible to chosen plaintext attacks than
symmetric algorithms.
However, since public key is generally used to
encrypt small messages (like keys), plaintext
attacks are not a practical problem.
More significant is the “man-in-the-middle” type
of attack.
“Man-in-the-Middle” Attacks
Figure A-3 depicts a “man-in-the-middle” attack.
First, let’s consider this kind of attack in terms of
Alice trying to send a message to Bob.
In this kind of attack, Ted sends Alice his own
public key, misrepresenting it as Bob’s public
key.
Ted is pretending that he is Bob when he is
communicating with Alice.
Man-in-the-Middle (cont.)
Ted sends Bob Ted’s own public key,
misrepresenting it as Alice’s public key.
Ted is pretending to be Alice when he
communicates with Bob.
Ted is intercepting all traffic between Bob and
Alice.
Man-in-the-Middle (cont.)
When Alice sends Bob a message, she encrypts it
using Ted’s public key (she thinks it is Bob’s).
When Ted receives Alice’s message, he can
decrypt it.
Ted can then send Bob a modified or entirely
different message, encrypting it was Bob’s public
key.
Bob decrypts the message, thinking it came from
Alice.
“Man-in-the-Middle” (cont.)
Figure A-3 depicts the situation in terms of a
client and a server.
The client (Alice) asks for the server’s public key
so she can send secure information to the server
(Bob).
But, the client is not communicating with the
server. She is communicating with the attacker,
who sends her his public key.
Man-in-the-Middle (cont.)
Meanwhile, the attacker establishes his secure
connection with the server.
This gives the attacker access to any information
that the client sends to the server and any
information that the server sends back to the
client.
This kind of problem motivates the need for a
public key infrastructure (PKI).
PKI
The basic idea behind a Public Key Infrastructure
(PKI) is that a trusted third party certifies valid
keys.
Back to Bob and Alice. In this case, Alice would
receive Bob’s public key through a trusted third
party, a certification authority (CA).
The CA would say, in effect: “Alice, trust us, Bob
is a dependable fellow and this is Bob’s public
key.”
PKI (cont.)
Obviously, this does not solve the matter of trust
(the security problem).
How can Alice be sure that she can trust the socalled trusted authority?
One of the largest CA’s at this point in time is
Verisign.
Verisign performs background checks on
applicants before issuing them a public key for a
fee.
PKI (cont.)
Verisign’s track record is not perfect.
Several people registered with Verisign under the
name “Bill Gates”.
In March 2001 Microsoft announced that two
false keys with MS’s name on them had been
issued by a CA.
PKI (cont.)
The problem of trusted identity, taken
from Viega and McGraw ….
PKI (cont.)
Advice for developers from
Viega and McGraw ...
Cryptographic Hashing Functions
for Data Integrity
Cryptographic hashing functions are used to
ensure the integrity of data.
Cryptographic hashing functions are sometimes
called cryptographic checksums or integrity
checksums.
Hashing functions are also used for digital
signatures, which we shall discuss later.
Integrity Checksums
Since stuff happens, it is important to have some
means of detecting unauthorized changes to files.
An integrity checksum is a value that is computed
from the data that is being protected.
The integrity checksum is stored separately from
the protected data.
Integrity checksums (cont.)
The recipient of the data recomputes the
checksum from the data that is received and
compares that checksum to the value that was
recorded separately by the provider of the data.
If the original checksum and the recomputed
checksum do not match, then the data has been
changed in some way.
Desirable Qualities for
Checksum Computations
The computation must depend upon every single
bit in the data, so that if even one bit is changed,
that will be reflected in the checksum.
The computation must be such that it would be
rare for two messages to have exactly the same
checksums.
The checksum should not reflect the original data
in any obvious way.
Desirable properties (cont.)
The third property implies that an attacker would
not be able to figure out how to manipulate the
data so that the cryptographic checksums for the
valid data and the corrupted data would wind up
being the same. Another way of stating this is
that it would be difficult for the attacker to
reverse engineer the checksum computation.
Hashing functions
Checksums are computed using hashing
functions.
Hashing functions are one-way functions. This
means that the ciphertext (i.e., the checksum)
cannot be used to reconstruct the plaintext.
The checksum (the ciphertext) is much smaller
than the plaintext.
Hashing functions (cont.)
Hashing functions provide a kind of digital
fingerprint.
When we take a fingerprint, we lose a lot of
information about the person.
Still fingerprints and checksums are useful
despite the information that is lost.
Checksums are sometimes called cryptographic
or digital fingerprints.
Hashing functions (cont.)
A checksum is sometimes called:
A message digest, or
A message authentication code, or MAC
The security of the hashing function is related to
the size of the resulting checksum (in bits).
Viega and McGraw suggest using hashing
functions that produce a checksum of at least 160
bits.
Checksum Systems
SHA-1 is a federal standard for computing
checksums.
SHA-1 does not use secret keys. The checksum
is computed with a public hashing function and
needs to be stored in a safe way. For example:
On a secure medium an attacker cannot modify
Encrypted on a completely separate medium from the
original data
Checksum systems (cont.)
SHA-1 uses a 160 bit digest.
SHA-1 is known to be secure.
Newer versions of SHA may have security
problems because they have not been as
thoroughly tested as SHA-1.
Tripwire is a checksum system that works with
the operating system to see if files have been
created, deleted, or modified in an unauthorized
way.
Hashing Functions and Passwords
Hashing functions are often used to store
passwords for users who are logging onto a multiuser system.
When the user tries to log in with his or her
established password, the login program hashes it,
and compares the newly hashed password with
the stored hash.
If the two are equal, the system assumes the user
typed in the right password.
Telnet and other Internet Protocols
With Telnet, the password goes over the network
unhashed.
A packet sniffer could be used to catch the
password in transit.
Telnet authentication provides a very low bar for
potential attackers to clear.
Other protocols that have a similarly weak
authentication mechanism include FTP, POP3,
and IMAP.
Attacks on Hashing Computations
A brute force attack involves finding an
alternative text that will yield the same hash
signature. This is usually fairly difficult because
the alternative text is likely to be gibberish.
An effective attack is called a birthday attack.
A Simple Birthday Attack
Suppose Bob and Alice enter an agreement in
which Alice agrees to pay Bob $5.00 per widget.
This agreement is sent to Bob with a
cryptographic checksum. Bob decides not to
store the original document on his server, just the
checksum thinking that would be adequate
evidence if Alice tries to present an alternative
document ...
A Simple Birthday Attack (cont.)
In fact, Alice does try to present an alternative
document which states that the agreement is that
she pay $1.00 per widget. Bob thinks she will fail
in a legal battle because he has the cryptographic
checksum. Unfortunately for Bob, Alice's new
document has the same checksum as the original
and Bob loses in court.
A Simple Birthday Attack (cont.)
What Alice did (what is called a birthday attack)
involved taking the original document (with the
known checksum) and replacing all references to
$5 to $1. Then, she systematically reformats the
$1 per widget document by changing spaces to
tabs and so forth. Eventually she finds a $1
document that has the same checksum as the
original $5 document.
This kind of attack would be difficult with
checksums of 512 or even 256 bits.
Digital Signatures for Authentication
Public key encryption enabled the development of
the technology of digital signatures.
Digital signatures are somewhat analogous to
traditional handwritten signatures.
Digital signatures are strongly bound to the
document, but weakly bound to the individual.
A digital signature is computed, in part, using the
contents of the document being signed.
Main Goals of Digital Signatures
A signature should be proof of authenticity. Its
existence on a document should be able to
convince people that the person whose signature
appears on the document signed the document.
A signature should be impossible to forge. The
person who signed the document should not be
able to claim that the signature is not theirs
(support for non-repudiation).
Main Goals (cont.)
After the document is signed, it should be
impossible to alter the document without
detection. The signature is intrinsically linked to
the document that is being signed.
It should be impossible to transplant the signature
to another document. Again, the digital signature
is intrinsically linked to the document that is
being signed.
Figure 12.1 from Denning
This figure shows one scheme for digital
signatures that uses public key cryptography and
hash algorithms (the usual technology).
As you might have guessed, Alice wants to send a
sign and encrypted message to Bob.
Here's how it works:
Figure 12.1 (cont.)
1. Alice generates a message key, K, for symmetric
encryption. Alice encrypts the message M with
K, getting the ciphertext message, CM.
2. Alice encrypts K with Bob's public keyencrypting key, Kbobpub, getting the ciphertext key,
CK. This will allow Bob to retrieve the key for
decrypting the ciphertext.
Figure 12.1 (cont.)
3. Alice uses a hashing function to compute a
checksum for the message, M. She then encrypts
the checksum (for public key encryption) using
her private signature key KSAlicepriv. The
encrypted checksum is the signature, S.
4. Alice sends CK (the encrypted message key),
CM (the encrypted message), and S (the digital
signature) to Bob.
Figure 12.1 (cont.)
5. Bob uses his private key, Kbobpriv, to decrypt CK.
This gives him the key, K, that Alice originally
sent to encrypt the message, M.
6. Bob uses K to decrypt CM (the encrypted
message) to get the message, M.
7. Bob uses Alice's public signature key KSAlicepub
to validate S, the digital signature. This requires
that Bob use the hashing function to hash the
message M. The resulting checksum should be
equal to the decrypted signature, S.
Figure 12.1 (cont.)
This technology of digital signatures uses:
A hash function to help generate the digital
signature, S.
Symmetric (secret key) cryptography to encrypt
the message, M.
Public key cryptography to share the secret key
used to encrypt and decrypt the message, M.
Public key cryptography to encrypt and decrypt
the digital signature, S.
Pretty Good Privacy (PGP)
This is how Bob and Alice would accomplish the
same goals using a user-friendly e-mail
encryption system called Pretty Good Privacy
(PGP):
1. Alice composes an e-mail message to Bob. She
clicks on a button or menu item that says “send
signed and encrypted”.
Pretty Good Privacy (cont.)
2. The encryption system prompts Alice for a
password. The password unlocks her private
signature key, which is stored encrypted on disk
or on a separate storage medium.
3. The encryption system looks up Bob‘s public key
(for encrypting messages sent to Bob under
public key cryptography) in Alice's address book
or on her “digital key ring” which is stored in a
file on her disk.
Pretty Good Privacy (cont.)
3 (cont.). The digital key ring generates K, the
symmetric key that will be shared with Bob, and
computes CK, the encrypted key, CM, the
encrypted message, and S, the digital signature.
It puts the message in the outbound queue.
4. When the message shows up in Bob's inbox, he
clicks on a button to read the message.
Pretty Good Privacy (cont.)
5. Bob's encryption system prompts him for a
password, which unlocks his private key. It
decrypts CK to retrieve K, and then uses K to
decrypt CM, to get the message M.
6. The encryption system on Bob's machine then
looks up Alice's public signture key in Bob's
address book or key ring. It validates her
signature S. The decrypted message is displayed
to Bob along with an indication as to whether the
signature was valid.
Pretty Good Privacy (cont.)
Alice and Bob each have two digital key rings
when they use PGP. They have a private ring that
holds their private keys and a public ring that
holds their own public keys and the public keys
of those they are communicating with.
The key rings are implemented as files stored on
the hard drive or on a diskette.
Diffie-Hellman
Diffie-Hellman is another popular method for
sharing secret keys.
Diffie-Hellman has some similarities to the use of
public key encryption to share secret keys.
This method was developed in 1976 by Whitfield
Diffie and Martin Hellman, two cryptographers at
Stanford University.
In 1997 it was revealed that British
cryptographers had developed a similar idea in
the 1960s and early 1970s.
Diffie-Hellman (cont.)
Here is a simple description of the Diffie-Hellman
protocol that allows two parties to compute a
message key for symmetric encryption without
that secret ever being shared explicitly:
1. Each party independently generates a private key.
2. They each compute a public key as a
mathematical function of their individual private
keys.
Diffie-Hellman (cont.)
3. They exchange public keys.
4. Each party then computes a message key (the
secret key) which is derived from their own
private key and the other person's public key.
They both arrive at the same message key.
Diffie-Hellman (cont.)
The public keys must be computed using a oneway function (a hashing function) that makes it
imposible to get back the private keys from the
publicly exchanged keys.
If an attacker has access to one party's public key
and the other party's private key, the attacker
could compute the message key.
The mathematics is such that the publicly
exchanged keys cannot reveal either party's
private key.
Diffie-Hellman (cont.)
The mathematics is based on the following
relationship:
y = gx mod N
It is easy to compute y if g, x, and N are known, but
it is not easy to compute x if y, g, and N are
known.
The problem of finding x is called the discrete
logarithm problem because x is the logarithm of y
base g (mod N). For numbers that are hundreds
of digits long, this is a hard problem.
Diffie-Hellman (cont.)
Here is how Diffie-Hellman works, allowing Allice
and Bob to establish a secret message key.
Assume that p is some prime number and g is a
base number:
Alice generates a secret key, xalice.
Bob generates a secret key, xbob.
Alice computes a public key yalice = gxalice mod
p.
Bob generates a public key ybob = gxbob mod p.
Diffie-Hellman (cont.)
Bob and Alice exchange their public keys.
Alice now computes the message key, K, as
K = ybobxalice mod p
Bob now computes the message key, K, as
K = yalicexbob mod p
Both Bob and Alice end up with the same key,
namely:
K = gxalice * xbob mod p
Diffie-Hellman (cont.)
In practice, very large numbers are used (several
hundred DIGITS each), but here is an example
using small numbers:
p = 11, g = 5, xalice = 2, xbob = 3.
Alice computes her public key
yalice = 52 mod 11 = 3.
Bob computes his public key
ybob = 53 mod 11 = 4.
Diffie-Hellman (cont.)
Bob and Alice exchange their public keys.
Alice computes the message key, K, as
K = 42 mod 11 = 5.
Bob computes the message key, K, as
K = 33 mod 11 = 5.
Both kend up with the same message key,
namely:
K = 52*3 mod 11 = 15,625 mod 11 = 5.
Diffie-Hellman (cont.)
Diffie-Hellman are used in several network
protocols and commercial products, including
PGP.
With Diffie-Hellman, keys can be generated as
needed (on the fly) and they can be discarded at
the end of the conversation.
Software Developers and
Cryptography
According to Viega and McGraw the most common
mistakes developers make with respect to
cryptography are:
Failing to apply cryptographywhen it is needed.
Applying cryptography in an incorrect manner when
it is deployed.
Developers and Crypto (cont.)
The most important rule is:
Never, Never implement your own
cryptographic algorithms!!!
An experienced cryptanalyst will not be deterred
by the fact that an algorithm is secret (not in the
public domain). Their tools do not require
knowledge of the algorithm.
Developers and Crypto (cont.)
The safest policy is to use a published, well-used
algorithm that has been well-scrutinized by
respected cryptographers over a period of at least
a few years.
Developers and Crypto (cont.)
Viega and McGraw note that most of the major
network protocols that use encryption have been
broken at least once. These include:
SSL (Secure Socket Layer) version 2 – this should
never be used.
SSH (Secure Shell Protocol) version 1 – this should
be avoided.
MS's Point-to-Point protocol used in MS's Virtual
Private Network (VPN).
Developers and Crypto (cont.)
It is not only important to use well-known
encryption algorithms, but also to use wellscrutinized implementations of those algorithms,
because the algorithms could be implemented
incorrectly.
Developers also need to understand the legal
framework surrounding cryptography. The laws
have been weakened somewhat concerning
shipping strong crypto stuff overseas, but there
are still laws governing this domain.
Developers and Crypto (cont.)
The best bet, in terms of avoiding legal
complications, is to use off-the-shelf, freely
available cryptographic packages.
Handout with reviews of two cryptographic
libraries.