Chapter 5

Electronic mail
security

1
 Outline
• Pretty good privacy
• S/MIME

2
 Pretty Good Privacy
• Philip R. Zimmerman is the creator
of PGP.
• PGP provides a confidentiality and
authentication service that can be
used for electronic mail and file
storage applications.

3
 Why Is PGP Popular?
• It is availiable free on a variety of
platforms.
• Based on well known algorithms.
• Wide range of applicability
• Not developed or controlled by
governmental or standards
organizations

4
Operational Description
• Consist of five services:
– Authentication
– Confidentiality
– Compression
– E-mail compatibility
– Segmentation

5
6
 Compression
• PGP compresses the message after
applying the signature but before
encryption
• The placement of the compression
algorithm is critical.
• The compression algorithm used is
ZIP (described in appendix 5A)

7
 E-mail Compatibility
• The scheme used is radix-64
conversion (see appendix 5B).
• The use of radix-64 expands the
message by 33%.

8
 Segmentation and
Reassembly
• Often restricted to a maximum
message length of 50,000 octets.
• Longer messages must be broken
up into segments.
• PGP automatically subdivides a
message that is to large.
• The receiver strip of all e-mail
headers and reassemble the block.
9
Sumary of PGP Services
Function Algorithm Used
Digital Signature DSS/ SHA or
RSA/ SHA
Message CAST or I DEA or
Encryption three-key triple DES
with Diffi e-Hellman
or RSA
Compression ZI P
E-mail Radix-64 conversion
Compatibility
Segmentation - 10
11
Format of PGP Message

12
13
14
15
 S/MIME
• Secure/Multipurpose Internet Mail
Extension
• S/MIME will probably emerge as
the industry standard.
• PGP for personal e-mail security

16
 Simple Mail Transfer
Protocol (SMTP, RFC
822)
• SMTP Limitations - Can not transmit, or
has a problem with:
– executable files, or other binary files (jpeg
image)
– “national language” characters (non-ASCII)
– messages over a certain size
– ASCII to EBCDIC translation problems
– lines longer than a certain length (72 to 254
characters)
17
 Header fields in MIME
• MIME-Version: Must be “1.0” -> RFC 2045,
RFC 2046
• Content-Type: More types being added by
developers (application/word)
• Content-Transfer-Encoding: How message
has been encoded (radix-64)
• Content-ID: Unique identifying character
string.
• Content Description: Needed when content
is not readable text (e.g.,mpeg)
18
 S/MIME Functions
• Enveloped Data: Encrypted content
and encrypted session keys for
recipients.
• Signed Data: Message Digest
encrypted with private key of “signer.”
• Clear-Signed Data: Signed but not
encrypted.
• Signed and Enveloped Data: Various
orderings for encrypting and signing.
19
More on Internet Email
Architecture

20
 MIME
Content
Types

(Table is on page 602 in

21
MIME Transfer Encodings

(Table is on page 605 in textbook)

23
 Algorithms Used
• Message Digesting: SHA-1 and MD5
• Digital Signatures: DSS
• Secret-Key Encryption: Triple-DES,
RC2/40 (exportable)
• Public-Private Key Encryption: RSA
with key sizes of 512 and 1024 bits, and
Diffie-Hellman (for session keys).

24
 User Agent Role
• S/MIME uses Public-Key Certificates - X.509
version 3 signed by Certification Authority
• Functions:
– Key Generation - Diffie-Hellman, DSS, and RSA key-
pairs.
– Registration - Public keys must be registered with
X.509 CA.
– Certificate Storage - Local (as in browser
application) for different services.
– Signed and Enveloped Data - Various orderings
for encrypting and signing.
25
DomainKeys Identified Mail
(DKIM)
• Started as an industrial effort but later defined in RFC 6376
– Adopted widely by a range of e-mail providers and Internet
Service Providers (ISPs)
• Basically, signing the emails.
– But not by the sender; but by the sending mail server
– Similarly, the verifier is not the recipient user, but the receiving
mail server.
– So not end-to-end, but between sending MTA and receiving MTA
(or agents on behalf of the MTAs)
• By signing an email,
– The sending domain (via its MTA or its agent) claim responsibility
for the email – it says “my server is sending it”
– Thwarts server-spoofing attacks cryptographically
– But it does not provide any proof about the individual who wrote
the email
• Public-private key pairs belong to the domains
– Public keys are stored as DNS records
• Receiving domain (via its MTA or its agent) verifies the 26
signature before passing the email to the ultimate recipient.
27
28