1. Lecture 8 (Chapter 18) Electronic Mail Security Prepared by Dr. Lamiaa M. Elshenawy 1

2.  Pretty Good Privacy  Notation  Operational Description  Cryptographic Keys  S/MIME  RFCs  S/MIME Functions

3.  Pretty Good Privacy (PGP): data encryption/decryption computer program  privacy& authentication data communication  PGP signing, encrypting/decrypting texts, e-mails, files increase the security of e-mail communications  Created by Phil Zimmermann 1991 provides Used in Used for in

4. 1. Available free worldwide (Windows, UNIX, Macintosh) 2. Based on algorithms considered extremely secure  RSA, DSS, and Diffie-Hellman for public-key encryption  CAST-128, IDEA, and 3DES for symmetric encryption  SHA-1 for hash coding 3. Wide range of applicability (encrypting files and messages to individuals who wish to communicate securely) 4. Not developed by, nor controlled by, any governmental or standards organization 5. PGP on an Internet standards track (RFC 3156; MIME Security)

6. Radix-64 is a group of binary- to- text encoding schemes that represent binary data in an ASCII code.

7. NotationDescription KsKs session key used in symmetric encryption scheme PR a private key of user A, used in public-key encryption scheme PU a public key of user A, used in public-key encryption scheme EPpublic-key encryption DPpublic-key decryption ECsymmetric encryption DCsymmetric decryption Hhash function Z Z -1 compression using ZIP algorithm decompression R64conversion to radix 64 ASCII format ││concatenation

8. PGP Cryptographic Functions

9. a: Digital signature service provided by PGP (Authentication) 1. The sender creates a message 2. SHA-1 is used to generate a 160-bit hash code of the message 3. The hash code is encrypted with RSA using the sender’s private key, and the result is prepended to the message 4.The receiver uses RSA with the sender’s public key to decrypt and recover the hash code 5. The receiver generates a new hash code for the message and compares it with the decrypted hash code. If the two match, the message is accepted as authentic

10. b: Confidentiality service provided by PGP 1. The sender generates a message and a random 128-bit number to be used as a session key for this message only 2. The message is encrypted using CAST-128 (or IDEA or 3DES) with the session key 3.The session key is encrypted with RSA using the recipient’s public key and is prepended to the message 4. The receiver uses RSA with its private key to decrypt and recover the session key 5. The session key is used to decrypt the message

11. 1. The sender creates a message 2. The hash code is generated using SHA-1( 160-bit) for the message. 3. The sender signs the message with its own private key, then encrypts the message with a session key 4. The session key is encrypted with the recipient’s public key 5. The receiver uses RSA with the sender’s public key to decrypt and recover the hash code. 6. The receiver generates a new hash code for the message and compares it with the decrypted hash code. If the two match, the message is accepted as authentic. c: Authentication & Confidentiality service provided by PGP

12.  PGP compresses the message save space both for e-mail transmission and file storage  PGP compresses the message after signature but before encryption store uncompressed message together with the signature future verification to for

13. 1. Hashing (SHA-1) Authentication 2. Symmetric-Key cryptography (CAST-128, IDEA, and 3DES) Confidentiality 3. Public- key cryptography (RSA, DSS, and Diffie-Hellman ) Digital Signature 4. Data compression/ Data decompression

14. Transmission and Reception of PGP Messages

15.  On transmission  Signature (If required) is generated using a hash code of uncompressed plaintext  Plaintext (plus signature if present) is compressed  The block (If confidentiality required), is encrypted and prepended with the public-key encrypted symmetric encryption key  The block is converted to radix-64 format  On reception  The incoming block is converted back from radix-64 format to binary  If the message is encrypted, the recipient recovers the session key and decrypts the message  The resulting block is then decompressed  If the message is signed, the recipient recovers the transmitted hash code and compares it to its own calculation of the hash code

16.  S/MIME version of the MIME protocol  supports encryption of messages (RSA technology)  S/MIME is a standard used to include content of various types in a single message  S/MIME IETF standards (RFC 2821 and RFC 2822)  S/MIME RSA Data Security Inc. S/MIME: Secure/Multipurpose Internet Mail Extensions IETF: Internet Engineering Task Force RFC: Request for Comments follow Developed by

17.  MIME SMTP format of mail  messages multiple content, both textual and non-textual (images, audio, or text in different character sets) SMTP: Simple Mail Transfer Protocol extends include

18.  Internet e-mail messages follow the format standards that are defined in RFC 2821/RFC 2822  A message is made up of header fields and a body  A message can be sent without a body (body is optional), but not without a header

20.  Enveloped data  Generate a session key for a symmetric encryption algorithm (RC2/40 or triple DES)  Encrypt the session key with the recipient’s public key (RSA)  Prepare a block known as Recipient Info contains 1. an identifier of the recipient’s public-key certificate 2. an identifier of the algorithm used to encrypt the session key  Encrypt the message content with the session key

21.  Signed data  Select a message digest algorithm (SHA or MD5).  Compute the message digest (hash function) of the content to be signed.  Encrypt the message digest with the signer’s private key.  Prepare a block known as SignerInfo contains 1. Signer’s public key certificate 2. an identifier of the message digest algorithm 3. an identifier of the algorithm used to encrypt the message digest, and the encrypted message digest

22.  Clear-signed data  Digital signature of the content is formed  Digital signature is encoded using base64  Recipients without S/MIME capability can view the message content and cannot verify the signature

23.  Signed and enveloped data  Encrypted data may be signed  Signed data or clear-signed data may be encrypted

25. Thank you for your attention