UNIT-3

EMAIL PRIVACY
(PGP & S/MIME)
 Pretty Good Privacy
 Electronic mail is the most heavily used network based
application
 Users expect to be able to, and do, send mail to others
who are connected directly or indirectly to the Internet,
regardless of host operating system or communication
suite.
 With the explosively growing reliance on electronic mail
for every conceivable purpose there grows a demand for
authentication and confidentiality services.
 Two schemes stand out as approaches that are likely to
enjoy wide spread use in the next few years :
PGP Pretty Good Privacy and S/MIME.
 PGP is internally used in a network
 Pretty Good Privacy
 Its is a remarkable phenomenon. Largely the efforts of a
single person, Phil Zimmermann.
 It provides confidentiality and authentication service that
can be used for electronic mail and file storage
applications.
 In essence, Zimmermann has done the following
1 Select the best available cryptographic algorithms as
building blocks
2 Integrated these algorithms into a general purpose
application that is independent of operating system and
processor and that is based on a small set of ease-to-use
commands
3. Made the package and its documentation, including the
source code, freely available via the Internet, Bulletin
Boards, commercial networks such as CompuServe

4. Entered into an agreement with a company (Via crypt,

now Network Associates) to provide fully compatible low
cost commercial version of PGP

PGP has grown explosively and is now widely used.

A number of can be cited for the growth

1 It is available free worldwide in versions that run on a

variety of platforms, including DOS/Windows, UNIX,
Macintosh, and many more. In addition, the commercial
version satisfies users who want to product that comes
with vendor support.
2 It is based on algorithms that have survived extensive
public review and are considered extremely secure.
Specifically the package includes RSA, DES, and Diffie-
Hellman for public key encryption; CAST-128, IDEA and
TDEA for conventional encryption, and SHA-1 for hash
coding.
3 It has a wide range of applicability, from corporations that
wish to select and enforce a standardized scheme for
encrypting files and messages to individuals who wish to
communicate securely with others worldwide over the
Internet and other networks
4 It was not developed by, nor it is controlled by, any
governmental standards organization. For those with an
instinctive distrust of “the establishment”, this makes PGP
attractive
 Notation

Ks = session key used in conventional encryption scheme

KRa = private key of user A, used in public key encryption scheme
KUa = public key of user A, used in public key encryption scheme
EP = public-key encryption
DP = public-key decryption
EC = conventional encryption
DC = conventional decryption
H = Hash function
|| = concatenation
Z = compression using ZIP algorithm
R64 = conversion to radix 64 ASCII Format
 Operational Description
Consists of five services
Ø Authentication
Ø Confidentiality
Ø Compression
Ø E-mail compatibility
Ø Segmentation.
We examine each of this in turn
Function Algorithms Used Description
Digital DSS/SHA or A hash code of a message is
Signature RSA/SHA created using SHA-1. This
DSS = Digital message digest is encrypted
using DSS or RSA with the
Signature
sender’s private key, and
Standard
included with the message
Message CAST or IDEA A message is encrypted using
Encryption or Three-key CAST-128 or IDEA or 3DES with
Triple DES with one-time session key generated
Diffie Hellman by the sender. The session key is
or RSA encrypted using Diffie Hellman or
RSA with the recipient’s public
key, and included with the
message
Function Algorithms Description
Used
Compression ZIP A message may be compressed,
for storage or transmission, using
ZIP.
Email Radix 64 – To provide transparency for email
Compatibility Conversion applications, an encrypted
message may be converted to an
ASCII string using radix-64
conversion

Segmentation - To accommodate maximum size

limitations, PGP performs
segmentation and reassembly
 PGP CRYPTOGRAPHIC FUNCTIONS
S ou r ce A D estin a tion B
E KRa [H(M)]
KU a
KR a
H DP
M || Z Z -1
EP M
Com pare

E KU b [K s ]
( a) Authentication only H

KU b KR b

Ks EP DP

M M
Z EC || DC Z -1

(b) Confidentiality only

E KU b [K s ]
KU b
KR b E KR a [H(M)] KU a
KR a Ks EP
H DP DP
M
EP || Z EC || M
DC Z -1 Com pare

H
(c) Confidentiality and authentication

Figu r e 15.1 P G P C r yp togr ap h ic F u n ction s

 PGP CRYPTOGRAPHIC FUNCTIONS
Sour ce A Destination B
EKRa[H(M)]
KUa
KRa
H DP
M || Z Z-1
EP M
Compare

(a) Authentication only H

Figure 15.1 PGP Cryptographic Functions

1. Message 1. Apply Decompose (Unzip)

2. Applied Hash Function 2. Perform Hash function with
3. Will Generate M. Digest message
4. Encrypted (M.D.) with KRa 3. We get M.D.
(private Key) 4. Decrypt original M.D. by using
5. M.D. concatenated with public key of A. KUa
Message 5. Original M.D. Achieved
6. Apply Zip Algo (Compress) 6. Compare M.D. with 3 if same
authenticated
 PGP CRYPTOGRAPHIC FUNCTIONS
Sour ce A Destination B
E[K ]KU b s

KU b KRb

Ks EP DP

M M
Z EC || DC Z-1

(b) Confidentiality only

1. Message, Apply Zip 1. First separate two messages

2. Get compressed file Z 2. Decrypt by using private key of
3. Encrypt by using conventional B so that we will get key Ks
encryption algorithm with Ks 3. Message apply conventional
4. Only Key Ks encrypt with public decryptional with key Ks
key of B kub 4. Now we got one message
5. Apply unzip
5. Append to convention encryption
message and the above message 6. We will get original message
7. This is confidentiality
6. Send message to B
 PGP CRYPTOGRAPHIC FUNCTIONS
Sour ce A Destination B

EKU b[Ks]
KUb
EKRa[H(M)] KUa
KRa Ks EP
H DP
M
EP || Z EC || M
DC Compare

H
(c) Confidentiality and authentication

Figur e 15.1 PGP Cr yptogr aphic Functions

 Confidentiality & Authentication
Clubbing Both confidentiality and authentication

 uses both services on same message

 create signature & attach to message
 encrypt both message & signature
 attach RSA encrypted session key
 PGP Operation – Authentication
 sender creates a message

 SHA-1 used to generate 160-bit hash code of message

 hash code is encrypted with RSA using the sender's

private key, and result is attached to message

 receiver uses RSA or DSS with sender's public key to

decrypt and recover hash code

 receiver generates new hash code for message and

compares with decrypted hash code, if match, message
is accepted as authentic
 PGP Operation – Confidentiality
 sender generates message and random 128-bit number
to be used as session key for this message only

 message is encrypted, using CAST-128 / IDEA/3DES

with session key

 session key is encrypted using RSA with recipient's

public key, then attached to message

 receiver uses RSA with its private key to decrypt and

recover session key

 session key is used to decrypt message

PGP Operation – Confidentiality &
Authentication

 uses both services on same message

 create signature & attach to message
 encrypt both message & signature
 attach RSA encrypted session key
 PGP Operation – Compression

 by default PGP compresses message

after signing but before encrypting
 so can store uncompressed message &
signature for later verification
 & because compression is non deterministic
 uses ZIP compression algorithm
 PGP Operation – Email Compatibility
 Clubbing Both confidentiality and authentication
 Use of Radix – 64. It’s a type of encoding
 Email converts files to ASCII. It has pool of 8 bits, 3
characters each total 24 bits. This can be easily
understood by anyone.
 Therefore apply radix 64, where it will chop 8 bits to 6.
Now it will have 6 bits each of 4 chars
 when using PGP will have binary data to send (encrypted
message etc)
 however email 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

6 bit Character 6 bit Character 6 bit Character 6 bit Character
value encoding value encoding value encoding value encoding
0 A 16 Q 32 g 48 w
1 B 17 R 33 h 49 x
2 C 18 S 34 i 50 y
3 D 19 T 35 j 51 z
4 E 20 U 36 k 52 0
5 F 21 V 37 l 53 1
6 G 22 W 38 m 54 2
7 H 23 X 39 n 55 3
8 I 24 Y 40 o 56 4
9 J 25 Z 41 p 57 5
10 K 26 a 42 q 58 6
11 L 27 b 43 r 59 7
12 M 28 c 44 s 60 8
13 N 29 d 45 t 61 9
14 O 30 e 46 u 62 +
15 P 31 f 47 v 63 /
(pad) =

Radix-64 conversion
 Segmentation
 Network has max packet size of 64 KB.

 Suppose you have 1 MB of message. Divide it into 64 KB.

 Here take for ex header length as 2. Therefore packet size

would be 62 KB.

 Divide entire data into 62 kb each i.e., 1024 KB / 62 that many

packets with appended header of 2 KB each.

 Now suppose 100 packets are to send to the sender. If we send

it as it is they will reach randomly but not sorted.

 For sorting we apply each packet with and unique ID.

 So segmentation is done as source side

 And Reassembling is done at destination side.
PGP Operation – Summary
 Explanation
 PGP will use multiple session keys (conventional
keys), and multiple public keys, and also multiple
private keys
 Only key number will be send
 i.e. key id for public keys and private keys would be
there. This is for making more complex
1. For ex . Suppose ID No : 5 is send along with session
key then encrypt session key with public key of B i.e.
Ekub. (Session key : Dynamic Generation of key)
Till this is confidentiality is obtained
 Key Id of sender, Generate Message Digest,
 For more complexity or to confuse the intruder append leading
2 octets of Message Digest
 Then Filename
 Timestamp
 Data
First Encryption
ZIP
Then Encryption with Ks and then
Finally Radix 64
 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
 generated using ANSI X12.17 mode
 uses random inputs taken from previous
uses and from keystroke timing of user
 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
 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 keyed from a hashed passphrase
 PGP Key Management
 rather than relying on certificate authorities
 in PGP every user is own CA
 can sign keys for users they know directly
 forms a “web of trust”
 trust keys have signed
 can trust keys others have signed if have a chain
of signatures to them
 key ring includes trust indicators
 users can also revoke their keys
 S/MIME (Secure/Multipurpose
Internet Mail Extensions)
 Its an extension of RFC 822,
 RFC 822 defines a format for text messages that are
using electronic mail. The overall structure of RFC 822 is
simple.
 A message consists of some number of header lines (the
header) followed by unrestricted text (the body). The
header is separated from the body by a blank line.
 Put differently, a message is ASCII text, and all lines up
to the first blank line are assumed to be header lines
used by the user agent
 Most frequently used keywords are From, To subject,
and date.
 MIME (Multipurpose Internet Mail Extensions)
 MIME is an extension of RFC 822 framework that is
intended to address some of the problems and limitations
of the use of SMTP (simple mail transfer protocol), the
following limitations
1. SMTP cannot transmit executable files or other binary
objects. A number of schemes are in use for converting
binary files into text form
2. SMTP cannot transmit text data that includes national
language characters because these are represented by 8
bit codes with values of 128 decimal or higher, and SMTP
is limited to 7-bit ASCII
3. SMTP Servers may reject mail message over a certain
size
4. SMTP Gateways that translate between ASCII and the
character code EBCDIC do not use a consistent set of
mappings, resulting in translation problems
5. SMTP gateways cannot handle non textual data
 MIME (Multipurpose Internet Mail Extensions)
 MIME is an intended to resolve these problems in a
manner that is compatible with existing RFC 822
implementations.
OVERVIEW
The MIME specification includes the following elements
1. Five new message header fields are defined, which may
be included in an RFC 822 header. These fields provide
information about the body of the message.
2. A number of content formats are defined, thus
standardization representations that support multimedia
electronic mail
3. Transfer encodings are defined that enable the
conversion of any content format into a form that is
protected from alteration by the mail system.
 MIME (Multipurpose Internet Mail Extensions)
The five header fields defined in MIME are as follows
1. MIME VERSION : This must have a parameter value 1.0.
This indicates that the message conforms to RFC 2045,46
2. Content Type : Describes that the data contained in the
body with sufficient details that the receiving user agent
can pick an appropriate agent or mechanism to represent
the data to the user or otherwise deal with the data.
3. Content Transfer Encoding : Indicates the type of
transformation that has been used to represent the body of
the message in a way that is acceptable for mail transport.
4. Content ID : Used to identify MIME entities uniquely in
multiple content
5. Content Description : A text description of the object with
the body, this is useful when the object is not readable
(e.g. audio data)
S/MIME (Secure/Multipurpose
Internet Mail Extensions)
 security enhancement to MIME email
 original Internet RFC822 email was text only
 MIME provided support for varying content
types and multi-part messages
 with encoding of binary data to textual form
 S/MIME added security enhancements
 have S/MIME support in various modern
mail agents: MS Outlook, Netscape etc
 S/MIME Functions
 enveloped data
 encrypted content and associated keys
 signed data
 encoded message + signed digest
 clear-signed data
 cleartext message + encoded signed digest
 signed & enveloped data
 nesting of signed & encrypted entities
 S/MIME Cryptographic
Algorithms
 hash functions: SHA-1 & MD5
 digital signatures: DSS & RSA
 session key encryption: ElGamal & RSA
 message encryption: Triple-DES, RC2/40
and others
 have a procedure to decide which
algorithms to use
 S/MIME Certificate
Processing
 S/MIME uses X.509 v3 certificates
 managed using a hybrid of a strict X.509
CA hierarchy & PGP’s web of trust
 each client has a list of trusted CA’s certs
 and own public/private key pairs & certs
 certificates must be signed by trusted CA’s
 Certificate Authorities
 have several well-known CA’s
 Verisign one of most widely used
 Verisign issues several types of Digital IDs
 with increasing levels of checks & hence trust
 Class Identity Checks Usage
 1name/email check web browsing/email
 2+enroll/addr check email, subs, s/w validate
 3+ID documents e-banking/service access
 Summary
 have considered:
 secure email
 PGP
 S/MIME