Cryptography Primer
Kameswari Chebrolu
Department of CSE, IIT Bombay
Outline
● Confidentiality
● Integrity
● Authentication Protocols
– Confirming identity
– Sharing Keys
– Message protection (confidentiality+integrity)
including from replay attacks
● Access control
Background
https://xkcd.com/1323/
Players
● Alice (A) and Bob (B) (lovers)
– In our world: web browser and server
● Eve (E, eavesdropper) (jealous ex)
– Passive attacker who can listen but not modify messages
● Mallory (M, malicious) or Trudy (T, intruder)
– Active attacker who can modify, substitute, replay messages
● Goal: Alice and Bob want to communicate securely in
presence of interlopers like E, M or T
– Securely: Confidentiality, Integrity (Authentication included)
Confidentiality
● Information not available or disclosed to
unauthorized entities
● Solution: Encryption and Decryption
Message (M)
Communication channel
Alice Bob
Eve Both Bob and Eve will receive message
Symmetric Key Algorithms
● Also called Shared key
– Alice and Bob share a key k
– Eve does not know the key but knows the
encryption/decryption algorithm
– E.g. AES (keysize: 128/192/256), 3DES (keysize: 168/112)
C=Ek(M) M = Dk(C)
Ciphertext (C)
Communication channel
????
Alice Bob
Eve
Asymmetric Key Algorithms
● Also called Public-key
– Bob has two keys: one public and one secret
– Bob’s public key (B,pu) is public, both Eve and Alice have
access to this
– Bob keeps private key (B,pr) secret
– Alice encrypts message with Bob’s public key
C=EB,pu(M) Ciphertext (C) M = DB,pr(C)
Communication channel
????
Alice Bob
Eve
● RSA (Rivest–Shamir–Adleman)
● ECC (Elliptic Curve Cryptography)
● Pro: Easier key management, scales better for
large systems
● Cons: Much slower operations than symmetric
Security Level ECC Key Size RSA Key Size
~80-bit 160 bits 1024 bits
~112-bit 224 bits 2048 bits
~128-bit 256 bits 3072 bits
~256-bit 512 bits 15360 bits
Integrity and Authentication
● Integrity (data): Has the data been modified in transit?
– Based on Hashes (SHA-1, SHA-2, SHA-3, MD5)
● Authentication (source): Am I talking with the right person?
● Solutions:
– Based on Shared key algorithms: Message Authentication
Codes (MACs) (e.g. HMAC)
– Based on Asymmetric key algorithm: Digital signatures (e.g.
RSA or ECDSA)
Hashes/Message Digest
● One way function used to
verify message integrity
M1
● Maps arbitrary length H1
message (*)🡪 fixed length M2
H2
M3
string (d)
– h(M) hash of message M;
similar to fingerprint
– No key; algorithm is public!
● E.g. SHA1/2/3; MD4/5
Collisions Possible
– Typical values of d: 128, 160,
256, 512 bits
Message Authentication Codes (MACs)
● Also referred to as keyed hashes
● Provides both Integrity and
Authentication
– M: message, k: secret key shared A B
M, tag
between A and B
– A sends message and tag tag = F(M,k)
V(k,M,tag)
(function of M and k) (=MAC)
= 1 (accept)
– B verifies received message with = 0 (reject)
tag
● Matches, accept (authentic +
untampered)
● No match, reject
(tampered/unauthentic or
corrupted)
MAC vs Hash
● A virus can modify a file and its hash also
(recalculate) → cannot detect tampering
● Virus can modify file but cannot calculate new
MAC since it does not know the secret key
Digital Signatures
● M: message; A_pu: Public key;
A_pr: private key A B
M, Sign
● A sends message and sign
(function of A_pr and M) sign = F(A_pr,M)
V(A_pu,M,S)
● B verifies received message = 1 (accept)
with sign using A_pu = 0 (reject)
– Matches, accept (authentic +
untampered)
– No match, reject
(tampered/unauthentic or
corrupted)
MAC vs Digital Signatures
● Example: Software company releasing periodic
patches; integrity of patches important
– How many keys?
– How to ensure trust? Bind document to author
● Digital Signatures (based on public key systems)
– Scalable
– Easy to verify identity
– Disputes can be resolved by third parties
Outline
● Confidentiality
● Integrity
● Authentication Protocols
– Replay Protection
– Key Distribution
– Basic Mechanism
● Access control
Authentication vs Authorization
Authentication: verify user is really who they claim
to be
Authorization: verify whether a user (after
authentication) is allowed to perform a given
action
Replay Attack
● A→B : Send Ek(M)|MAC(Ek(M)) or EB,pu(M|S)
– M: Transfer 1 Lakh rupees; S: signature
● Replay attack: Attacker snoops and sends same
message again
● B thinks it is valid and acts on it
● Need to preserve originality
Network Authentication Protocols
Goal: Establish a secure channel for communication
between two end devices
● Confirm the identity of the communicating
entities
● Establish shared keys (typically symmetric) to
ensure confidentiality and integrity of subsequent
communication
● Protect all message exchanges against
eavesdropping, tampering, replay attacks
– Preserve timeliness and originality of the messages
Identity
● Verify the identity of the communicating parties
via Digital Certificates
● Each party possesses a certificate issued by a
trusted Certificate Authority (CA)
● Parties sign messages (or key exchange values)
using their private key
● Other party verifies the signature using the public
key in the certificate
● Ensures the party is who they claim to be
Digital Certificates
● A trusted entity signs some “data” using its
private key
– Trusted Entity: Certificate Authority (CA)
– Data: public key, public key owner identifier,
expiration time, serial number etc
– Signed document: Digital certificate
Example:
● VeriSign (CA) signs a digital certificate for IITB
using VeriSign’s private key
● Certificate claims www.iitb.ac.in’s public key is
xyz
● IITB can use this certificate to convince users
visiting IITB website that the site is genuine
● User (Browser i.e.) has Verisign’s public key
(hardcoded) and can verify this certificate!
From https://en.wikipedia.org/wiki/Public_key_certificate
Shared Key
● Derive symmetric keys for confidentiality and
integrity
● Diffie-Hellman Key Exchange (DH or ECDH) is
often used
– Compute a shared secret that is never transmitted
→ Forward Secrecy
● Combined with other inputs (e.g. nonces) in a
Key Derivation Function (KDF) → Session keys
– Session Keys used for AES encryption and HMAC
authentication
Ephemeral Diffie Hellman
● Two parties (A and B) agree on:
– A large prime number p
– A generator g (primitive root modulo p)
– These values (p, g) are public
● Exchange:
– A → B: X = g^x mod p, where x is A’s random secret
– B → A: Y = g^y mod p, where y is B’s random secret
– x and y are private and never transmitted
– X and Y are public and can be observed
– Each session uses a new, temporary (ephemeral) DH key pair
● Private key is discarded after session ends
● Even if long-term keys are compromised, past sessions remain
secure.
● Both A and B compute the same shared secret
key:
– A: K = Y^x mod p = g^(xy) mod p
– B: K = X^y mod p = g^(xy) mod p
– Security based on hardness of solving discrete
logarithm problem
● Modern variants use elliptic curves (based on a
similar hardness assumption)
● Subject to Man-in-the-Middle Vulnerability:
– Public values (X, Y) can be intercepted and replaced
● To protect against this:
– Parties digitally sign the respective public values (X
and Y)
– Signatures verified using digital certificates from
trusted authorities.
Protecting Messages
● Nonces (random, one-time values): Ensure
message freshness and resist replay attacks
● Exchanged by both parties during the handshake
● Used to prove liveness and ensure that messages
are not reused
● Note: Also fed into the session key derivation to
guarantee fresh session keys
Pieces
● Symmetric key and asymmetric key based
encryption and data integrity mechanisms
● Digital certificates that involve digital
signatures
● Challenge Response Mechanisms
Typical Message Flow
Client → Server:
• Client Nonce (Nc)
• Client's ephemeral DH public value (Gc)
• Optional: ClientCertificate
Server → Client:
• ServerNonce (Ns)
• Server's ephemeral DH public value (Gs)
• ServerCertificate
• Signature over {Gc, Gs, Nc, Ns} using Server's private key
Client:
- Verifies ServerCertificate and signature
- Optionally sends its own signature if mutual auth is required
● Both Client and Server:
– Derive shared secret
– Use KDF with shared secret + nonces to derive for
the session:
● Symmetric encryption key (e.g., for AES)
● MAC key (e.g., for HMAC)
– Secure channel established
● All communication via above keys → confidentiality and
integrity provided
Outline
● Confidentiality
● Integrity
● Authentication Protocols
– Replay Protection
– Key Distribution
– Basic Mechanism
● Access control
Access Control
● Determines who can access what resources (in
the network) and under what conditions
● Key Goals:
– Protect resources from unauthorized access
– Enforce least privilege
– Provide accountability
Models
● DAC (Discretionary Access Control)
– Owner defines access (e.g., file permissions,
Access Control Lists –ACLs)
– E.g. Linux OS, Firewalls
● MAC (Mandatory Access Control)
– Central authority enforces access based on label
– E.g., military classification
● RBAC (Role-Based Access Control): Access is
based on user roles (e.g., admin, user, guest)
– Most widely used, including in networks
● ABAC (Attribute-Based Access Control): Uses
attributes (e.g., time, location, device type) to
decide access
– Used in modern and cloud networks
– Supports zero trust networks well!
Access Control in Network Security
● Firewalls: Allow/deny traffic based on IP, port,
protocol
● Switch ACLs: Enforce policies at Link Layer
● VPNs: Grant secure access to remote users
● NAC (Network Access Control): Control access
based on device health, credentials
Implementation
● Incoming Request (Packet/Connection
Attempt)
– A user/device sends a packet to a protected
resource (e.g., server, application)
● Policy Enforcement Point (PEP)
– Request hits the PEP — e.g., firewall, VPN
gateway, or switch
– Note: PEP does not make access decisions; it only
enforces them
● Authentication
– If identity is needed (as in VPN, NAC), credentials
are collected
– May involve RADIUS, LDAP, MFA, or digital
certificates
● Forward to Policy Decision Point (PDP)
– PEP sends context (IP, user ID, device info) to the
PDP
– PDP contains the access control rules/policies.
● Policy Evaluation: PDP checks:
– Access control model (DAC, RBAC, ABAC)
– Role or attribute conditions (e.g., time of day, device
compliance)
– Decides to allow/deny, log, redirect
– Decision Returned to PEP
● Enforcement
– PEP allows or blocks the traffic accordingly
● Logging and Auditing
– Result is logged for accountability and forensic
analysis
Summary
