·
Cryptography:
designing ciphers
·
Traditional
methods
·
Substitutions
(disguise symbols)
·
Transposition
(re-order symbols)
·
Combination
of the two
·
Requirements:
·
key
known only to sender and receiver
·
decryption
algorithm exists
·
public
key cryptography
·
developed
by Hellman and Diffie at Stanford (1976)
·
Essence:
·
Encryption
key E is public
·
Decryption
key D is private
·
Plaintext
message M.
·
Characteristics
of D and E:
1.
D
(private) is "very difficult" to deduce from E
2.
E
(public) cannot be broken by plaintext attack
3.
D(E(M)
) = M
·
Procedure:
1.
Sender
encrypts M using receiver's algorithm and key ER
2.
Sender
transmits ER(M)
3.
Receiver
decrypts using its private key: DR(ER(M)) = M
·
And
many more (that time does not permit), such as
·
Data
Encryption Standard (DES), developed by IBM in 70s
·
Escrowed
Encryption Standard, including Clipper chip and skipjack algorithm, that allows
government a back-door key
·
Rivest,
Shamir, Adleman (RSA), a public-key encryption method
Authentication
1.
sender
applies its private DS to M
2.
sender
encrypts the result using receiver's public ER
3.
sender
transmits result: ER(DS(M))
4.
receiver
applies its private DR to get DR(ER(DS(M))),
which is DS(M)
5.
receiver
applies sender's public ES to get ES(DS(M)),
which is M
Secure
communication w/o encrypting data!
Technique
developed by Ron Rivest ( the “R” in RSA) at MIT: chaffing and winnowing.
Basic
concept:
Note
that data themselves are not encrypted, and data field could be as short as 1
bit!
For
more info, see: http://theory.lcs.mit.edu/~rivest/chaffing.txt
Q: If symmetric (shared secret key) encryption is used, how do the two parties come to know the key if they have not “met” before?
A:
obtain from mutually trusted intermediary, called Key Distribution Center (KDC). The KDC is key server which also has a repository
of secret keys between it and each of its clients.
Q: If assymmetric (public key) encryption is used, how does A learn what B’s public key is?
A: Get
from B’s web site or other public place, or obtain certificate from mutually
trusted intermediary called Certification Authority (CA).
Preliminary:
A
has secret key it shares with KDC. This
is KAK.
B
has a secret key it shares with KDC. This
is KBK.
1. A sends request to KDC
KAK
( < request_key, A, B >)
*
request contains A and B i.d.s
*
request encrypted with KAK
2. KDC gets request
*
decrypts to get < request_key, A, B
>
*
generates random session key R
3. KDC sends response to A
KAK
( < grant_key, R, KBK ( < lets_play, A, R > ) > )
*
< lets_play,A,R > contains A’s
i.d. and shared session key R
*
encrypt using KBK (which KDC and B know, but not A). The result, KBK ( < lets_play,
A, R > ), is sometimes called a ticket.
*
response also contains separate copy of session key R that A can use
*
response encrypted with KAK
4. A gets response
* decrypts to get R and the ticket.
5.
A sends ticket to B
KBK
( < lets_play, A, R > )
6. B gets ticket and decrypts to get A’s i.d.
and session key R
7. A and B
communicate using session key R for encryption.
B may post it in public place (e.g. web page or
.plan file), good for manual operations but not good for embedded automated
encryption (e.g. web communication or secure IP routers)
B registers with a CA, which
* verifies B’s identify through an authentication
procedure
* creates certificate containing B’s i.d., public
key, expiration date
* digitally signs certificate
A then requests and obtains certificate from the CA.
To be sure certificate really came from the CA, A
checks certificate’s digital signature.
This requires it to have the CA’s public key. If it does not, it needs to obtain it in a recursive
fashion! Fun and games….
[notes
| CSC 465 | Peter
Sanderson | Computer Science | SMSU ]