Pretty Good Privacy (PGP) Security for Electronic

Most popular network-based application Sending an between two distant sites means that the has to transit dozens of machines on the way Those machines may read and record the message Privacy is thus non-existent by default There are systems for secure s –PGP (Pretty Good Privacy) -S/MIME Secure/Multipurpose Internet Mail Extension

PGP Developed by Phil Zimmerman in Documentation and source code is freely available. The package is independent of operating system and processor. PGP does not rely on the “establishment” and it’s popularity and use have grown extensively since 1995.

PGP Features It is based on the best available crypto algorithms –Considered very strong and secure Mainly used for and file storage applications Independent of governmental organizations Messages are automatically compressed

PGP Components There are five important services in PGP –Authentication (Sign/Verify) –Confidentiality (Encryption/Decryption) –Compression – compatibility –Segmentation and Reassembly The last three are transparent to the user

PGP: Authentication steps Sender: 1.Creates a message 2.Hashes it to 160-bits using SHA1 3.Encrypts the hash code using her private key, forming a signature 4.Attaches the signature to message Receiver: 1.Decrypts attached signature using sender’s public key and recovers hash code 2.Re computes hash code using message and compares with the received hash code’ 3.If they match, accepts the message

M= original message H= hash function | | = concatenation (join) Z= compression Z -1 = decompression EP= public key encryption DP= public key decryption KR a = A’s private key KU a = A’s public key Stallings, Fig 5.1a Encryption on hash code to get signature Sig + M

PGP: Confidentiality Sender: 1. Generates message and a random number (session key) only for this message 2. Encrypts message with the session key using AES, 3DES, 3. Encrypts session key itself with recipient’s public key using RSA 4.Attaches it to message Receiver: 1.Recovers session key by decrypting using his private key 2.Decrypts message using the session key.

PGP Confidentiality 1.Alice wishes to send Bob a confidential message m. 2.Alice generates a random session key k for a symmetric cryptosystem. 4.Alice encrypts the message m with the session key k to get ciphertext c c=sk.encrypt k (m)

4. Alice encrypts k using Bob’s public key B e to get k’ = pk.encrypt Be (k) 5.Alice sends Bob the values (k’,c) 6.Bob receives the values (k’,c) and decrypts k’ using his private key B d to obtain k k=pk.decrypt Bd (k’)

7.Bob uses the session key k to decrypt the ciphertext c and recover the message m m=sk.decrypt k (c) Public and symmetric key cryptosystems are combined in this way to provide security for key exchange and then efficiency for encryption. The session key k is used only to encrypt message m and is not stored for any length of time.

EC= symmetric encryption DC= symmetric decryption K s = session key EP= Public key encryption Stallings, 5.1b

Confidentiality pitfall Note that confidentiality service provides no assurance to the receiver as to the identity of sender (i.e. no authentication) Only provides confidentiality for sender that only the recipient can read the message (and no one else)

Combining authentication and confidentiality in PGP Authentication and confidentiality can be combined –A message can be both signed and encrypted That is called authenticated confidentiality Encryption/Decryption process is “nested” within the process shown for authentication alone See next slide

Format of a classic PGP message Key part contains the key and a key identifier Signature part contains a header, followed by a timestamp, the ID of the sender’s public key that should be used for decrypting the signature hash, some type information to identify the algorithms used (for more flexibility), and the encrypted hash Message part contains a header, the default name of the file if the receiver is saving it on the disk, a message creation timestamp, and the message

PGP Compression Compression is done after signing the hash –Why? –Saves having to compress document every time you wish to verify its signature It is also done before encryption –Why? –To speed up the process (less data to encrypt) –Also improves security Compressed messages are more difficult to cryptanalyze as they have less redundancy

PGP compatibility PGP is designed to be compatible with all systems Makes no assumptions regarding ability to handle attachments etc. –Handles both the simplest system and the most complex system –Output of encryption and compression functions is divided into 6-bit blocks Each block is mapped onto an ASCII Character This is called RADIX-64 encoding Has the side-effect of increasing the size of the data by about 33%

PGP Compatibility Many electronic mail systems can only transmit blocks of ASCII text. This can cause a problem when sending encrypted data since ciphertext blocks might not correspond to ASCII characters which can be transmitted. PGP overcomes this problem by using radix-64 conversion.

Radix-64 conversion 1.The binary input is split into blocks of 24 bits 2.Each 24 is then split into four sets each of 6-bits. 3.Each 6-bit set will then have a value between 0 and (=63). 4.This value is encoded into a printable character.

RADIX-64 encoding

An example Radix-64' is a method of converting binary files into text format. First, it breaks the bit stream of the binary file into bit groups of six. Next, it looks at each group of six as an individual character. It then converts each group of six bits into a text character. For example, `010111' would correspond to a decimal 23 which becomes (by Radix-64 definition) an upper case `X'. Other bit groups would be converted by this chart as well. Once we have converted all six bit characters into a text format, it is ready for transmission via conventional text modes

PGP Segmentation/Reassembly protocols have a maximum allowed size for messages –Like 100 KB –PGP divides messages that are too large into smaller ones –Divide and conquer Reassembly at the receiving end is required before verifying signature or decryption