Pretty Good Privacy
“To PGP or not to PGP? “
Phil Zimmermann
What are we going to do ?

Background & Concept
– Why Is PGP Popular?
– PGP’s algorithms

Operational Description
– Inside look on operations

Key Management
– The problem & Solution

Web Of Trust
Pretty Good Privacy



First released in 1991, developed by Phil Zimmerman, provoked
export control and patent infringement controversy.
PGP provides a confidentiality and authentication service
- can be used for electronic mail and file storage
applications.
Available as plug-in for popular e-mail clients, can also be used
as stand-alone software.
- microsoft exchange
- outlook
Why Is PGP Popular?

Based on well known algorithms - “The main idea”
– These algorithm have survived extensive public review and are considered
extremely secure.
– Integrated these algorithms into a general-purpose application

It is availiable free on a variety of platforms (Windows,
UNIX, Macintosh, etc.)
– Open and free code.

Wide range of applicability from corporations that wish to
select and enforce a standerized secure to individuals

Independent – meaning Not developed or controlled by
governmental or standards organizations
- Based on mutual trust between clients
Operational Description
Actual operations of PGP consist of five services:
• Authentication
–
DSS/SHA or RSA/SHA
• Confidentiality
–
CAST or IDEA or RSA or 3DES
• Compression
–
A message may be compressed, for storage or transmission using
ZIP
• E-mail compatibility
– To provide transparency for e-mail applications, an encrypted
message
may be converted to an ASCII using Radix-64
• Segmentation
–
To accommodate maximum message size limitations.
Authentication/Digital
Signature


Sender creates a message
Sender generates a hash code of the message
- uses SHA-1 algorithm in order to generates 160-bit hash code

Hash code encrypted with RSA (sender’s private key)
- the result is prepended to the message

Receiver recover the hash code
- uses RSA with the sender’s public key
Receiver generates new hash code of the message and
compares the two codes.
If the two match, the message is accepted as authentic.

Note:
- PGP only encryptes the hash-code of the message:
more efficient in running time and in transfer time
Authentication/Digital
signature
Source A
Destination B
Public key
KRb
Private key
KRa
Message
M
H
EP
||
ZIP
DP
UNZIP
Message
Compare
M
H
PGP Signed Message
-----BEGIN PGP SIGNED MESSAGE----Hash: SHA1
This is simply the text of the message.
It has not been encrypted, simply signed
-----BEGIN PGP SIGNATURE----Version: PGPfreeware 6.5.3 for non-commercial use
<http://www.pgp.com>
iEYEARECAAYFAj5Ha6AACgkQ99/KQPj2cRNHsQCffKf64L
wWQMfRIiKUfs6QrokB7twAnR5gDobzGapPgyLKQ0gL
klj1WIIp=gXad
-----END PGP SIGNATURE-----
Confidentiality/Encryption

Sender generates message and also a session key
- The session key is a random 128-bit number to be used as a session
key for this message only

Sender encryptes the message
- Uses CAST-128 (IDEA or 3DES) algorithm with the session key
Sender encryptes the Session key with RSA and prepended to the
message
Receiver decrypt the session key

Receiver decrypt the message with the Session key


- uses RSA with its private key
Note:
- PGP does not simply using RSA to encrypt the message directly.
- Using CAST128 force us to share a key - using public-key algorithm solves the session key
distrinution problem.
- Given “Store-and-forward” nature of e-mail, the use of handshaking to assure that both
sides have the same session key is not practical.
- The use of on-time conventional keys strengthens what is already a strong conventional
encryption approach. only a small amount of plaintext is encrypted with each key and
there is no relationship among keys.
Confidentiality/Encryption
Source A
Destination B
Public key
KUb
Private key
KRb
Session key
Ks
EP
DP
Message
M
ZIP
EC
||
Message
Session key
Ks
M
DC
UNZIP
Message
M
Confidentiality &
Authentication
Source A
Destination B
Public key
KUb
Session key
Ks
Private key
KRa
M
H
EP
Private
key
KRb
Public key
KRb
DP
EP
DP
Session key
Ks
||
ZIP
EC
||
M
DC
Compare
M
UNZIP
H
•PGP first signs the message and then encrypts it:
- more convenient to store a signature with a plaintext version of a
message
- for purposes of third party verification
Compression



Saving space both for e-mail transmission and for file storage
PGP uses ZIP to compress the message
PGP compress the message after applying the signature but before message
encryption:
Signature
Zip
Encryption
• One can store only the uncompressed message with the signature for future
verification. In case the order was opposite:
- it would be necessary either to store a compressed version of the message or to
recompress the message each time when verification is required
• Compression algorithms are different – the algorithm is not deterministic.
- sign after compress will would constrain all PGP implementations to the same
compression algorithm
• Encryption is applied after compression to strengthen cryptographic security
- compressed message has less redundancy than original plaintext
Example of ZIP (LZ77)
Scheme
The brown fox jumped over the brown foxy jumping frog
13
5
26
27
The brown fox jumped over
0b26d13d
y 0b27d5ding frog
•The main assumption is that words and phrases within a text
stream (image patterns I the case of GIF) are likely to be repeated
• When a repetition occurs, the repeated sequence can be replaced by a short one
• Over time, codes are reused to capture new sequences
E-mail Compatibility

When PGP is used, At least part of the block to
be transmitted is encrypted
– The resulting block will consist of a stream of arbitraty 8-bit octets
– Many electronic mail systems only permit the use of blocks consisting
of ASCII text


To provide transparency for e-mail applications,
an encrypted message may be converted to an
ASCII string using radix 64 conversion
The use of Radix-64 expands a message
by 33%
- In fact, the compression should be more than enough to compensate
for the radix-64 expansion
Encoding Binary Data
into Radix-64 Format


The scheme used is radix-64 conversion, which expands the
message by 33%.
Radix-64 blindly converts the input stream to radix-64 format
regardless of content, even if the input happens to be ASCII text.
- certain level of confidentiality - if the message is signed but not
encrypted, the output will be unreadable to the casual observer
Segmentation and
Reassembly

E-mail facilities are often restricted to a maximum
message length
- for example 50,000 octets.



Longer messages must be broken up into segments, which
will be mailed separately.
PGP automatically subdivides a message that is too
large into segments that are small enough to send via
e-mail.
The segmentation is done after all of the other
processing, including the Raidx-64 conversion.
- thus, the session key component and signature component appear only once

The receiver strips off all e-mail headers and
reassemble the block.
Key Requirements

PGP makes use of four types of keys:
- one-time session conventional keys, public keys, private keys ,
passphrase-based conventional keys



Three seperate requirements:
A means of generating unpredictable session keys is needed
Any user may have multiple public-key/private-key pairs
- may wish to change his key pair from time to time
- in order to interact with different groups
- simply to enhance security by limiting tha anount material encrypted with any one key
some means is needed for identifying particular keys

Each PGP entity must maintain data base of:
- a file of its own key pairs
- a file of public keys of correspondents
Session Key Generation


The Problem : generating unpredictable session keys
Session keys are generated using CAST-128 itself:
– This is a PGP specific random number generation
technique
– getting as input:


two 64-bit blocks that are treated as plaintext to be encrypted.
- based on keystroke stream generated by the user
128-bit key
- random input that also combined with previous session key
output from CAST-128.
The result, scrambling of CAST-128, is to produce
a sequence of session keys that is effectively unpredictable
Key Identifiers


The Problem: user may have multiple public-key/privatekey pairs
One simple solution would be to transmit the public key
with the message.
- Would work but an RSA key may be three hundreds of
decimal digits in length (1024 bits)



PGP solution associate a short identifier with each public
key that is unique.
then only the much shorter key ID would need to be
transmitted.
The key ID associated with each public key consists of its
least significant 64 bits
That is the ID of KU is (KU mod 264)
Format of PGP Message
Session Key
Component
Key Id of Recipients Public Key
Session Key
EKUb
Timestamp
Key Id of Senders Public Key
Signature
Leading Two Octets
of Message Digest
Message Digest
Filename
Message
Time Stamp
Data
EKRa
ZIP
Eks
R64
PGP Key Rings

The problem:

The Solution : Keys stored locally in a PGP Key
must maintain a database in order to supports
multiple public/private keys.
Ring – essentially a database of keys.
Two rings:
- Private-key ring: stores the public/private key pairs owned
by that node
- Public-key ring: stores the public keys of other users known
at this node

Private keys stored in encrypted form; decryption key determined by
user-entered passphrase.
Key Rings
Private-Key Ring
Timestamp
Key ID*
Public Key
Encrypted
Private Key
User ID*
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Ti
KUi mod 264
KUi
EH(Pi)[KRi]
User i
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Key Rings
Public-Key Ring
Timestamp
Key
ID*
Public
Key
Owner
Trust
User
ID*
Key
Legitimacy
Signature(s)
Signature
Trust(s)
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Ti
KUi
mod
264
KUi
User
i
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Message Generation
Public-Key ring
Passphase
H
Private-Key ring
IDa
IDb
Select
Encrypted
Private key
Select
DC
Key
ID
Public key
Private key
KRb
KRa
RNG
H
Message
M
Message
digest
EP
Message
Session key
||
Ks
Signature
+ message
EP
EC
Encrypted
Signature
+ message
||
Output
Reception
Passphase
Private-Key ring
Select
Public-Key ring
H
Select
Encrypted
Private key
DC
Private key
Public key
KRb
Receiver's
key ID
Encrypted
Session key
Encrypted
Message +
Signature
KRb
DP
Session key
Ks
DC
Sender’s
Key ID
Encrypte
d
Digest
DP
Compare
Message
H
Public Key Management
Problem


The Problem: A’s key ring contains a public
key attributed to B but that the key is, in
fact, owned by C
Two threats now exist:
• C can send messages to A and fake B’s signature,
so that A will accept the message as coming from
B!
• Any encrypted message from A to B can be read
by C !
Public Key Management
Problem
(cont.)

Possible solutions:
•
•
•
•

Physically get the key from B
Verify a key by telephone
Obtain B’s public key from a mutual trusted individual
Obtains B’s public key from a trusted certifying authority
That would violate PGP’s spirit as an Email security scheme for the masses:
• It should be possible for people to exchange keys
electronically with others whom they have never met and
may not even know
• Every one who uses this scheme trusts the central authority
PGP Key Management



PGP Solution: adopts a different trust model – the
“web of trust”
No centralised authority like a root of trust !
The concept of the web of trust:
• The concept: Individuals sign one another’s public keys and
create an interconnected community of public-key users.
• These “certificates” are stored along with keys in key rings
- A signature testifies that the User ID associated with this public key is
valid
- A signature is formed using the private key of the signer
• PGP computes a trust level for each public key in key ring.
• Users take part in the assignment of the trust level
Trust in Public Key Ring


Each user collects signed keys and stores these in the public- key
ring.
Each entry in the ring has:
- Key legitimacy field
Measures the degree to which this PGP user trusts that the key is valid for its user. The
higher the level of trust, the stronger is the binding of this user ID to this key
- Signature trust field
Measures how far the PGP user trusts the signer to certify public keys. (The key
legitimacy field for an entry derives from the signature trust fields.)
- Owner trust field
Indicates the degree to which this PGP user trusts the key's owner to sign other publickey certificates. PGP doesn't compute this level of trust; the PGP user assigns it. You
can think of a signature trust field as a cached copy of the owner trust field from
another entry.
Trust in Public Key Ring



Key Legitimacy Field (computed by PGP)
Signature Trust Field (copies of OTF)
Owner Trust Field (assigned by the user)
Public-Key Ring
Timestamp
Key
ID*
Public
Key
Owner User
Trust
ID*
Key
Legitimacy
Signature(s)
Signature
Trust(s)
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Ti
KUi KUi
mod
264
Trust
flagi
User
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
i
Trust
flagi
Adding a new public key to
your public-key ring:

Owner trust field:
(signed other keys)
Signature trust field:
(trusts the signer)
key-legitimacy:
(the key is valid for its user)
- If you own the key - ultimate trust is automatically assigned.
- If you don’t own the key - PGP asks the user:
unknown, untrusted, marginally trusted, or completely trusted

PGP searches the public-key ring to see if the author of this signature is among the
known public-key owners.
- If so, the owner trust value for this owner is assigned to the signature trust
field for this signature.
OWNERTRUST
SIGTRUST
- If not, an unknown-user value is assigned.

On the basis of the signature trust fields present in this entry.
- If at least one signature has a value of ultimate trust, then the key legitimacy
value is set to complete
- Otherwise, PGP computes a weighted sum of the trust values.
1/X is given to signatures that are always trusted
1/Y is given to signatures that are usually trusted
X and Y are user-configurable parameters.
PGP Trust Model Example
Revoking Public Keys


When exposure suspects or simply avoiding the use of the same
key for an extended period
The owner issue a key revocation certificate
– Signed by the owner , with the corresponding private key
– Same form of normal signature certificate but includes an indicator
that the purpose of this certificate is to revoke the use of this public
key

The owner should disseminate this certificate as widely and as
quickly as possible opponent
NOTE:
An opponent who has compromised the private-key of an owner
can also issue such a certificate. However, this would deny the
opponent as well as the legitimate owner the use of the public
Key – seems much less likely threat.
Next: S/MIME…
Radix-64
Table
Conversion
Radix-64 Encoding
6-bit
Value
Character
Encoding
6-bit
Value
Character
Encoding
6-bit
Value
Character
Encoding
6-bit
Value
Character
encoding
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
A
B
C
D
E
F
G
H
I
J
K
L
M
N
O
P
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
Q
R
S
T
U
V
W
X
Y
Z
a
b
c
d
e
f
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
g
h
i
j
k
l
m
n
o
p
q
r
s
t
u
v
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
(pad)
w
x
y
z
0
1
2
3
4
5
6
7
8
9
+
/
=