Cryptography Fundamentals

James Walden

Northern Kentucky University

CSC 666: Secure Software Engineering

Topics1. Cryptography Concepts

2. Public Key Cryptography

3. Man-in-the-Middle Attacks

4. Hash Functions

5. Random Number Generation

CSC 666: Secure Software Engineering

Cryptography Concepts

encrypt decrypt

ciphertext

plaintext

sharedsecret

key

sharedsecret

key

CommunicationchannelSender Recipient

Eve(eavesdropper)

plaintext

Alice Bob

plaintext

Cryptanalysis Threat Models

Ciphertext only: adversary has only ciphertext; goal is to find plaintext, possibly key.

Known plaintext: adversary has ciphertext, corresponding plaintext; goal is to find key.

Chosen plaintext: adversary may supply plaintexts and obtain corresponding ciphertext; goal is to find key.

Kerckhoff’s Principle

Cryptosystem security should only depend on 1. Quality of shared encryption algorithm E2. Secrecy of key K

The best attack against such a system is Exhaustive key search (a/k/a Brute Force) Note that this assumes that all keys are equally

likely to be chosen, i.e. are randomly generated.

Brute Force Attack

Exhaustive search of keyspace by decrypting ciphertext C with all possible keys K.

Must determine if DK(C) is a likely plaintext

Requires some knowledge of format (language, doc type)

For N possible keys, Worst case is N decryptions. Mean case is N/2 decryptions.

Example: DES has 56-bit keys Average time to find key is 255 decryptions.

Is 128 bits enough?

128-bit keyspace permits 2128 keys 340,282,366,920,938,463,463,374,607,431,768,211,456

or 3.4 x 1038 keys

Cracking 1 trillion (1012) keys per second requires 3.4 x 1026 seconds or 1.08 x 1019 years

Cracking 1 trillion keys per second on 1 billion CPUs requires 1.08 x 1010 years = 10.8 billion years

CSC 666: Secure Software Engineering

Stream Ciphers

Features Use encryption algorithm to generate a pseudo-

random stream of bits called keystream. XOR keystream with plaintext bit stream to generate

ciphertext bit stream.

StreamCipher

⊕

=

1 1 0 0

1 0 1 0

0 1 1 0

Plaintext stream

Ciphertext stream

CSC 666: Secure Software Engineering

Block Ciphers

Features Divide message into fixed size blocks. Pad plaintext if it doesn’t fit into blocks. Encrypt each plaintext block with algorithm.

PKCS#7 Padding Padding value = number of bytes appended. Padding verified and removed after decryption.

7 7 7 7 7 7 7

4 4 4 4

Electronic Code Book Mode

Encrypt each block independently. E(block) = Cblock each time block appears

Therefore attacker can build dictionary of blocks.

ECB encryption of bitmap hides colors but image is still discernible.

Cipher Block Chaining Mode

XOR each block with previous ciphertext block. Random initialization vector (IV) used for 1st block.

CBC encryption of bitmap looks random.

Advanced Encryption Standard

AES was winner of open NIST competition (1997-2000) Rijndael, designed by Joan Daemen and Vincent Rijmen.

Published as FIPS 197 in November 2001.

128-bit block cipher

Variable key length: 128-, 192-, or 256-bit keys.

Replacement for DES DES vulnerable to brute force attacks due to 56-bit keys.

Triple DES is very slow.

Symmetric Key Distribution

Requires each pair of communicating parties to share a (separate) secret key.

n (n-1)/2 keys

sharedsecret

sharedsecret

sharedsecret

sharedsecret

sharedsecret

sharedsecret

Public-Key Cryptography

Separate keys for encryption and decryption.

encrypt decrypt

ciphertext

plaintext

Bob’s publickey

Bob’s privatekey

CommunicationchannelSender Recipient

Eve(eavesdropper)

plaintext plaintext

Alice Bob

Public Key Distribution

Only one key is needed for each recipient

n key pairs

private

private private

private

public public

public public

Requirements

1. It must be computationally easy to encipher or decipher a message given the appropriate key.

2. It must be computationally infeasible to derive the private key from the public key.

3. It must be computationally infeasible to determine the private key from a chosen plaintext attack.

One-Way Trapdoor Functions

Trapdoor one-way Function: One-way function whose inverse is easy to calculate only if given a special piece of information.

Example: Prime factoring Easy to calculate product. Difficult to calculate prime factors from product. Easy to calculate one prime factor, given others.

Note: Better attacks than brute force exist. While prime factoring is hard, it’s not as hard as a

brute force search of all keys. 128-bit keys are not sufficient for public keys! Key size required depends on which trapdoor fn used.

Diffie-Hellman Key Exchange

Compute shared key w/o trusted 3rd party.

Based on discrete logarithm problem Given integers n and g and prime number p,

compute k such that n = gk mod p. Solutions known for small p. Computationally infeasible for

large p.

Shared Constants prime modulus p, integer base g ≠ {0, 1, p–1}

Diffie-Hellman Algorithm1. Alice chooses a random private key k

2. Computes public key A = gk mod p and sends to Bob.

3. Bob chooses a random private key k’

4. Computes public key B = gk’ mod p and sends to Alice.

5. Alice computes secret key1. K1 = Bk mod p

6. Bob computes secret key1. K2 = Ak’ mod p

7. Encrypt messages w/ symmetric cipher using K1=K2 as the shared secret key.

Diffie-Hellman Example

Assume p = 53 and g = 17

Alice chooses kAlice = 5Then KAlice = 175 mod 53 = 40

Bob chooses kBob = 7Then KBob = 177 mod 53 = 6

Shared key:Alice computation: KBob

kAlice mod p = 65 mod 53 = 38

Bob computation: KAlicekBob mod p = 407 mod 53 =

38

Diffie-Hellman Activity

Assume p = 51 and g = 19.

Find a student to pair with. Each student picks a random private key. Compute public key with irb.

irb(main):001:0> (19**7).modulo(51)

=> 43

Share your public key with your partner. Compute shared, secret key using irb. Compare shared key with partner. If they match, congratulations! If they don’t, find out what went wrong.

RSA Algorithm

Choose two large prime numbers p, q Let the modular base n = pq. Choose e < n so e is relatively prime to (n). Compute inverse of e, d, as private key.

Public key: (e, n)Private key: dEncipher: c = me mod nDecipher: m = cd mod n

CSC 666: Secure Software Engineering

Man-in-the-Middle Attacks

MITM is an active network attack in which attacker routes packets through his machine, modifying them in the process.

Attacker needs to start with one of these attacks: ARP spoofing DHCP spoofing DNS hijacking or cache poisoning Route hijacking DNS cache poisoning

Then he can modify packets as desired.

ARP Spoofing

Alice Bob

Cracker

gratuitous arp replyBob’s IP→ Cracker’s MAC

arpspoof 192.168.1.10 192.168.1.100

Regular traffic

Using arp poisoning

LAN: 192.168.1.x

.10 .100

CLIENT SERVER

switch

.1

MAC: 00:0A:E4:2E:9B:11

MAC: 00:22:64:34:60:88

gratuitous arp replyAlice’s IP→ Cracker’s MAC

arpspoof 192.168.1.100 192.168.1.10

MAC: 00:0A:E4:3B:47:7E

victim ip victim ipgateway ip gateway ip

Hash Functions

Hash Function h: MMD Input M: variable length message M Output MD: fixed length “Message Digest” of input

Many inputs produce same output (called a collision) Limited number of outputs; infinite number of inputs Avalanche effect: small input change -> big output change

Example (insecure) hash function Sum 32-bit words of message mod 232

Mh

MD=h(M)

MACs for Data Integrity

Given a message M and shared secret key K, Alice computes H(K||M) and sends M and this hash to Bob.

(attack detected)=?

MACh

sharedsecret

key

Communicationchannel

Alice BobMallory(modifying)

MAC6B34339 4C66809 4C66809

message M’

h

sharedsecret

key

87F9024

receivedMAC

computedMAC

message M

Secure Hash Function

A function h = hash(m) must have 3 properties to be secure:1. Pre-image resistance: Given a hash h it should be difficult to

find any message m such that h = hash(m). Functions that lack this property are vulnerable to preimage attacks.

2. Second pre-image resistance: Given an input m1 it should be difficult to find another input m2 such that m1 ≠ m2 and hash(m1) = hash(m2). Functions that lack this property are vulnerable to second-preimage attacks.

3. Collision resistance: It should be difficult to find two different messages m1 and m2 such that hash(m1) = hash(m2). Such a pair is called a cryptographic hash collision. This property is sometimes referred to as strong collision resistance. It requires a hash value at least twice as long as that required for preimage-resistance; otherwise collisions may be found by a birthday attack.

Digital Signatures

Message-Digest Algorithm 5 (MD5)

Developed by Ron Rivest in 1991 Uses 128-bit hash values

Merkle–Damgård construction

Still widely used in legacy applications even

though collision vulnerabilities allow forgery of

digital signatures and SSL certificates.

MD5 Collision Attack History

1. Initial attacks (2004) could only find collisions in files that differed only in last few bytes.

2. Early attacks (2008) used cluster of 200 PS3s for a couple of days.

3. Current attacks can find a collision in seconds on single PC.

Lesson: Cryptanalytic attacks always improve. Change algorithms before they do.

Secure Hash Algorithm (SHA-1)

Developed by NSA; approved federal std by NIST

SHA-0 (1993) and SHA-1 (1995) 160-bit hash values

Merkle–Damgård construction

SHA-1 developed to correct insecurity of SHA-0

SHA-1 still found in legacy applications

Vulnerabilities less severe than those of MD5 Can find SHA-1 collision in 269 operations.

Can find SHA-0 collision in 239 operations.

SHA-2

Developed by NSA; approved federal std by NIST

SHA-2 (2001) 224, 256, 384, or 512-bit hash values

Merkle–Damgård construction

Current recommended hash function for security

applications like digital signatures or SSL certificates.

Cryptanalysts making progress but no breaks Can only find collisions if modify hash algorithm by reducing

number of rounds from 80 (SHA-512) to 46 or 64 (SHA-

256) to 41.

SHA-3

Winner of open NIST competition (2007-2012) Draft standard published in 2014.

Keccak (2012) 224, 256, 384, or 512-bit hash values.

Concerns about NIST changes to 128- and 256-bit values only.

An alternative to SHA-2 Not a replacement as SHA-2 is not broken.

Built on sponge-function instead of Merkle–Damgård

construction like MD5, SHA-1, SHA-2 so that the same

cryptanalytic techniques will not work against SHA-3.

CSC 666: Secure Software Engineering

Random Number Generation

PRNGs are Statistically random, but Predictable. Given same seed, generate same sequence.

CSPRNGs are Statistically random and not predictable. Seed themselves at times with random bits

from hardware (time between keystrokes, hard drive movements, etc.)

Ivy Bridge RNG Added with Ivy Bridge Core iN CPUs in 2012. One RNG per die, not per core. Entropy source is thermal noise.

CSC 482/582: Computer Security

Random Number APIs

Windows rand() – insecure PRNG, uses LCG CryptGenRandom() – CSRNG CryptGenKey() – to securely generate keys

Java java.util.Random – insecure PRNG java.security.SecureRandom – CSRNG Relies on OS, so SecureRandom can fall back

to insecure Random if OS does not provide /dev/random or similar

Key Size and SecurityProtection Symmetric Public

KeyDiffie-Hellman

EllipticCurve

Hash

Short term against small organizations

64 816 816 128 128

Very short term against agencies

80 1248 1248 160 160

Short term against agencies (10 years)

96 1776 1776 192 192

Medium term against agencies (20 years)

112 2432 2432 224 224

Long term protection (30 years)

128 3248 3248 256 256

Long term protection with increased defense against quantum computers.

256 15424 15424 512 512

ECRYPT2 recommendations from www.keylength.com

Key Points

Symmetric cryptography Alice/Bob send confidential data with shared key. 128-bit keys long enough for brute force attacks. Stream (RC4) vs. Block (AES) ciphers.

Public key (asymmetric) cryptography Alice encrypts with Bob’s public key Bob decrypts with Bob’s private key

Secure hash functions Resistance to pre-image, 2nd pre-image, collision Digital signature = Hash + Encrypt w/ Private Key

Keys must be generated with CSPRNGs

CSC 666: Secure Software Engineering

References

1. Brian Chess and Jacob West, Secure Programming with Static Analysis, Addison-Wesley, 2007.

2. David Gourley et. Al., HTTP: The Definitive Guide, O’Reilly, 2002.

3. Dafydd Stuttart and Marcus Pinto, The Web Application Hacker’s Handbook, 2nd Edition, Wiley, 2011.

4. Ivan Ristic, Bulletproof SSL and TLS, Feisty Duck, 2014.

5. Sanctum, “HTTP Response Splitting Whitepaper,” http://www.packetstormsecurity.org/papers/general/whitepaper_httpresponse.pdf, 2004.

6. Michael Zalewski, The Tangled Web: A Guide to Securing Modern Web Applications, No Starch Press, 2011.