






Study with the several resources on Docsity
Earn points by helping other students or get them with a premium plan
Prepare for your exams
Study with the several resources on Docsity
Earn points to download
Earn points by helping other students or get them with a premium plan
Community
Ask the community for help and clear up your study doubts
Discover the best universities in your country according to Docsity users
Free resources
Download our free guides on studying techniques, anxiety management strategies, and thesis advice from Docsity tutors
cryptigraphy security issues PGP RSA MAC
Typology: Thesis
1 / 10
This page cannot be seen from the preview
Don't miss anything!
With the explosively growing reliance on electronic mail for every conceivable pur- pose, there grows a demand for authentication and confidentiality services. Two schemes stand out as approaches that enjoy widespread use: Pretty Good Privacy (PGP) and Secure/Multipurpose Internet Mail Extension (S/MIME). The latter is a security en- hancement to the MIME Internet e-mail format standard, based on technology from RSA Data Security. Although both PGP and S/MIME are on an IETF standards track, it appears likely that S/MIME will emerge as the industry standard for commercial and organisational use, while PGP will remain the choice for personal e-mail security for many users. In this course we will only be looking at PGP. S/MIME is discussed in detail in the recommended text.
PGP is a remarkable phenomenon. Largely the effort of a single person, Phil Zimmer- mann, PGP provides a confidentiality and authentication service that can be used for electronic mail and file storage applications. In essence what Zimmermann has done is the following:
From its beginnings about 15 years ago, PGP has grown explosively and is now very widely used. A number of reasons are sited for such growth:
PGP consists of the following five services:
Table 12.1 shows a summary of these services and the algorithms used to implement them. Each service will be discussed in turn and then we will look at the problem of key management.
12.2.1 Authentication
Figure 12.2a illustrates the digital signature service provided by PGP. The figure is similar to ones we have looked at earlier. The hash function used is SHA-1 which creates a 160 bit message digest. EP (DP) represents public encryption (decryption) and the algorithm used can be RSA or DSS (recall that the DSS can only be used for the digital signature function and unlike RSA cannot be used for encryption or key exchange). The message may be compressed using and algorithm called ZIP. This is represented by “Z” in the figure.
The combination of SHA-1 and RSA provides an effective digital signature scheme. Due to the strength of RSA the recipient is assured that only the possessor of the
Figure 12.2: PGP cryptographic functions.
As mentioned before, public key encryption is a lot more computationally intensive than symmetric encryption. For this reason both forms are used as public key encryp- tion solves the key distribution problem. However as will be noticed, the message itself (which is the largest part of the transmission) is encrypted using symmetric key cryptography whereas only the key is encrypted using the public key algorithm.
12.2.3 Confidentiality and Authentication
As figure 12.2c illustrates, both services may be used for the same message. First, a signature is generated for the plaintext message and prepended to the message. 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). This sequence is preferable
to the opposite: encrypting the message and then generating a signature of the en- crypted message. It is generally more convenient to store a signature with a plaintext version of a message. Furthermore, for purposes of third party verification, if the sig- nature is performed first, a third party need not be concerned with the symmetric key when verifying the signature.
12.2.4 Compression
As a default, PGP compresses the message after applying the signature but before encryption. This has the benefit of saving space both for e-mail transmission and for file storage.
The placement of the compression algorithm, indicated by Z for compression and Z−^1 for decompression in figure 12.2 is critical:
(a) It is preferable to sign an uncompressed message so it is free of the need for a compression algorithm for later verification. (b) Different version of PGP produce different compressed forms. Applying the hash function and signature after compression would constrain all PGP implementation to the same version of the compression algorithm.
The compression algorithm used is called ZIP which is described in the recommended text.
12.2.5 E-mail compatibility
Many electronic mail systems only permit the use of blocks consisting of ASCII text. When PGP is used, at least part of the block to be transmitted is encrypted. This ba- sically produces a sequence of arbitrary binary words which some mail systems won’t accept. To accommodate this restriction PGP uses and algorithm known as radix which maps 6 bits of a binary data into and 8 bit ASCII character. Unfortunately this expands the message by 33% however, with the compression algorithm the overall compression will be about one third (in general).
12.2.6 Segmentation
E-mail facilities are often restricted to a maximum message length. For example, many of the facilities accessible throughout the Internet impose a maximum length of 50, octets. Any message longer than that must be broken up into smaller segments, each of which is mailed separately.
PGP makes use of four types of keys:
Three separate requirements can be identified with respect to these keys:
12.3.1 Session key generation
Each session key is associated with a single message and is used only for the purpose of encryption and decrypting that message. Recall that message encryption/decryption is done with a symmetric encryption algorithm. Assuming it is a 128 bit key that is required, the random 128 bit numbers are generated using CAST-128. The input to the random number generator consists of as 128-bit key (this is a random number using the keystroke input from the user) and two 64-bit blocks that are treated as plaintext to be encrypted. Using CFB mode two 64-bit cipher text blocks are produced and concatenated to form the 128 bit session key. The algorithm that is used is based on the one specified in ANSI X12.17.
12.3.2 Key Identifiers
As mentioned it is possible to have more than one public/private key pair per user. Each one therefore needs an ID of some kind. The key ID associated with each public key consists of its least significant 64 bits. That is, the key ID of public key KUa is (KUa mod 2^64 ). This is a sufficient length that the probability of duplicate key IDs is very small. A key ID is also used for the PGP digital signature as the sender may use one of a number of private keys to encrypt the message digest and the recipient must know which one was used.
With the key ID concept understood, a more detailed look at the format of a transmitted message is shown in figure 12.4.
Figure 12.4: General format of PGP message (from A to B).
12.3.3 Key Rings
Key IDs are critical to the operation of PGP. From figure 12.4 it can be seen that two key IDs are included in any PGP message that provides both confidentiality and authentication. These keys need to be stored and organised in a systematic way for efficient and effective use by all parties. The scheme used in PGP is to provide a pair of data structures at each node, one to store the public/private key pairs owned by that node and one to store the public keys of other users known at this node. These data structures are referred to, respectively as the private-key ring and the public key ring. They can be seen in figure 12.5.
We can view the ring as a table where each row represents one of the public/private key pairs owned by this user. Each row contains the following:
A freeware PGP version can be downloaded here (I recommend downloading it and trying it out):
http://www.pgpi.org/products/pgp/versions/freeware/
Figure 12.6: PGP Message generation (from User A to User B; no compression or radix conversion).