1. Explain Symmetric Key Distribution Using Symmetric Encryption.

For symmetric encryption to work securely, both communicating parties must share the same
secret key. Protecting and distributing these keys becomes difficult as the number of users
increases, since physical exchange does not scale and the number of required keys grows
as N(N−1)/2.

To solve this, systems use Key Distribution Centers (KDCs), which automate key sharing
through a hierarchy of keys:

Key Hierarchy

1.​ Session Keys: Temporary keys used only for a single communication session. They
are discarded once the session ends.
2.​ Master Keys: Long-term keys shared individually between each user and the KDC.
These secure the distribution of session keys.

With this setup, each user needs only one master key (with the KDC), drastically reducing
key-management complexity.

Typical Key Distribution Protocol

1.​ Request: User A asks the KDC for a session key to communicate with User B,
including A’s and B’s identities plus a nonce (N₁) to prevent replay attacks.
2.​ KDC Response: The KDC sends A a message encrypted with A’s master key (Kₐ). It
contains:
○​ The session key (K ) and the original nonce N₁.
○​ A ticket for B, containing K and A’s ID, encrypted with B’s master key (K_b).
3.​ Forwarding: A keeps the session key and forwards B’s ticket. Since it’s encrypted
with K_b, B trusts it came from the KDC.
4.​ Authentication: A and B now share the session key. To ensure freshness, B may
send a nonce (N₂) encrypted with K , and A replies with a function of N₂.

Variations

●​ Hierarchical KDCs: Large networks divide control among multiple KDCs to avoid
bottlenecks and single points of failure.
●​ Decentralized Control: Works only for small networks because each pair of users
must share a master key.
●​ Key Usage Control: Keys can be restricted to specific functions by attaching a
control vector, typically coupled using a hash.

2. Explain Symmetric Key Distribution Using Asymmetric Encryption.

Public-key cryptosystems are inefficient for encrypting large data, so they are mainly used to
securely distribute symmetric keys.

Simple Secret Key Distribution

Merkle’s basic protocol lets two users (A and B) establish a shared session key without a
prior secret:

1.​ Key Setup: A generates a public/private key pair and sends B their ID and public
key.
2.​ Session Key Creation: B generates a session key KsK_sKs​and encrypts it with A’s
public key.
3.​ Recovery: A decrypts using their private key to obtain KsK_sKs​.
4.​ Use & Disposal: Both use KsK_sKs​for secure communication and then discard it.

Weakness: This protocol is vulnerable to man-in-the-middle attacks. An attacker can

replace A’s public key with their own, intercept the session key, and re-encrypt it, making
both parties believe they are secure.

Secret Key Distribution with Authentication

To prevent active attacks, identities must be verified. Assuming A and B already trust each
other’s public keys:

1.​ Initiation: A sends IDAID_AIDA​and nonce N1N_1N1​encrypted with B's public key.
2.​ Verify A: B decrypts and replies with N1N_1N1​and a new nonce N2N_2N2​,
encrypted with A’s public key.
3.​ Verify B: A returns N2N_2N2​encrypted with B’s public key.
4.​ Key Transfer: A generates KsK_sKs​, signs it with A’s private key, then encrypts it
with B’s public key.
5.​ Recovery: B decrypts with their private key and verifies A’s signature to obtain
KsK_sKs​.

This provides both confidentiality and authentication.

Hybrid Scheme

Because public-key operations are computationally heavy, systems often use a hybrid
design:

1.​ Public-Key Layer: Asymmetric encryption distributes long-term master keys

between users and a KDC.
2.​ KDC Layer: The KDC shares a master key with each user.
3.​ Session Layer: The KDC generates and distributes session keys for actual data
encryption.

This reduces the number of expensive asymmetric operations while maintaining security.

Application: S/MIME Email

In S/MIME, encrypted email works without an interactive handshake:

1.​ A random symmetric content-encryption key is generated.

2.​ The email content is encrypted with this key.
3.​ That key is encrypted with the recipient’s public key and attached to the email.
4.​ The recipient uses their private key to recover the symmetric key and decrypt the
message.

This solves key distribution for store-and-forward communication.

3. Discuss the applications of cryptographic Hash functions.

Cryptographic hash functions are highly versatile and used widely across security protocols.
Their main applications include:

1. Message Authentication

Hash functions verify message integrity by ensuring the received data matches what was
sent.

●​ Process: The sender computes a hash (message digest) and sends it with the
message. The receiver recomputes the hash and compares.
●​ Security: To prevent an attacker from altering both the message and the hash, the
hash is often protected using encryption.

2. Message Authentication Codes (MAC)

A MAC is a keyed hash function used when two parties share a secret key.

●​ Mechanism: The MAC function takes the secret key and message to produce a tag.
●​ Benefit: Only someone with the key can generate a valid MAC, providing
authentication without needing to encrypt the entire message.

3. Digital Signatures

Hash functions enable efficient digital signatures.

●​ Process: The sender hashes the message and encrypts the hash with their private
key.
●​ Verification: Anyone with the sender’s public key can verify the decrypted hash
matches the message.
●​ Use Cases: Protocols like S/MIME and DKIM rely on secure hashes (e.g., SHA-256)
for signing messages and email headers.

4. Password Protection
Systems store hashes of passwords instead of the actual passwords.

●​ Verification: The entered password is hashed and compared with the stored hash.
●​ Security: Since hashing is one-way, stolen password files do not reveal actual
passwords.

5. Intrusion & Virus Detection

Hash values detect unauthorized changes to files.

●​ A stored hash H(F)H(F)H(F) is compared with a newly computed one; mismatches

indicate tampering or infection.

6. Pseudorandom Function (PRF) Construction

Hash functions can generate pseudorandom values or keys.

●​ Use: Many systems derive symmetric keys from hash-based PRFs.

●​ TLS: TLS uses HMAC-based PRFs (e.g., with SHA-1/MD5) to expand shared
secrets into key material.

4. Discuss X.509 Formats. How is an X.509 certificate revoked?

The X.509 standard defines the structure of public-key certificates and the authentication
framework used in protocols such as IPsec, SSL/TLS, and S/MIME.

X.509 Certificate Format

An X.509 certificate includes the following core fields:

●​ Version: Indicates format version (1, 2, or 3).

●​ Serial Number: Unique identifier assigned by the CA.
●​ Signature Algorithm: The algorithm used to sign the certificate.
●​ Issuer Name: The CA’s X.500 name.
●​ Validity Period: Start and end dates of certificate validity.
●​ Subject Name: The identity of the certificate owner.
●​ Subject Public Key Info: The public key plus algorithm details.
●​ Signature: CA’s digital signature over all certificate fields.

Version Differences

●​ Version 1: Original basic format.

●​ Version 2: Added optional Issuer and Subject Unique Identifiers (rarely used).
●​ Version 3: Introduced extensions to support extra information like email addresses
and security policies.
Version 3 Extensions

Each extension has an ID, value, and a criticality flag. Extensions fall into three groups:

1.​ Key and Policy Information: Key usage (e.g., signing, encryption), certificate
policies, and private-key usage period.
2.​ Subject & Issuer Attributes: Alternative names (email, URLs) and other directory
attributes.
3.​ Certification Path Constraints: Restrict CA capabilities, limit path length, or prevent
a subject from acting as a CA.

Certificate Revocation

Certificates may be revoked before expiration.

Reasons for Revocation

●​ Private key compromise

●​ Change of status (e.g., user leaves organization)
●​ CA compromise

Revocation Process (CRL)

1.​ CRL Maintenance: Each CA maintains a signed Certificate Revocation List

containing revoked but unexpired certificates.
2.​ CRL Contents: Issuer name, issue date, next update, and a list of serial numbers
with revocation dates.
3.​ Verification: Users check certificates against the CRL. To reduce delays, systems
usually keep cached certificates and CRLs.

5. With a neat diagram explain the transmission and reception of PGP

messages.

PGP provides confidentiality and authentication using both symmetric and asymmetric
cryptography, similar to S/MIME but with different key-distribution and trust mechanics.

Sending PGP Messages

1. Confidentiality

PGP uses hybrid encryption:

●​ The sender generates a one-time session key.

●​ The message is encrypted with this symmetric key.
●​ The session key is then encrypted with the recipient’s public key, so only the
recipient can recover it.

2. Authentication (Digital Signature)

 ●​ A hash of the message is created.
●​ The sender encrypts the hash with their private key to form a digital signature.

3. Key Inclusion

●​ Unlike S/MIME, PGP does not attach the sender’s public key; it must be obtained
separately.

Receiving PGP Messages

1. Public Key Retrieval

Since the sender’s public key is not included, the recipient must fetch it from:

●​ an OpenPGP key server,

●​ a website, or
●​ local storage (if exchanged earlier).

2. Signature Verification

●​ The recipient uses the sender’s public key to decrypt the signature.
●​ They recompute the message hash and compare to verify integrity and origin.

3. Trust Validation (Web-of-Trust)

●​ PGP does not use Certificate Authorities.

●​ Trust depends on whether the sender’s key is signed by people the recipient already
trusts.

4. Decryption

●​ The recipient uses their private key to decrypt the encrypted session key.
●​ The recovered session key decrypts the message content.

6. Discuss PGP cryptographic functions or PGP functions with a neat

diagram.

Pretty Good Privacy (PGP) provides email security through authentication and
confidentiality, similar to S/MIME but with different key-management and certification models.
OpenPGP is the standardized version of the protocol.

1. Cryptographic Key Management

PGP shifts key responsibility to users rather than relying on centralized Certificate
Authorities.

●​ Key Generation: Users create their own public/private OpenPGP key pairs.
●​ Key Certification (Web-of-Trust): Instead of X.509 CAs, PGP uses a decentralized
 trust model. A public key is trusted if it is signed by someone the user already trusts.
Users collect signatures from others to build trust.
●​ Key Distribution: PGP does not attach the sender’s public key to messages.
Recipients must obtain it separately—usually from an OpenPGP key server, a
website, or prior exchange.

2. Encryption and Authentication Algorithms

OpenPGP (RFC 4880) uses standard cryptographic algorithms.

●​ RSA: Used for public-key encryption and key exchange (also referenced in IKE).
●​ Digital Signatures: Used for message authentication and integrity checking.

3. Integration with Other Protocols

PGP is not limited to email.

●​ In IPsec, the Internet Key Exchange (IKE) protocol can carry PGP certificates in its
Certificate payload to exchange public keys.

7. Explain 1) MIME transfer encodings 2) native and canonical form 3)

S/MIME functionality 4) S/MIME messages.

S/MIME secures MIME email by providing authentication, confidentiality, compression, and

compatibility with standard mail systems. It relies on MIME processing rules and the
Cryptographic Message Syntax (CMS).

1. MIME Transfer Encodings

S/MIME encryption produces 8-bit binary data, but many email systems allow only ASCII
text.

●​ To ensure compatibility, S/MIME uses Base64 (Radix-64) encoding, which converts

every 3 bytes of binary data into 4 printable ASCII characters.
●​ Even unsigned plaintext becomes unreadable after Base64 conversion, giving minor
confidentiality.

2. Native vs. Canonical Form

●​ Native Form: The local, system-dependent representation of data (e.g., UNIX text
file, raster image, audio format).
●​ Canonical Form: A standardized representation used during transmission. All
message bodies are converted to canonical form before applying S/MIME security
services. Conversion may involve character-set changes, including file attributes and
record lengths.

3. S/MIME Functionality
S/MIME provides four key services:

• Authentication

●​ Achieved using digital signatures.

●​ The sender hashes the message (e.g., SHA-256) and encrypts the hash with their
private key.
●​ The receiver verifies using the sender’s public key.

• Confidentiality

●​ Ensured through symmetric encryption (commonly AES-128 in CBC mode).

●​ A one-time session key is generated, used to encrypt the message, then encrypted
with the recipient’s public key and attached to the message.

• Compression

●​ Messages may be compressed to save space.

●​ If used, compression must occur before signing to avoid signature breakage.

• Email Compatibility

●​ S/MIME converts encrypted output to Radix-64 to allow transmission through

standard 7-bit email systems.

4. S/MIME Message Types (CMS)

S/MIME uses CMS structures to secure MIME entities:

●​ Data: The raw MIME content.

●​ SignedData: Contains the message, digest algorithm ID, and a SignerInfo block with
the signer’s certificate and encrypted digest.
●​ EnvelopedData: Used for encryption. A session key is generated, encrypted
separately for each recipient, and used to encrypt the message.
●​ CompressedData: For compressed messages.
●​ Clear Signing: Uses multipart/signed format. The message is readable to
non-S/MIME users, with a detached signature in a separate MIME part.

8. Explain the Kerberos Version 4 diagram with message Exchanges.

Kerberos Version 4 uses a trusted Key Distribution Center (KDC) to authenticate clients
without sending passwords over the network. Authentication occurs in three phases, using
tickets and session keys.
Phase 1: Authentication Service (AS) Exchange

Goal: Client obtains a Ticket-Granting Ticket (TGT).

(1) Client → AS

The client sends its ID (IDᶜ), the TGS ID (IDₜ₍g ₎), and a timestamp (TS₁) in plaintext.

(2) AS → Client

The AS looks up the user’s password and creates a session key Kᶜ, ₍gₛ₎ (for client–TGS
communication).​
It replies with a message encrypted using the client’s secret key Kᶜ (derived from the
password). This includes:

●​ The session key Kᶜ,ₜ₍g ₎

●​ TGS ID, timestamps
●​ The TGT, which is encrypted using the TGS’s secret key K ₍gₛ₎

The client can decrypt the outer message but cannot read the TGT; it simply stores it.

Phase 2: Ticket-Granting Service (TGS) Exchange

Goal: Client obtains a Service Ticket for a specific server.

(3) Client → TGS

Client sends:

●​ Service ID (IDᵥ)
 ●​ The TGT
●​ An Authenticator, containing client ID and timestamp, encrypted with Kᶜ, ₍gₛ₎

The TGS decrypts the TGT to retrieve the session key, then validates the Authenticator.

(4) TGS → Client

If valid, the TGS generates a new session key Kᶜ,ᵥ (client ↔ server).​
It sends back:

●​ Kᶜ,ᵥ
●​ Server ID
●​ A Service Ticket, encrypted with the server’s secret key Kᵥ, containing Kᶜ,ᵥ and
client info.

Phase 3: Client/Server Authentication

Goal: Client proves identity to the server using the Service Ticket.

(5) Client → Server

Client sends:

●​ The Service Ticket

●​ A new Authenticator encrypted with Kᶜ,ᵥ

The server decrypts the ticket with Kᵥ, retrieves Kᶜ,ᵥ, and verifies the Authenticator.

(6) Server → Client (Optional)

For mutual authentication, the server returns (TS + 1) encrypted with Kᶜ,ᵥ, proving it is
genuine.