1. Lecture 4: Cryptography III; Email Security
CS 336/536: Computer Network Security
Fall 2015
Nitesh Saxena

2. Course Administration
HW/Lab 1 Posted
Due at 11am on Sep 28
Labs are active starting this week
Travel next week
Attending and presenting at a conference in Vienna:
No class next week
Would not affect our coverage
Please utilize this time to do HW and review the previous lectures
6/2/2018
Lecture 4: Crypto, and Security

3. Outline of Today’s lecture
6/2/2018
Outline of Today’s lecture
Hash Functions
Message Authentication Code
Security
Key Distribution
Private Key Setting
Public Key Setting
6/2/2018
Lecture 4: Crypto, and Security

4. Lecture 4: Crypto, and Email Security
Hash Functions
6/2/2018
Lecture 4: Crypto, and Security

5. Cryptographic Hash Functions
6/2/2018
Cryptographic Hash Functions
Requirements of cryptographic hash functions:
Can be applied to data of any length.
Output is fixed length, usually very short
Relatively easy to compute h(x), given x
Function is deterministic
Infeasible to get x, given h(x). One-wayness property
Infeasible to find any pair x and y (x ≠ y) such that h(x) = h(y). Collision resistance property
6/2/2018
Lecture 4: Crypto, and Security

6. Some Applications of Hash Functions
6/2/2018
Some Applications of Hash Functions
In general, can be used as a checksum for large amounts of data
Password hashing
Digital signatures
Message authentication codes (will study in a bit)
Used also in RSA-OAEP, and many other cryptographic constructions
6/2/2018
Lecture 4: Crypto, and Security

7. Lecture 4: Crypto, and Email Security
6/2/2018
Hash Output Length
How long should be the output (n bits) of a cryptographic hash function?
To find collision - randomly select messages and check if hash matches any that we know.
Throwing k balls in N = 2n bins. How large should k be, before probability of landing two balls in the same becomes greater than ½?
Birthday paradox - a collision can be found in roughly sqrt(N) = 2(n/2) trials for an n bit hash
In a group of 23 (~ sqrt(365)) people, at least two of them will have the same birthday (with a probability > ½)
Hence n should be at least 160
6/2/2018
Lecture 4: Crypto, and Security

8. Lecture 4: Crypto, and Email Security
6/2/2018
Birthday Paradox
Probability that hash values of k random messages are distinct is (that is, no collisions) is:
6/2/2018
Lecture 4: Crypto, and Security

9. Generic Hash Function – Merkle-Damgard Construction
6/2/2018
Generic Hash Function – Merkle-Damgard Construction
This design for H() is collision-resistant given that h() is collision resistant
Intuitively, this is because there is a avalanche effect – even if the inputs differ in just 1 bit, the outputs will be completely different
IV is a known public constant

10. An Illustrative Example
6/2/2018
An Illustrative Example
6/2/2018
Lecture 4: Crypto, and Security

11. Lecture 4: Crypto, and Email Security
Practical Examples
SHA-1
Output 160 bits
B’day attack requires 280 calls
MD5
Output is 128 bits
B’day attack requires 264 calls only
Better use stronger versions, such as SHA-256
B’day attack requires 2128 calls
6/2/2018
Lecture 4: Crypto, and Security

12. Lecture 4: Crypto, and Email Security
6/2/2018
Further Reading
Stallings Chapter 3
HAC Chapter 9
6/2/2018
Lecture 4: Crypto, and Security

13. Message Authentication Codes
6/2/2018
Lecture 4: Crypto, and Security

14. Message Authentication Codes
6/2/2018
Message Authentication Codes
Provide integrity as well as authentication
Send (m, MAC); MAC is created on m using the key shared between two parties
Has to be deterministic to enable verification
Unlike encryption schemes
We want MAC to be as small and as secure as possible
Can not provide non-repudiation
Why not?
6/2/2018
Lecture 4: Crypto, and Security

15. Lecture 4: Crypto, and Email Security
6/2/2018
MAC – Functions
KeyGen – outputs a key
MAC – creates a checksum on m using key K
Verify – validates whether the checksum on m is computed correctly
Just create MAC and compare
6/2/2018
Lecture 4: Crypto, and Security

16. Security Notion for MAC
6/2/2018
Security Notion for MAC
Very similar to the security notion for a digital signature scheme
Existential forgery under (adaptively) chosen message attack
6/2/2018
Lecture 4: Crypto, and Security

17. MAC Based on Block Cipher in the CBC mode – CBC-MAC
6/2/2018
MAC Based on Block Cipher in the CBC mode – CBC-MAC
6/2/2018
Lecture 4: Crypto, and Security

18. Lecture 4: Crypto, and Email Security
6/2/2018
CBC-MAC
Note that this is deterministic
IV = [0]
Unlike CBC encryption
Only the last block of the output is used as a MAC
This is secure under CMA attack
For pre-decided fixed-length messages
Intuitively because of the presence of an avalanche effect
6/2/2018
Lecture 4: Crypto, and Security

19. HMAC: MAC using Hash Functions
6/2/2018
HMAC: MAC using Hash Functions
Developed as part of IPSEC - RFC Also used in SSL etc.
Key based hash but almost as fast as non-key based hash functions.
Avoids export restrictions unlike DES based MAC.
Provable security
Can be used with different hash functions like SHA-1,MD5, etc.
6/2/2018
Lecture 4: Crypto, and Security

20. Lecture 4: Crypto, and Email Security
6/2/2018
HMAC
Block size b bits.
K+ - K padded with bits on the left to make b bits.
ipad – (ox36) repeated b/8 times.
opad – (0x5c) repeated b/8 times.
Essentially
HHMACK = H[(K+ xor opad) || H[(K+ xor ipad) || M]]
6/2/2018
Lecture 4: Crypto, and Security

21. Lecture 4: Crypto, and Email Security
6/2/2018
Security of HMAC
Security related to the collision resistance of the underlying hash function
6/2/2018
Lecture 4: Crypto, and Security

22. Lecture 4: Crypto, and Email Security
6/2/2018
Further Reading
Stallings Chapter 3
HAC Chapter 9
6/2/2018
Lecture 4: Crypto, and Security

23. Lecture 4: Crypto, and Email Security
Security via PGP
6/2/2018
Lecture 4: Crypto, and Security

24. Lecture 4: Crypto, and Email Security
is one of the most widely used and regarded network services
By default, communication is NOT “secure”
may be inspected either in transit, or by suitably privileged users on destination system
may be impersonated/spoofed
In virtually all distributed environments, electronic mail is the most heavily used network-based application. But current services are roughly like "postcards”, anyone who wants could pick it up and have a look as its in transit or sitting in the recipients mailbox.
6/2/2018
Lecture 4: Crypto, and Security

25. Email Security Enhancements
Confidentiality
protection from disclosure
Authentication
of sender of message
Message integrity
protection from modification
Non-repudiation of origin
protection from denial by sender
With the explosively growing reliance on electronic mail for every conceivable purpose, there grows a demand for authentication and confidentiality services. What we want is something more akin to standard mail (contents protected inside an envelope) if not registered mail (have confidence about the sender of the mail and its contents). That is, the “classic” security services listed are desired.
6/2/2018
Lecture 4: Crypto, and Security

26. Pretty Good Privacy (PGP)
Open source, freely available software package for secure
De facto standard for secure
Developed by Phil Zimmermann
Selected best available crypto algorithms to use
Runs on a variety of platforms like Unix, PC, Macintosh and other systems
Originally free (now also have commercial versions available)
The Pretty Good Privacy (PGP) secure program, is a remarkable phenomenon, has grown explosively and is now widely used. Largely the effort of a single person, Phil Zimmermann, who selected the best available crypto algorithms to use & integrated them into a single program, PGP provides a confidentiality and authentication service that can be used for electronic mail and file storage applications. It runs on a wide range of systems, in both free & commercial versions.
6/2/2018
Lecture 4: Crypto, and Security

27. PGP Operation – Authentication
Just use digital signatures:
Sender creates message
Generates a digital signature for the message
Use SHA-1 to generate 160-bit hash of message
Signed hash with RSA using sender's private key, and is attached to message
Receiver uses RSA with sender's public key to decrypt and recover hash code
Receiver verifies received message using hash of it and compares with decrypted hash code
The actual operation of PGP consists of five services: authentication, confidentiality, compression, compatibility, and segmentation.
Here see the digital signature service provided by PGP, using the steps as shown. Note this assumes use of RSA digital signatures, recent PGP versions also support the use of DSS signatures. Signatures can also be detached from a message/file and sent/stored separately.
6/2/2018
Lecture 4: Crypto, and Security

28. PGP Operation – Confidentiality
Sender generates a message
Generates a128-bit random number as session key
Encrypts the message using CAST-128 / IDEA / 3DES in CBC mode with session key
Session key encrypted using RSA with recipient's public key and attached to the msg
Receiver uses RSA with private key to decrypt and recover session key
Session key is used to decrypt message
Another basic service provided by PGP is confidentiality, provided by encrypting messages to be transmitted or to be stored locally as files, using symmetric encryption algorithms CAST-128, IDEA or 3DES in 64-bit cipher feedback (CFB) mode. The randomly chosen session key used for this is sent encrypted using the recipient’s public RSA key. The steps used in this process are as shown. Recent PGP versions also support the use of ElGamal (a Diffie-Hellman variant) for session-key exchange.
6/2/2018
Lecture 4: Crypto, and Security

29. PGP Operation – Confidentiality & Authentication
Can use both services on the same message
create signature & attach it to the message
encrypt both message & signature
attach RSA encrypted session key
This sequence is preferred because
--one can store the plaintext message/file and its signature
--no need to store the ciphertext for future signature verification
Both confidentiality & authentication services may be used for the same message. Firstly a signature is generated for the plaintext message and prepended to the it. Then the plaintext message plus signature is encrypted using CAST-128 (or IDEA or 3DES), and the session key is encrypted using RSA (or ElGamal).
6/2/2018
Lecture 4: Crypto, and Security

30. PGP Operation – Compression
PGP compresses messages to save space for transmission and storage
By default, PGP compresses message after signing but before encrypting
so can store uncompressed message & signature for later verification
Encryption after compression strengthens security (because compression has less redundancy)
uses ZIP compression algorithm
By default PGP compresses the message after applying the signature but before encryption. This has the benefit of saving space both for transmission and for file storage. The signature is generated before compression for the reasons shown. The compression algorithm used is ZIP, which is described in Stallings Appendix 15A.
6/2/2018
Lecture 4: Crypto, and Security

31. PGP Operation – Email Compatibility
When using PGP will have binary data (8-bit octets) to send (encrypted message, etc)
However, was designed only for text
Hence PGP must encode raw binary data into printable ASCII characters
uses radix-64 algorithm
maps 3 bytes to 4 printable chars
also appends a CRC
PGP also segments messages if too big
(maximum length 50,000 octets)
When PGP is used, at least part of the block to be transmitted is encrypted, and thus consists of a stream of arbitrary 8-bit octets. However many electronic mail systems only permit the use of ASCII text. To accommodate this restriction, PGP provides the service of converting the raw 8-bit binary stream to a stream of printable ASCII characters. It uses radix-64 conversion, in which each group of three octets of binary data is mapped into four ASCII characters. This format also appends a CRC to detect transmission errors. See Stallings Appendix 15B for a description.
PGP also automatically subdivides a message that is too large for a single , into segments that are small enough to send.
6/2/2018
Lecture 4: Crypto, and Security

32. PGP Operation – Summary
Stallings Figure 15.2 illustrates the general operation of PGP, and the relationship between the services discussed.
6/2/2018
Lecture 4: Crypto, and Security

33. Lecture 4: Crypto, and Email Security
PGP Session Keys
Need a session key for each message
of varying sizes: 56-bit DES, 128-bit CAST or IDEA, 168-bit Triple-DES
Uses random inputs taken from
actual keys hit
keystroke timing of a user
mouse movement
PGP makes use of four types of keys: one-time session symmetric keys, public keys, private keys, and passphrase-based symmetric keys.
Each session key is associated with a single message and is used only for the purpose of encrypting and decrypting that message. Random numbers are generated using the ANSI X12.17 generator, with inputs based on keystroke input from the user, where both the keystroke timing and the actual keys struck are used to generate a randomized stream of numbers. Stallings Appendix 15C discusses PGP random number generation techniques in more detail.
6/2/2018
Lecture 4: Crypto, and Security

34. PGP Public & Private Keys
Since many public/private keys may be in use, need to identify which is actually used to encrypt session key in a message
Could send full public-key with every message
But, this is inefficient
Rather use a key identifier based on key
is least significant 64-bits of the key
will very likely be unique
also use key ID in signatures
Since many public/private keys may be in use with PGP, there is a need to identify which key is actually used to encrypt the session key for any specific message. You could just send the full public-key with every message, but this is inefficient. Rather PGP use a key identifier based on the least significant 64-bits of the key, which will very likely be unique. Then only the much shorter key ID would need to be transmitted with any message. A key ID is also required for the PGP digital signature.
6/2/2018
Lecture 4: Crypto, and Security

35. Lecture 4: Crypto, and Email Security
PGP Key Rings
each PGP user has a pair of keyrings:
public-key ring contains all the public-keys of other PGP users known to this user, indexed by key ID
private-key ring contains the public/private key pair(s) for this user, indexed by key ID & encrypted key (encrypted with a hashed passphrase)
security of private keys thus depends on the pass-phrase security
Keys & key IDs are critical to the operation of PGP. These keys need to be stored and organized in a systematic way for efficient and effective use by all parties. PGP uses a pair of data structures, one to store the users public/private key pairs - their private-key ring; and one to store the public keys of other known users, their public-key ring. The private keys are kept encrypted using a block cipher, with a key derived by hashing a pass-phrase which the user enters whenever that key needs to be used. As in any system based on passwords, the security of this system depends on the security of the password, which should be not easily guessed but easily remembered.
6/2/2018
Lecture 4: Crypto, and Security

36. PGP Message Generation
Stallings Figure 15.5 illustrates how these key rings are used in message transmission to implement the various PGP crypto services (ignoring compression and radix-64 conversion for simplicity).
6/2/2018
Lecture 4: Crypto, and Security

37. Lecture 4: Crypto, and Email Security
PGP Message Reception
Stallings Figure 15.6 then illustrates how these key rings are used in message reception to implement the various PGP crypto services (again ignoring compression and radix-64 conversion for simplicity).
6/2/2018
Lecture 4: Crypto, and Security

38. Lecture 4: Crypto, and Email Security
PGP Key Distribution
Public keys for encrypting session keys / verifying signatures.
Private keys for decrypting session keys / creating signatures.
Where do these keys come from and on what basis can they be trusted?
S/MIME and PGP address these questions in quite different ways.
What goes wrong if you use the wrong public key to encrypt or verify?
6/2/2018
Lecture 4: Crypto, and Security

39. Lecture 4: Crypto, and Email Security
PGP Key Distribution
PGP adopts a trust model called the web of trust.
No centralized authority
Individuals sign one another’s public keys, these “certificates” are stored along with keys in key rings.
PGP computes a trust level for each public key in key ring.
Users interpret trust level for themselves.
6/2/2018
Lecture 4: Crypto, and Security

40. PGP Key Distribution Issues
Original intention was that all users would contribute to web of trust.
Reality is that this web is sparsely populated.
How should security-unaware users assign and interpret trust levels?
Later versions of PGP support X.509 certs.
Another HP story here: academic and HP employee using PGP as guerrilla secure solution.
6/2/2018
Lecture 4: Crypto, and Security

41. Lecture 4: Crypto, and Email Security
PGP in Practice
PGP plugins available
Standalone clients (Enigmail)
Browser extensions (e.g., FireGPG, Mailvelope)
SecureGmail (Chrome extension)
You will be playing around with this as part of Lab 1 (Problem 1)
6/2/2018
Lecture 4: Crypto, and Security

42. Lecture 4: Crypto, and Email Security
References
Chapter 8 of Stallings
6/2/2018
Lecture 4: Crypto, and Security

43. Lecture 4: Crypto, and Email Security
Key Distribution
6/2/2018
Lecture 4: Crypto, and Security

44. Lecture 4: Crypto, and Email Security
6/2/2018
Key Distribution
Cryptographic primitives seen so far assume
In private key setting: Alice and Bob share a secret key which is unknown to Oscar.
In public key setting: Alice has a “trusted” (or authenticated) copy of Bob’s public key.
But how does this happen in the first place?
Alice and Bob meet and exchange key(s)
Not always practical or possible.
We need key distribution, first and foremost!
Idea: make use of a trusted third party (TTP)
6/2/2018
Lecture 4: Crypto, and Security

45. “Private Key” Distribution: An Attempt
6/2/2018
“Private Key” Distribution: An Attempt
Protocol assumes that Alice and Bob share a session key KA and KB with a Key Distribution Center (KDC).
Alice calls Trent (Trusted KDC) and requests a session key to communicate with Bob.
Trent generates random session key K and sends E KA(K) to Alice and E KB(K) to Bob.
Alice and Bob decrypt with KA and KB respectively to get K.
This is a key distribution protocol.
Susceptible to replay attack!

46. Session Key Exchange with KDC – Needham-Schroeder Protocol
6/2/2018
Session Key Exchange with KDC – Needham-Schroeder Protocol
A -> KDC IDA || IDB || N1
(Hello, I am Alice, I want to talk to Bob, I need a session Key and here is a random nonce identifying this request)
KDC -> A E KA( K || IDB || N1 || E KB(K || IDA))
Encrypted(Here is a key, for you to talk to Bob as per your request N1 and also an envelope to Bob containing the same key)
A -> B E KB(K || IDA)
(I would like to talk using key in envelope sent by KDC)
B -> A E K(N2)
(OK Alice, But can you prove to me that you are indeed Alice and know the key?)
A -> B E K(f(N2)) (Sure I can!)
Dennig-Sacco (replay) attack on the protocol
NS protocol only provides one way authentication (A  B). You can provide mutual authentication (see next lecture slides for correction)
Talk about Dennig-Sacco Attack on NS: Since the ticket does not contain any timestamp; Eve can replay it in next session. If the key for first session is somehow leaked to Eve  the next session will be compromised too.
6/2/2018
Lecture 4: Crypto, and Security

47. Lecture 4: Crypto, and Email Security
6/2/2018
Session Key Exchange with KDC – Needham-Schroeder Protocol (corrected version with mutual authentication)
A -> KDC: IDA || IDB || N1
(Hello, I am Alice, I want to talk to Bob, I need a session Key and here is a random nonce identifying this request)
KDC -> A: E KA( K || IDB || N1 || E KB(TS1, K || IDA))
Encrypted(Here is a key, for you to talk to Bob as per your request N1 and also an envelope to Bob containing the same key)
A -> B: E K(TS2), E KB(TS1, K || IDA)
(I would like to talk using key in envelope sent by KDC; here is an authenticator)
B -> A: E K(TS2+1)
(OK Alice, here is a proof that I am really Bob)
6/2/2018
Lecture 4: Crypto, and Security

48. Lecture 4: Crypto, and Email Security
6/2/2018
Some questions
Can a KDC learn communication between Alice and Bob, to whom it issued keys?
Can OTP make for a good MAC?
Can H(K||m) make for a good MAC?
Does HMAC provide non-repudiation?
6/2/2018
Lecture 4: Crypto, and Security

49. Lecture 4: Crypto, and Email Security
6/2/2018
Key Distribution
Cryptographic primitives seen so far assume
In private key setting: Alice and Bob share a secret key which is unknown to Oscar.
In public key setting: Alice has a “trusted” (or authenticated) copy of Bob’s public key.
But how does this happen in the first place?
Alice and Bob meet and exchange key(s)
Not always practical or possible.
We need key distribution, first and foremost!
Idea: make use of a trusted third party (TTP)
6/2/2018
Lecture 4: Crypto, and Security

50. Public Key Distribution
6/2/2018
Public Key Distribution
Public announcements (such as )
Can be forged
Public directory
Can be tampered with
Public-key certification authority (CA) (such as verisign)
This is what we use in practice
CA issues certificates to the users
6/2/2018
Lecture 4: Crypto, and Security

51. Naming and Certificates
6/2/2018
Naming and Certificates
Certification authority’s vouch for the identity of an entity - Distinguished Names (DN).
/O=UAB/OU=CIS/CN=Nitesh Saxena
Although CN may be same, DN is different.
Policies of certification
Authentication policy What level of authentication is required to identify the principal.
Issuance policy Given the identity of principal will the CA issue a certificate?
6/2/2018
Lecture 4: Crypto, and Security

52. Lecture 4: Crypto, and Email Security
6/2/2018
Types of Certificates
CA’s vouch at some level the identity of the principal.
Example – Verisign:
Class 1 – address
Class 2 – Name and address verified through database.
Class 3- Background check.
6/2/2018
Lecture 4: Crypto, and Security

53. Public Key Certificate
6/2/2018
Public Key Certificate
Public Key Certificate – Signed messages specifying a name (identity) and the corresponding public key.
Signed by whom – Certification Authority (CA), an organization that issues public key certificates.
We assume that everyone is in possession of a trusted copy of the CA’s public key.
6/2/2018
Lecture 4: Crypto, and Security

54. Public Key Certificate
6/2/2018
Public Key Certificate
Note: Mechanism of certification and content of certificate, will vary but at the minimum we have verification and contains ID and Public Key.
6/2/2018
Lecture 4: Crypto, and Security

55. Certificate Verification/Validation
6/2/2018
Certificate Verification/Validation
6/2/2018
Lecture 4: Crypto, and Security

56. Certificate Revocation
6/2/2018
Certificate Revocation
CA also needs some mechanism to revoke certificates
Private key compromised.
CA mistake in issuing certificate.
Particular service the certificate grants access to may no longer exist.
CA compromised.
Expiration time solves the problems only partially.
Certification Revocation Lists (CRL) – a list of every certificate that has been revoked but not expired.
CRL’s quickly grow large!
CRL’s distributed periodically.
What about time period between revocation and distribution of CRL?
Other mechanisms
OCSP (online certificate status protocol)
6/2/2018
Lecture 4: Crypto, and Security

57. Lecture 4: Crypto, and Email Security
6/2/2018
X.509
Clearly, there is a need for standardization – X.509.
Originally 1988, revised 93 and 95.
X.509 is part of X.500 series that defines a directory service.
Defines a framework for authentication services by X.500 directory to its users.
Used in S/MIME, IPSEC, SSL etc.
Does not dictate use of specific algorithm (recommends RSA).
6/2/2018
Lecture 4: Crypto, and Security

58. Lecture 4: Crypto, and Email Security
6/2/2018
X.509 Certificate
6/2/2018
Lecture 4: Crypto, and Security

59. Advantages of CA Over KDC
6/2/2018
Advantages of CA Over KDC
CA does not need to be on-line all the time!
CA can be very simple computing device.
If CA crashes, life goes on (except CRL).
Certificates can be stored in an insecure manner!!
Compromised CA cannot decrypt messages.
Scales well.
6/2/2018
Lecture 4: Crypto, and Security

60. Public-key Infrastructure (PKI)
6/2/2018
Public-key Infrastructure (PKI)
Combination of digital certificates, public-key cryptography, and certificate authorities.
A typical enterprise's PKI encompasses
issuance of digital certificates to users and servers
end-user enrollment software
integration with corporate certificate directories
tools for managing, renewing, and revoking certificates; and related services and support
Verisign, Thawte and Entrust – PKI providers.
Your own PKI using Mozilla/Microsoft certificate servers
6/2/2018
Lecture 4: Crypto, and Security

61. Problems with PKI – Private Key
6/2/2018
Problems with PKI – Private Key
Where and how is private key stored?
Host – encrypted with pass phrase
Host – encrypted by OS or application
Smart Card
Assumes secure host or tamper proof smartcard.
6/2/2018
Lecture 4: Crypto, and Security

62. Problems with PKI - Conflicts
6/2/2018
Problems with PKI - Conflicts
X.509, and PGP remain silent on conflicts.
They assume CA’s will ensure that no conflicts arise.
But in practice conflicts may exist –
John A. Smith and John B. Smith may live at the same address.
6/2/2018
Lecture 4: Crypto, and Security

63. Trustworthiness of Issuer
6/2/2018
Trustworthiness of Issuer
A certificate is the binding of an external identity to a cryptographic key and a distinguished name. If the issuer can be fooled, all who rely upon the certificate can be fooled 
How do you trust CA from country XYZ (your favorite prejudice).
6/2/2018
Lecture 4: Crypto, and Security

64. Lecture 4: Crypto, and Email Security
6/2/2018
Further Reading
Stallings Chapter 4
HAC Chapter 12
6/2/2018
Lecture 4: Crypto, and Security

65. Lecture 4: Crypto, and Email Security
6/2/2018
Further Reading
X.509 page
Ten Risks of PKI -
6/2/2018
Lecture 4: Crypto, and Security

66. Lecture 4: Crypto, and Email Security
6/2/2018
Some questions
Can a KDC learn communication between Alice and Bob, to whom it issued keys?
Can a CA learn communication between Alice and Bob, to whom it issued certificates?
What happens if the CA is online all the time?
Alice uses her private key, public key pairs and a CA issued certificate. She learnt that Eve might have leaned her key. What should she do?
6/2/2018
Lecture 4: Crypto, and Security

67. Lecture 4: Crypto, and Email Security
6/2/2018
Some Questions
Sometimes when you access an https web-site, you get a security warning. What is that warning for?
Sometimes when you connect to an SSH server, you get a security warning. What is that warning for?
What is a self-signed certificate?
6/2/2018
Lecture 4: Crypto, and Security