The School of Electrical Engineeringand Computer Science (EECS)

CS/ECE Network Security

Hash-based Primitives

Credits: Dr. Peng Ning and Dr. Adrian Perrig

Dr. Attila A. Yavuz 1

OSU EECS

One-Time Signatures

• Basis of all digital signatures– Valuable tool to learn the principles

• Still, the fastest and most secure signature schemes!

– Quantum computer resistant!

• Caveat: Impractical for real-life applications

• They can be used as a “support unit”, seldomly

– Offline/online signatures

– Tailoring for application (e.g., smart-grid, vehicular)

OSU EECS

One-Time Signatures

• Use one-way functions without trapdoor• Efficient for signature generation and verification• Caveat: can only use one time• Example: 1-bit one-time signature

– P0, P1 are public values (public key)

– S0, S1 are private values (private key)

S1 P1

S0 P0

S1

S0

P

S0’

S1’

OSU EECS

Lamport’s One-Time Signature• Uses 1-bit signature construction to sign multiple bits

S1

P1

S0

P0

Bit 0 Bit 1 Bit 2 Bit n

S1’

P1’

S0’

P0’

S1’’

P1’’

S0’’

P0’’

S1*

P1*

S0*

P0*

Private values

Private values

Public values…

Sign 0

Sign 1

OSU EECS

Improved Construction I

• Uses 1-bit signature construction to sign multiple bits

S0

P0

Bit 0 Bit 1 Bit 2 Bit n

S0’

P0’

S0’’

P0’’

S0*

P0*

…

c0

p0

c0’

p0’

c0*

p0*

…

Bit 0 Bit 1 Bit log(n)

Sign message Checksum bits: encode# of signature bits = 0

OSU EECS

Improved Construction II

• Lamport signature has high overhead• Goal: reduce size of public and private key• Approach: use one-way hash chains• S1 = F( S0 )

S2 PS3S0 S1Signaturechain

C1 C0C3 C2Checksumchain

P = F( S3 || C0 )

Sig(0) Sig(1) Sig(2) Sig(3)

OSU EECS

Hash to Obtain Random Subset (HORS)

• Merkle-Winternitz Still impractical• BiBa (ancestor of HORS, please read)

– Fast signature verification, but

– Signing cost is high

• HORS goal:– Develop a one-time signature scheme with

– Fast signing and verification

– Still same signature sizes with Merkle-Winternitz

7

OSU EECS

Preliminary: Bijective Function

• Bijective function– Each element of input is mapped onto one and only one

element in output

– Each element of output is mapped onto one and only one element in input

– Intuitively, there is a one-to-one correspondence between elements of the two sets

8

OSU EECS

Bijective Function S

• Let T = {1, 2, …, t}• S is a bijective function that outputs the m-th k-element

subset of T• C(t,k) in total

9

OSU EECS

Initial Scheme: Based on One-way Functions

• Generalization of Bos and Chaum one-time signatures– A distant variant of Lamport OTS!

• Key generation– Generate t numbers of random l-bit values

– Let these be the private key: SK = (s1,…,st)

– Compute the public key PK = (v1,…,vt),

• where vi = f(si) and f() is a one-way function

10

OSU EECS

Signature Generation and Verification

• Chose (t,k) s.t. C(t,k) > 2^b, • Sign a b-bit message m, 1 <m 2^b (if not just hash it)

– Use S to find the m-th k-element subset of T:{i1,…,ik}

– Interpret these elements as integers to chose keys as below:

– The corresponding values (si1,…,sik) are the signature of m

• Verify message m and its signature (s’1,…, s’k) – Use S to find the m-th k-element subset of T:{i1,…,ik}

– Verify f(s’1) = vi1,…, f(s’k) = vik

11

OSU EECS

Efficiency Analysis

• Key generation– Requires t evaluations of the one-way function

– Secret key size = l*t bits

– Public key size = fl*t bits

• fl = length of the one-way function output

• Signature generation– Time to find the m-th k-element subset of T

• Verification– Time to sign + k one-way function operations

12

OSU EECS

Security

• Bijective function S– Each input corresponds to one and only one output

• Thus, each b-bit message m corresponds to a different k-element subset of T– 1 < m <2^b < C(t,k)– Knowing the signature of one message, an attacker

has to invert at least one of the remaining t − k values in the public key to forge another signature

13

OSU EECS

An Option for S

• Algorithm #1: C(t, k) = C(t−1, k−1) + C(t−1, k) – If the last element of T belongs to the subset, choose k−1

elements from the remaining t−1 elements

– Otherwise, choose k elements from the remaining t−1 elements

• Input: (m, t, k)• Steps:• If m < C(t−1, k−1)

– add t to output and recur on (m, k−1, t−1)

• Else– Add nothing to output and recur on (m – C(t−1, k−1), k, t−1)

14

OSU EECS

HORS: Based on Subset-Resilient Functions

• Replace the Bijective function S with a subset-resilient function H– S(m) has exactly k elements

– S fully guarantees that no two distinct messages have the same k-element subset of T

– H(m) has at most k elements

– H guarantees that it is infeasible to find two distinct messages m1 and m2 such that subset of T selected with H

• H(m1) ≠ H(m2), implies the infeasibility of subset via H

•

• Up to r-time signature generation

15

1 1 2( ) ( ) ( ) ( )r rH m H m H m H m

2 1( ) ( )H m H m

OSU EECS

HORS Operations

16

OSU EECS

Influence of HORS

• Time-valid HORS

• Several Variants for HORS:– HORSIC, HORS++, HORSE

– Are they practical? (part of your Take-home)

• Can you extend HORS with other crypto primitives?– One-wayness is not all about hash functions?

– What about modular exponentiation?

– RSA? or DLP/ECDLP? (part of your Take-home)

• A digression with ECDSA (to discuss principles)

• Structure-Free Rapid Authentication (one of future lecture)

17

OSU EECS

One-way Hash Chain• Used for many network security applications

– S/Key (now)– Authenticate data streams (TESLA& EMSS lecture)– Key derivation in crypto schemes (ETA lecture) – Forward-security (BAF, HaSAFSS)– Commitments ( MR-ETA lecture, e-commerce)

• Good for authentication of the hash values

18

Ki=F(Ki+1), F: hash function

K4FK3

FK2FK1

FK0F Kn= RF

Commitment

OSU EECS

Properties of One-way Hash Chain

• Given Ki

– Anybody can compute Kj, where j<i

– It is computationally infeasible to compute Kl, where l > i, if Kl is unknown

– Any Kl disclosed later can be authenticated by verifying if Hl-

i(Ki) = Kl

– Disclosing of Ki+1 or a later value authenticates the owner of the hash chain

19

K4FK3

FK2FK1

FK0F Kn= RF

OSU EECS 20

Using “Disposable” Passwords

• Simple idea: generate a long list of passwords, use each only one time– attacker gains little/no advantage by eavesdropping

on password protocol, or cracking one password

• Disadvantages– storage overhead– users would have to memorize lots of passwords!

• Alternative: the S/Key protocol– based on use of one-way (e.g. hash) function

OSU EECS 21

S/Key Password Generation

1. Alice selects a password x

2. Alice specifies n, the number of passwords to generate

3. Alice’s computer then generates a sequence of passwords– x1 = H(x)

– x2 = H(x1)

– …

– xn = H(xn-1)

x (Password)

x1

H H H H

x2 x3 x4

x

OSU EECS 22

Generation… (cont’d)

4. Alice communicates (securely) to a server the last value in the sequence: xn

• Key feature: no one knowing xi can easily find an xi-1 such that H(xi-1) = xi

– only Alice possesses that information

OSU EECS 23

Authentication Using S/Key

• Assuming server is in possession of xi …

i

xi-1

verifies H(xi-1) = xi

AliceServer

OSU EECS 24

Limitations

• Value of n limits number of passwords– need to periodically regenerate a new chain of

passwords

• Does not authenticate server! Example attack:1. real server sends i to fake server, which is

masquerading as Alice

2. fake server sends i to Alice, who responds with xi-1

3. fake server then presents xi-1 to real server

OSU EECS

Chained Hashes

• More general construction than one-way hash chains

• Useful for authenticating a sequence of data values D0 , D1 , …, DN

• H* authenticates entire chain

DN

DN-1

HN-1

H(DN)

DN-2

HN-2

H( DN-1 || HN-1 )

D0

H0

…

H*

OSU EECS

Merkle Hash Tree

• A binary tree over data values

– For authentication purpose

• The root is the commitment of the Merkle tree

– Known to the verifier.

• Example

– To authenticate k2, send (k2, m3,m01,m47)

– Verify

m07= h(h(m01||h(f(k2)||m3)||m47)

26

m07

m01

m0 m1

k0 k1

m23

m2 m3

k2 k3

m45

m4 m5

k4 k5

m67

m6 m7

k6 k7

m03 m47

m0=f(k0)

m01=h(m0,m1)

m03=h(m01,m23)

m07=h(m03,m47)

OSU EECS

Merkle Hash Tree (Cont’d)

• Hashing at the leaf level is necessary to prevent unnecessary disclosure of data values

• Authentication of the root is necessary to use the tree– Typically done through a digital signature or pre-

distribution

• Limitation– All leaf values must be known ahead of time

27

m07

m01

m0 m1

k0 k1

m23

m2 m3

k2 k3

m45

m4 m5

k4 k5

m67

m6 m7

k6 k7

m03 m47

m0=f(k0)

m01=h(m0,m1)

m03=h(m01,m23)

m07=h(m03,m47)

OSU EECS

Untrusted External Storage

• Problem: how can we store memory of a secure coprocessor in untrusted storage?

• Solution: construct Merkle hash tree over all memory pages

SecureCoprocessor

Small persistentstorage

Mallory’s Storage