0% found this document useful (0 votes)
17 views13 pages

(Pretty Good Privacy) : Presented By: Sakshi Sharad Kulkarni (1906070) Janhavi Vijay Mali (1906083)

Uploaded by

Shruti Pawar
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
17 views13 pages

(Pretty Good Privacy) : Presented By: Sakshi Sharad Kulkarni (1906070) Janhavi Vijay Mali (1906083)

Uploaded by

Shruti Pawar
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 13

PGP

(PRETTY GOOD PRIVACY)


PRESENTED BY :
SAKSHI SHARAD KULKARNI (1906070)
JANHAVI VIJAY MALI (1906083)
What Is PGP
• One of the protocols to provide security at the application layer is Pretty
Good Privacy (PGP).
• PGP is designed to create authenticated and confidential e-mails.
• PGP is a cryptographic method that lets people communicate privately
online. When you send a message using PGP, the message is converted into
unreadable ciphertext on your device before it passes over the internet. Only
the recipient has the key to convert the text back into the readable message
on their device.
• PGP also authenticates the identity of the sender and verifies that the
message was not tampered with in transit.
History Of PGP
• Philip Zimmermann wrote the initial program. He worked as a
computer security consultant in Boulder, Colorado during the
original days of PGP.
• Other programmers around the world have created subsequent
versions of PGP.
• The newest versions of PGP are created by a California based
corporation called Network Associates, which bought a previous
company, co founded by Zimmermann, called PGP, Inc.
Security Parameters

• Sending an e-mail is a one-time activity. In IPsec or SSL, we assume that the


two parties create a session between themselves and exchange data in both
directions. In e-mail , there is no session.
• The security parameters need to be sent with the message. In PGP, the
sender of the message needs to include the identifiers of the algorithms used
in the message as well as the values of the keys.
Services
• Plaintext: The simplest case is to send the e-mail message in plaintext (no service).
• Message Authentication: Probably the next improvement is to sign the message.
• Compression: A further improvement is to compress the message and digest to make the
packet more compact. This improvement has no security benefit, but it eases the traffic.
• Confidentiality: with One-Time Session Key confidentiality in an e-mail system can be
achieved by using conventional encryption with a one-time session key.
• Code Conversion: Another service provided by PGP is code conversion. Most e-mail
systems allow the message to consist of only ASCII characters. To translate other characters
not in the ASCII set, PGP uses Radix 64 conversion. Each character to be sent (after
encryption) is converted to Radix 64 code.
• Segmentation: PGP allows segmentation of the message after it has been converted to
Radix 64 to make each transmitted unit the uniform size allowed by the underlying e-mail
protocol.
Example
Email Message Message Digest

Sender’s Private Key

Email msg | D. S. Digital Signature

Symmetric Key
Compressed Message

Using Receiver’s
Public key Encrypted o/p

Digital Envelope
Encrypted Symmetric Key
PGP Algorithms
Algorithm ID Description
Public key 1 RSA (encryption or signing)
2 RSA (for encryption only)
3 RSA (for signing only)
17 DSS (for signing)
Hash Algorithm 1 MD5
2 SHA-l
3 RIPE-MD
Encryption 0 No Encryption
1 IDEA
2 Triple DES
9 AES
PGP Keyrings
• In the previous scenarios, we assumed that Alice needed to send a message to only Bob.
That is not always the case. Alice may need to send messages to many people.
• In this case, Alice needs a key ring of public keys, with a key belonging to each person with
whom Alice needs to correspond (send or receive messages).
• Each user needs to have two sets of rings: a ring of private/public keys and a ring of public
keys of other people.
• Each person in the ring can keep more than one public key for each other person.
Two cases may arise.
1. Alice needs to send a message to one of the persons in the community.
a. She uses her private key to sign the digest.
b. She uses the receiver's public key to encrypt a newly created session key.
c. She encrypts the message and signs the digest with the session key created.

2. Alice receives a message from one of the persons in the community.


a. She uses her private key to decrypt the session key.
b. She uses the session key to decrypt the message and digest.
c. She uses her public key to verify the digest.
PGP Certificates

• To trust the owner of the public key, each user in the PGP group needs to
have, implicitly or explicitly, a copy of the certificate of the public-key owner.
• Although the certificate can come from a certificate authority (CA), this
restriction is not required in PGP. PGP has its own certificate system
• In PGP, there is no need for CAs; anyone in the ring can sign a certificate for
anyone else in the ring
• There is no hierarchy of trust in PGP; there is no tree.
• There can be multiple paths in the line of trust from a fully or partially trusted
authority to a certificate.
 Trusts and Legitimacy
• The entire operation of PGP is based on introducer trust, the certificate trust, and the legitimacy of the
public keys.
• PGP allows different levels of trust.
• for simplicity, let us assign three levels of trust to any introducer: none, partial, and full.
• The introducer trust level specifies the trust levels issued by the introducer for other people in the ring.
• The certificate trust level is normally the same as the introducer trust level that issued the certificate.
• There is no mechanism in PGP to determine how to make a decision about the trustworthiness of the
introducer; it is up to the user to make this decision.
 Key Legitimacy
The purpose of using introducer and certificate trusts is to determine the legitimacy of a public key.
The level of the key legitimacy for a user is the weighted trust level of that user.
we assign the following weights to certificate trust levels:
1. A weight of 0 to a nontrusted certificate
2. A weight of to a certificate with partial trust
3. A weight of 1 to a certificate with full trust
 Web of Trust
• If each entity introduces more entities to other entities, the public-key ring for
each entity gets larger and larger and entities in the ring can send secure e-mail to
one another.

 Key Revocation
• It may become necessary for an entity to revoke his or her public key from the ring.
• This may happen if the owner of the key feels that the key is compromised
• To revoke a key, the owner can send a revocation certificate signed by himself The
revocation certificate must be signed by the old key and disseminated to all the
people in the ring who use that public key.

You might also like