DHANALAKSHMI COLLEGE OF ENGINEERING,

CHENNAI

Department of Computer Science and Engineering

CS6701 – Cryptography and Network Security

Anna University 2 & 16 Mark Questions & Answers

Year / Semester: IV / VII

Regulation: 2013

Academic year: 2017 - 2018

UNIT-I

PART A

UNIT-IV SECURITY PRACTICE & SYSTEM SECURITY

1 .Why does PGP generate a signature before applying compression? (A/M-11)

The signature is generated before compression due to 2 reasons:

It is preferable to sign an uncompressed message so that one can store only the

uncompressed message together with the signature for future.

2. Write the four SSL Protocols. (A/M-11)

1. SSL Handshake protocol

2. SSL Change cipher spec. protocol

3. SSL Alert Protocol

4. SSL Record Protocol

3. What is meant by S/MIME? (A/M-12)

S/MIME (Secure/Multipurpose Internet Mail Extensions) is a standard for public

key encryption and signing of MIME data. S/MIME is on an IETF standards track and

defined in a number of documents, most importantly RFCs (3369, 3370, 3850, 3851).

S/MIME was originally developed by RSA Data Security Inc. The original specification

used the IETF MIME specification with the de facto industry standard PKCS secure

message format. Change control to S/MIME has since been vested in the IETF and the

specification is now layered on cryptographic message syntax.

4. What are the services provided by IPSec? (N/D-09)

The services provided by IPSec are authentication, confidentiality and key

management authentication. It ensures the identity of an entity. Confidentiality is protection

of data from unauthorized disclosure. Key management is generation, exchange, storage,

safeguarding, etc. of keys in a public key cryptography.

5. What is meant by replay attack? (A/M-11)

A replay attack (also known as playback attack) is a form of network attack in which

a valid data transmission is maliciously or fraudulently repeated or delayed. This is carried

out either by the originator or by an adversary who intercepts the data and retransmits it,

possibly as part of a masquerade attack by IP packet substitution (such as stream cipher

attack).

6. What is the difference between an SSL connection and SSL session? (M/J-09)

Connection is a transport that provides a suitable type of service. For SSL, such

connections are peer-topeer relationships. The connections are transient. Every connection

is associated with one session. Session: An SSL session is an association between a client

and a server. Sessions are created by the Handshake Protocol. Sessions define a set of

cryptographic security parameters, which can be shared among multiple connections.

Sessions are used to avoid the expensive negotiation of new security parameters for each

connection.

7. Why does ESP include a padding field? (N/D-08)

The ciphertext needs to end on an eight octet boundary because the Authentication

data field is properly aligned in the packet. This is what the protocol expects and if it

doesn't follow the rules, it's considered to contain an error in the packet. It's like English or

other languages. We expect sentences to end with a period so we know where one sentence

ends and the other begins.

8. What is the problem that kerberos addresses? (A/M-12)

The problem that Kerberos addresses is this: Assume an open distributed

environment in which users at workstations wish to access services on servers distributed

throughout the network. We would like for servers to be able to restrict access to

authorized users and to be able to authenticate requests for service. In this environment a

workstation cannot be trusted to identify its users correctly to network services.

9. What is meant by the function of a compression function in a hash function?

The hash function involves repeated use of a compression function. The motivation

is that if the compression function is collision resistant, then the hash function is also

collision resistant function. So a secure hash function can be produced.

10. How is signed data entity of S/MIME prepared?

Secure/Multipurpose Internet Mail Extension is a security enhancement to the

MIME Internet e-mail format standard, based on technology from RSA data security. It is

able to sign and/or encrypt messages.

11. What are the services provided by IPSec?

1. Access control

2. Connectionless integrity

3. Data origin authentication

4. Rejection of replayed packets

12. List out four requirements defined for kerberos. (M/J-09)

The four requirements defined for Kerberos are:

1. Secure: A network eavesdropper should not be able to obtain the necessary

information to impersonate a user. More generally Kerberos should be strong

enough that a potential opponent does not find it to be the weak link.

2. Reliable: For all services that relay on Kerberos for access control, lack of

availability of the supported services. Hence, Kerberos should be highly reliable

and should employ distributed server architecture, with one system able to back

up another.

3. Transparent: Ideally, the user should not be aware that authentication is taking

place, beyond the requirement to enter a password.

4. Scalable: The system should be capable of supporting large numbers of clients

and servers. This suggests a modular, distributed architecture.

13. What are the entities that constitute a full-service kerberos environment?

(N/D-08)

A full service environment consists of a Kerberos server, a number of clients and a

number of application servers.

14. What is the need of segmentation and reassembly function in PGP?

E-mail facilities often are restricted to a maximum message length. To

accommodate this restriction, 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 radix-64 conversion. Thus, the session key component

and signature component appear only once, at the beginning of the first segment.

PART B

1. Explain in detail, the S/MIME capability.

These functions allow for S/MIME capability manipulation of certificates.

These capabilities are an extension to the X.509 standard to accomodate the S/MIME capabilities

that a given message recipient has. They are included in the certificate so the message sender has a

way to know about them (see RFC 4262 and its references for details).

Each capability is a tuple with an unique OID key1 plus a data binary string.

CST_set_capability

int CST_set_capability ( CST * st, const cst_t_seqnum certID, ASN1_OBJECT * oid, unsigned

char * data, int data_length)

Set S/MIME Capability for a given certificate

Parameters

st Pointer to storage structure

certID the certificate ID inside the storage

oid Capability OID

data Capability binary data buffer

data_length Length of data buffer

Returns

Error code.

Errors

CST_ERROR_PARAM_INCORRECT (if storage is NULL)

CST_ERROR_CERT_NOTFOUND

CST_ERROR_DBSTRUCTURE_CORRUPT

CST_ERROR_IO

CST_ERROR_UNDEF_FILE_ERROR

CST_get_capability_data

unsigned char* CST_get_capability_data (CST * st, const cst_t_seqnum certID, ASN1_OBJECT *

oid, int * data_length)

Get S/MIME Capability for given cert

Parameters

st Pointer to storage structure

certID the certificate ID inside the storage

oid Capability OID

data_length Pointer to integer that will receive the length of returned buffer.

Returns

Binary string buffer. User is responsible to free this object using g_free().

Errors

CST_ERROR_PARAM_INCORRECT (if storage is NULL)

CST_ERROR_CERT_NOTFOUND

CST_ERROR_DBSTRUCTURE_CORRUPT

CST_ERROR_IO

CST_ERROR_UNDEF_FILE_ERROR

CST_ERROR_CAPABILITY_NOTFOUND

CST_get_capabilities

CST_STACK_OF_ASN1_OBJECT* CST_get_capabilities (CST * st, const cst_t_seqnum certID)

Get S/MIME Capabilities list for given cert

Parameters

st Pointer to storage structure

certID the certificate ID inside the storage

Returns

Stack of ASN.1 objects with capability tuples. User is responsible to free this object. Do

this by freeing each element in the list with ASN1_OBJECT_free() and then freeing the

stack with sk_ASN1_OBJECT_free().

Errors

CST_ERROR_PARAM_INCORRECT (if storage is NULL)

CST_ERROR_CERT_NOTFOUND

CST_ERROR_DBSTRUCTURE_CORRUPT

CST_ERROR_IO

CST_ERROR_UNDEF_FILE_ERROR

CST_is_capability

int CST_is_capability (CST * st, const cst_t_seqnum certID, ASN1_OBJECT * oid)

Returns TRUE if capability exists

Parameters

st Pointer to storage structure

certID the certificate ID inside the storage

oid Capability OID

Returns

TRUE if capability exists

FALSE if it does not exist, of if some error ocurred. You need to test CST_last_error() to

tell apart.

Errors

CST_ERROR_PARAM_INCORRECT (if storage is NULL)

CST_ERROR_CERT_NOTFOUND

CST_ERROR_DBSTRUCTURE_CORRUPT

CST_ERROR_IO

CST_ERROR_UNDEF_FILE_ERROR

CST_delete_capability

int CST_delete_capability (CST * st, const cst_t_seqnum certID, ASN1_OBJECT * oid)

Delete capabilities

Parameters

st Pointer to storage structure

certID the certificate ID inside the storage

oid Capability OID

Returns

Error code.

Errors

CST_ERROR_PARAM_INCORRECT (if storage is NULL)

CST_ERROR_CERT_NOTFOUND

CST_ERROR_DBSTRUCTURE_CORRUPT

CST_ERROR_IO

CST_ERROR_UNDEF_FILE_ERROR

CST_ERROR_CAPABILITY_NOTFOUND

2.Explain in detail about Kerberos.

Kerberos is a computer network authentication protocol which works on the basis of

'tickets' to allow nodes communicating over a non-secure network to prove their identity to one

another in a secure manner. Its designers aimed it primarily at a client–server model and it

provides mutual authentication—both the user and the server verify each other's identity. Kerberos

protocol messages are protected against eavesdropping and replay attacks.

Kerberos builds on symmetric key cryptography and requires a trusted third party, and

optionally may use public-key cryptography during certain phases of authentication. Kerberos uses

UDP port 88 by default.

Protocol

The client authenticates itself to the Authentication Server (AS) which forwards the

username to a key distribution center (KDC). The KDC issues a ticket-granting ticket (TGT),

which is time stamped, encrypts it using the user's password and returns the encrypted result to the

user's workstation. This is done infrequently, typically at user logon; the TGT expires at some

point, though may be transparently renewed by the user's session manager while they are logged

in.

When the client needs to communicate with another node ("principal" in Kerberos

parlance) the client sends the TGT to the ticket-granting service (TGS), which usually shares the

same host as the KDC. After verifying the TGT is valid and the user is permitted to access the

requested service, the TGS issues a ticket and session keys, which are returned to the client. The

client then sends the ticket to the service server (SS) along with its service request.

User Client-based Logon

1. A user enters a username and password on the client machines. Other credential

mechanisms like pkinit (RFC4556) allow for the use of public keys in place of a password.

2. The client transforms the password into the key of a symmetric cipher. This either uses the

built in key scheduling or a one-way hash depending on the cipher-suite used.

Client Authentication

1. The client sends a cleartext message of the user ID to the AS (Authentication Server)

requesting services on behalf of the user. (Note: Neither the secret key nor the password is

sent to the AS.) The AS generates the secret key by hashing the password of the user found

at the database (e.g., Active Directory in Windows Server).

2. The AS checks to see if the client is in its database. If it is, the AS sends back the following

two messages to the client:

o Message A: Client/TGS Session Key encrypted using the secret key of the

client/user.

o Message B: Ticket-Granting-Ticket (TGT, which includes the client ID, client

network address, ticket validity period, and the client/TGS session key) encrypted

using the secret key of the TGS.

3. Once the client receives messages A and B, it attempts to decrypt message A with the

secret key generated from the password entered by the user. If the user entered password

does not match the password in the AS database, the client's secret key will be different and

thus unable to decrypt message A. With a valid password and secret key the client decrypts

message A to obtain the Client/TGS Session Key. This session key is used for further

communications with the TGS. (Note: The client cannot decrypt Message B, as it is

encrypted using TGS's secret key.) At this point, the client has enough information to

authenticate itself to the TGS.

Client Service Authorization

1. When requesting services, the client sends the following two messages to the TGS:

o Message C: Composed of the TGT from message B and the ID of the requested

service.

o Message D: Authenticator (which is composed of the client ID and the timestamp),

encrypted using the Client/TGS Session Key.

2. Upon receiving messages C and D, the TGS retrieves message B out of message C. It

decrypts message B using the TGS secret key. This gives it the "client/TGS session key".

Using this key, the TGS decrypts message D (Authenticator) and sends the following two

messages to the client:

o Message E: Client-to-server ticket (which includes the client ID, client network

address, validity period and Client/Server Session Key) encrypted using the

service's secret key.

o Message F: Client/Server Session Key encrypted with the Client/TGS Session Key.

Client Service Request

1. Upon receiving messages E and F from TGS, the client has enough information to

authenticate itself to the SS. The client connects to the SS and sends the following two

messages:

o Message E from the previous step (the client-to-server ticket, encrypted using

service's secret key).

o Message G: a new Authenticator, which includes the client ID, timestamp and is

encrypted using Client/Server Session Key.

2. The SS decrypts the ticket using its own secret key to retrieve the Client/Server Session

Key. Using the sessions key, SS decrypts the Authenticator and sends the following

message to the client to confirm its true identity and willingness to serve the client:

o Message H: the timestamp found in client's Authenticator (plus 1 in version 4, but

not necessary in version 5[2][3]

), encrypted using the Client/Server Session Key.

3. The client decrypts the confirmation using the Client/Server Session Key and checks

whether the timestamp is correct. If so, then the client can trust the server and can start

issuing service requests to the server.

4. The server provides the requested services to the client.

3.What are the drawbacks and limitations in Kerberos?

Single point of failure: It requires continuous availability of a central server. When the

Kerberos server is down, new users cannot log in. This can be mitigated by using multiple

Kerberos servers and fallback authentication mechanisms.

Kerberos has strict time requirements, which means the clocks of the involved hosts must

be synchronized within configured limits. The tickets have a time availability period and if

the host clock is not synchronized with the Kerberos server clock, the authentication will

fail. The default configuration per MIT requires that clock times be no more than five

minutes apart. In practice Network Time Protocol daemons are usually used to keep the

host clocks synchronized. Note that some servers (Microsoft's implementation being one of

them) may return a KRB_AP_ERR_SKEW result containing the encrypted server time in

case both clocks have an offset greater than the configured maximum value. In that case,

the client could retry by calculating the time using the provided server time to find the

offset. This behavior is documented in RFC 4430.

The administration protocol is not standardized and differs between server

implementations. Password changes are described in RFC 3244.

In case of symmetric cryptography adoption (Kerberos can work using symmetric or

asymmetric (public-key) cryptography), since all authentications are controlled by a

centralized key distribution center (KDC), compromise of this authentication infrastructure

will allow an attacker to impersonate any user.

Each network service which requires a different host name will need its own set of

Kerberos keys. This complicates virtual hosting and clusters.

Kerberos requires user accounts, user clients and the services on the server to all have a

trusted relationship to the Kerberos token server (All must be in the same Kerberos domain

or in domains that have a trust relationship between each other). Kerberos cannot be used

in scenarios where users want to connect to services from unknown/untrusted clients as in a

typical Internet or cloud computer scenario, where the authentication provider typically

does not have knowledge about the users client system.

The required client trust makes creating staged environments (e.g., separate domains for

test environment, pre-production environment and production environment) difficult:

Either domain trust relationships need to be created that prevent a strict separation of

environment domains or additional user clients need to be provided for each environment.

4. Explain about Secure Sockets Layer (SSL).

. This layer is known as the SSL Record Protocol and it provides basic security

services to various higher layer protocols. An independent protocol that makes use of

the record protocol is the Hypertext Markup Language (HTTP) protocol. Another three

higher level protocols that also make use of this layer are part of the SSL stack. They

are used in the management of SSL exchanges and are as follows:

1. Handshake Protocol.

2. Change Cipher Spec Protocol.

3. Alert Protocol.

Figure 11.1: SSL protocol stack.

The SSL record protocol, which is at a lower layer and offers services to these three

higher level protocols, is discussed first.

SSL Record Protocol

This protocol provides two services for SSL connections:

1. Confidentiality - using conventional encryption.

2. Message Integrity - using a Message Authentication Code (MAC).

In order to operate on data the protocol performs the following actions (see figure

11.2):

• It takes an application message to be transmitted and fragments it into manage-able blocks. These blocks are 2

14 = 16, 384 bytes or less.

• These blocks are then optionally compressed which must be lossless and may

not increase the content length by more than 1024 bytes.

• A message authentication code is then computed over the compressed data using

a shared secret key. This is then appended to the compressed (or plaintext)

block.

• The compressed message plus MAC are then encrypted using symmetric en-

cryption. Encryption may not increase the content length by more than 1024 bytes, so that the total length may not exceed 2

14 + 2048. A number of different

encryption algorithms are permitted.

• The final step is to prepend a header, consisting of the following fields:

SSL Record Protocol Operation.

– Content type (8 bits) - The higher layer protocol used to process the en-

closed fragment.

– Major Version (8 bits) - Indicates major version of SSL in use. For SSLv3,

the value is 3.

– Minor Version (8 bits) - Indicates minor version in use. For SSLv3, the

value is 0.

– Compressed Length (16 bits) - The length in bytes of the compressed (or

plaintext) fragment.

The overall format is shown in figure 11.3.

The “content type” above is one of four types; the three higher level protocols given

above that make use of the SSL record, and a fourth known as “application data”. The

first three are described next as they are SSL specific protocols.

Change Cipher Spec Protocol

This consists of a single message which consists of a single byte with the value 1. This

is used to cause the pending state to be copied into the current state which updates the

cipher suite to be used on this connection.

5.Write about PGP in detail.

• Open source, freely available software package for secure e-mail

• de facto standard for secure email

• developed by Phil Zimmermann

• selected best available crypto algs to use

• Runs on a variety of platforms like Unix, PC, Macintosh and other systems

• originally free (now also have commercial versions available)

PGP Operation – Authentication

1. sender creates message

2. Generates a digital signature for the message

3. use SHA-1 to generate 160-bit hash of message

4. signed hash with RSA using sender's private key, and is attached to message

5. receiver uses RSA with sender's public key to decrypt and recover hash code

6. receiver verifies received message using hash of it and compares with decrypted hash code

PGP Operation – Confidentiality

1. sender generates a message and encrypts it.

2. Generates a128-bit random number as session key

3. Encrypts the message using CAST-128 / IDEA / 3DES in CBC mode with session key

4. session key encrypted using RSA with recipient's public key and attached to the msg

5. receiver uses RSA with private key to decrypt and recover session key

6. session key is used to decrypt message

PGP Operation – Confidentiality & Authentication

• can use both services on the same message

– create signature & attach it to the message

– encrypt both message & signature

– attach RSA/ElGamal encrypted session key

This sequence is preferred because

--one can store the plaintext message/file and its signature

--no need to decrypt the message/file again and again

PGP Operation – Compression

• PGP compresses messages to save space for e-mail transmission and storage

• by default PGP compresses message after signing but before encrypting

– so can store uncompressed message & signature for later verification

– Encryption after compression strengthens security (because compression has less

redundancy)

• uses ZIP compression algorithm

PGP Operation – Email Compatibility

• when using PGP will have binary data (8-bit octets) to send (encrypted message, etc)

• however email was designed only for text

• hence PGP must encode raw binary data into printable ASCII characters

• uses radix-64 algorithm

– maps 3 bytes to 4 printable chars

– also appends a CRC

• PGP also segments messages if too big

PGP Message format:

6. Explain in detail about SET.

• Problem: communicate credit card and purchasing data securely to gain consumer trust

– Authentication of buyer and merchant

– Confidential transmissions

• Systems vary by

– Type of public-key encryption

– Type of symmetric encryption

– Message digest algorithm

– Number of parties having private keys

– Number of parties having certificates

• Developed by Visa and MasterCard

• Designed to protect credit card transactions

• Confidentiality: all messages encrypted

• Trust: all parties must have digital certificates

• Privacy: information made available only when and where necessary

• Provide confidentiality of payment and ordering information

• Ensure the integrity of all transmitted data

• Provide authentication that a cardholder is a legitimate user of a credit card account

• Provide authentication that a merchant can accept credit card transactions through its

relationship with a financial institution

• Ensure the use of the best security practices and system design techniques to protect all

legitimate parties in an electronic commerce transaction

• Create a protocol that neither depends on transport security mechanisms nor prevents their

use

• Facilitate and encourage interoperability among software and network providers

Events required for a Successful SET Transaction

• Customer Opens an account – customer gets a credit card account from, such as a Visa or

MasterCard, with a bank that supports SET.

• The Customer receives a certificate – the customer receives an X.509v3 digital certificate

which is signed by the bank. This certificate verifies the customers public key and it’s

expiration date.

• Merchant Certificates – the merchant must have two(2) certificates for the two public

keys it owns. One for signing messages with and one for key exchange. The merchant also

needs a copy of the payment gateway’s public-key certificate.

• The customer places an order.

• Merchant Verification – The merchant sends an order form to the customer, as well as a

copy of the merchants certificate, so the customer can verify that he/she is dealing with a

valid store.

• Order & Payment Sent – The customer sends order information (OI) and payment

information(PI) to the merchant together with the customers certificate so the merchant can

verify that he is dealing with a valid customer. The PI is encrypted in such a way that the

merchant cannot read it.

• Merchant Requests PI authorization – The merchant forwards the PI to the payment

gateway, to determine whether the customer has sufficient funds/credit for the purchase.

• Merchant Confirms the order – merchant sends confirmation of the order to the

customer.

• Merchant ships goods and services.

• Merchant requests payment – this request for payment is sent to the payment gateway,

which handles payment processing

7. Describe about IP security

have a range of application specific security mechanisms

eg. S/MIME, PGP, Kerberos, SSL/HTTPS

however there are security concerns that cut across protocol layers

would like security implemented by the network for all applications

general IP Security mechanisms

provides

authentication

confidentiality

key management

applicable to use over LANs, across public & private WANs, & for the Internet

need identified in 1994 report

need authentication, encryption in IPv4 & IPv6

Benefits of IPSec

in a firewall/router provides strong security to all traffic crossing the perimeter

in a firewall/router is resistant to bypass

is below transport layer, hence transparent to applications

can be transparent to end users

can provide security for individual users

secures routing architecture

IPSec Services

Access control

Connectionless integrity

Data origin authentication

Rejection of replayed packets

a form of partial sequence integrity

Confidentiality (encryption)

Limited traffic flow confidentiality

Transport Mode

to encrypt & optionally authenticate IP data

can do traffic analysis but is efficient

good for ESP host to host traffic

Tunnel Mode

encrypts entire IP packet

add new header for next hop

no routers on way can examine inner IP header

good for VPNs, gateway to gateway security

Encapsulating Security Payload (ESP)

provides message content confidentiality, data origin authentication, connectionless

integrity, an anti-replay service, limited traffic flow confidentiality

services depend on options selected when establish Security Association (SA), net location

can use a variety of encryption & authentication algorithms

Authentication Header (AH)

• provides support for data integrity & authentication of IP packets

•end system/router can authenticate user/app

•prevents address spoofing attacks by tracking sequence numbers

• based on use of a MAC (message authentication code)

•HMAC-MD5-96 or HMAC-SHA-1-96

•MAC is calculated:

• immutable IP header fields

• AH header (except for Authentication Data field)

• the entire upper-level protocol data (immutable)

• parties must share a secret key

8. List out the participants of SET system and explain in detail.

• Customer Opens an account – customer gets a credit card account from, such as a Visa or

MasterCard, with a bank that supports SET.

• The Customer receives a certificate – the customer receives an X.509v3 digital certificate

which is signed by the bank. This certificate verifies the customers public key and it’s

expiration date.

• Merchant Certificates – the merchant must have two(2) certificates for the two public

keys it owns. One for signing messages with and one for key exchange. The merchant also

needs a copy of the payment gateway’s public-key certificate.

• The customer places an order.

• Merchant Verification – The merchant sends an order form to the customer, as well as a

copy of the merchants certificate, so the customer can verify that he/she is dealing with a

valid store.

• Order & Payment Sent – The customer sends order information (OI) and payment

information(PI) to the merchant together with the customers certificate so the merchant can

verify that he is dealing with a valid customer. The PI is encrypted in such a way that the

merchant cannot read it.

• Merchant Requests PI authorization – The merchant forwards the PI to the payment

gateway, to determine whether the customer has sufficient funds/credit for the purchase.

• Merchant Confirms the order – merchant sends confirmation of the order to the

customer.

• Merchant ships goods and services.

• Merchant requests payment – this request for payment is sent to the payment gateway,

which handles payment processing

9.Describe the SSL architecture, and explain in detail.

SSL connection

a transient, peer-to-peer, communications link

associated with 1 SSL session

SSL session

an association between client & server

created by the Handshake Protocol

define a set of cryptographic parameters

may be shared by multiple SSL connections

SSL Record Protocol Services

confidentiality

using symmetric encryption with a shared secret key defined by Handshake Protocol

AES, IDEA, RC2-40, DES-40, DES, 3DES, Fortezza, RC4-40, RC4-128

message is compressed before encryption

message integrity

using a MAC with shared secret key

similar to HMAC but with different padding

SSL Change Cipher Spec Protocol

one of 3 SSL specific protocols which use the SSL Record protocol

a single message

causes pending state to become current

hence updating the cipher suite in use SSL Alert Protocol

conveys SSL-related alerts to peer entity

severity

• warning or fatal

specific alert

• fatal: unexpected message, bad record mac, decompression failure, handshake failure,

illegal parameter

• warning: close notify, no certificate, bad certificate, unsupported certificate, certificate

revoked, certificate expired, certificate unknown

compressed & encrypted like all SSL data

SSL Handshake Protocol

allows server & client to:

authenticate each other

to negotiate encryption & MAC algorithms

to negotiate cryptographic keys to be used

comprises a series of messages in phases

Establish Security Capabilities

Server Authentication and Key Exchange

Client Authentication and Key Exchange

Finish

10.Explain PGP message generation and reception.