Digital Signatures Dennis Hofheinz (slides based on slides by Bjrn - - PDF document

Digital Signatures

Dennis Hofheinz (slides based on slides by Björn Kaidel and Gunnar Hartung)

Digital Signatures 2020-05-05 1

Outline

More on BLS signatures Programmable Hash Functions Waters’ PHF

Digital Signatures 2020-05-05 2

Recap: pairings

Definition 78 (Pairings): Let G1, G2, GT be groups of prime order p. A pairing is a map e : G1 × G2 → GT with the following properties: 1) Bilinearity: ∀g1, g′

1 ∈ G1, g2, g′ 2 ∈ G2 :

e(g1 · g′

1, g2) = e(g1, g2) · e(g′ 1, g2)

e(g1, g2 · g′

2) = e(g1, g2) · e(g1, g′ 2)

2) Non-degeneracy: e(g1, g2) = GT for any gens. g1, g2 3) e efficiently computable. Note: Here, G1 = G2 (symmetric or “type-1” pairings).

Digital Signatures 2020-05-05 3

Remark/addendum to previous lecture

• Claim: self-bilinear map (GT = G1 = G2) breaks CDH
• Not (completely) trivial
• Given g, gx, gy, compute gxy
• Pairing gives e(gx, gy) = e(g, g)xy = gαxy for fixed α
• Problem: e(g, g) = g (i.e., α = 1) in general
• Solution: (requires group order p = |GT| = |G1| = |G2|)

– Compute gα = e(g, g)

square-and-mult. using e

− →

gαp−3 = gα−2 mod p – Compute e(gαxy, gα−2) = gxy

Digital Signatures 2020-05-05 4

Recap: BLS signatures

Gen(1k) :

• x ← Z∗

p

• pk = (g, gx), sk = x

Sign(sk, m) :

• σ := H(m)x ∈ G

Vfy(pk, m, σ) :

• e(H(m), gx) ?

= e(σ, g) EUF-CMA secure in ROM under CDH assumption

Digital Signatures 2020-05-05 5

BLS: extra properties

Problem:

• U1, ..., UN senders (e.g., in a sensor network)
• Each Ui has their own pki = (g, gxi)

Straightforward (but expensive!) solution:

U1 with (pk1, sk1) → m1, σ1 U2 with (pk2, sk2) → m2, σ2 . . . Un with (pkn, skn) → mn, σn Verifier

∀i : Vfy(pki, mi, σi) ?

= 1 (m1, σ1), ... , (mn, σn)

Digital Signatures 2020-05-05 6

Better solution: aggregable signature scheme

U1 U2 . . . Un aggregator m

1

, σ

1

m2, σ2 . . . m

n

,

σ

n

Verifier

Vfy(pk1, ... , pkn, m1, ... , mn, σAgg) ?

= 1 m1, ... , mn, σAgg

• Algorithm that aggregates signatures
• |σAgg| = |σ|
• Vfy of single aggregated signature more efficient than Vfy of

many single signatures

Digital Signatures 2020-05-05 7

Aggregable signatures

Advantages and (potential) applications:

• Saves bandwidth/storage
• Aggregating signatures more efficient than signing huge

dataset (perhaps over and over again)

• Applications:

– Sensor networks – Secure logging – (Authenticating) databases – . . .

Digital Signatures 2020-05-05 8

BLS: aggregability

• Ui has BLS keypair (pki = (g, gxi), ski = xi)
• Signatures are of the form σi = H(mi)xi
• Aggregator computes

σAgg =

n

• i=1

σi

and sends (m1, ... , mn, σ) to the verifier

• Aggregation is public computation, no secret key necessary

Digital Signatures 2020-05-05 9

BLS: aggregability

σAgg =

n

• i=1

σi

• Verification of aggregated signatures:

e(σAgg, g) ? =

n

• i=1

e(H(mi), gxi).

• Correctness:

e(σAgg, g) = e(σ1, g) · ... · e(σn, g) = e(H(m1)x1, g) · ... · e(H(mn)xn, g) =

n

• i=1

e(H(mi), gxi)

Digital Signatures 2020-05-05 10

BLS: aggregability

• Verification time approximately halved:

– No aggregation: verifying n signatures takes 2n pairing computations – Aggregated: verifying aggregated signature for n messages takes n + 1 pairing computations

• Scheme with aggregation EUF-CMA secure

– . . . according to adapted EUF-CMA definition – Difference: allow aggregated forgery – Generalizes “ordinary” EUF-CMA

Digital Signatures 2020-05-05 11

BLS: batch verification

Problem:

U with (pk, sk) Verifier

∀i : Vfy(pki, mi, σi) ?

= 1 (m1, σ1), ... , (mn, σn)

Solution: batch verification

• σ1, ... , σn signatures for m1, ... , mn
• h = n

i=1 H(mi), σ := n i=1 σi

• Check

e(σ, g) ? = e(h, gx)

• Correctness: as with aggregation
• Only two pairing computations for n signatures

Digital Signatures 2020-05-05 12

Research

• Different forms of aggregation

– Sequential aggregation (→ Waters signatures), full aggregation (BLS), . . . – Reason: weaker forms of aggregation easier to achieve (without RO)

• “Universal aggregators” (aggregation across signature

schemes)

• Fault-tolerant aggregate signatures

– Aggregating an invalid signature (and valid ones) invalidates aggregate – But: sometimes useful to be able to tell which message has invalid signature – → Vfy outputs list of valid signatures

Digital Signatures 2020-05-05 13

Waters signatures

• Pairing-based signature
• EUF-CMA secure under CDH in standard model (w/o ROs)
• Tool: “programmable hash functions” (PHFs)

Note:

• Waters’ paper did not call this “PHFs”
• Abstraction only found later on
• PHFs make presentation more modular

Digital Signatures 2020-05-05 16

Programmable hash functions

Motivation:

• RO proofs use programmability of RO (RSA-FDH, BLS, . . . )
• Problem: ROs do not exist, leads to heuristic arguments
• Goal: imitate necessary programming operations with

standard-model hash function

Digital Signatures 2020-05-05 17

Programmable hash functions

Motivation, closer look:

• In BLS proof: H(m) programmed in reduction so that

– Most of the time, H(m) = gyi for known yi – Once, H(m) = gy for unknown y

• Can be viewed as “partitioning” set of messages m into

– . . . “controlled” m for which Dlog of H(m) is known (to reduction) – . . . “uncontrolled” m for which Dlog of H(m) is not known

• Goal: signature queries m controlled, forgery m∗ uncontrolled

Digital Signatures 2020-05-05 18

Programmable hash functions

• Problem: without random oracle, H fixed in pk
• Hence: want an algebraic object H for which

– Dlog of H(m) computable (using trapdoor) for most m – . . . but for some m, Dlog of H(m) hard even given trapdoor – Hope that all signature queries controlled, forgery uncontrolled

• Problem: “most DLogs known” algebraically hard to achieve

– Intuition: many known DLogs of H(mi) tell you much about the group elements from which H is computed

• Solution: refine what “controlled” means

Digital Signatures 2020-05-05 19

Programmable hash functions

• Solution: refine what “controlled” means
• BLS: “reduction can sign m” ⇔ “m controlled” ⇔

Dlog of H(m) known (to reduction)

• Now: “reduction can sign m” ⇔ “m controlled” ⇔

H(m) = hamgbm for known g, h, am, bm with am = 0

• Also: “CDH can be embedded into m” ⇔ “m uncontrolled” ⇔

H(m) = hamgbm for known g, h, am, bm with am = 0

• g, h, H public, but exponents am, bm only known to reduction
• Reduction can sign if and only if H(m) has h-component
• Requires different signature scheme, suitable H

Digital Signatures 2020-05-05 20

Programmable hash functions

• Let G be a finite cyclic group g, h generators

Intuition:

• Hash function Hκ : {0, 1}ℓ → G
• Two Gen algorithms for H: Gen and TrapGen
• Gen → κ, but TrapGen → (κ, τ) also outputs trapdoor τ
• κ-output by Gen and TrapGen indistinguishable
• Trapdoor allows to represent every H-output as follows:

hamgbm = Hκ(m)

• Besides: exponents am, bm “well-distributed”, so that

– for every κ and all fixed sequences m∗

1, ... , m∗ v , m1, ... , mw

– we have am∗

i = 0 and amj = 0 for all i, j with sufficiently high

probability (over the choice of τ)

Digital Signatures 2020-05-05 21

Programmable hash functions

Def.: A group hash function over a group G consists of two PPT algorithms:

• Gen(1k) → κ (for g ∈ G): key generation
• Eval(κ, m) → Hκ(m) ∈ G: evaluation (deterministic)
• Interesting property of a group hash function: programmability

(next slides)

Digital Signatures 2020-05-05 22

Programmable hash functions

Def.: A group hash function (Gen, Eval) is (v, w, γ)-programmable (for v, w ∈ N, γ ∈ [0, 1]), if there are two PPT algorithms as follows:

• TrapGen(g, h) → (κ, τ): trapdoor key generation
• TrapEval(τ, m) → (am, bm) with

hamgbm = Hκ(m) (deterministic) that fulfill the following two requirements:

• κ from Gen statistically close to κ from TrapGen
• TrapEval has (v, w, γ)-well-distributed outputs (next slide)

A (v, w, γ)-PHF is a (v, w, γ)-programmable group hash function.

Digital Signatures 2020-05-05 23

Programmable hash functions

Well-distributedness condition of TrapEval’s outputs:

• (v, w, γ)-well-distributed (for v, w ∈ N, γ ∈ [0, 1]):

For all

– generators g, h of G, – m∗

1, ... m∗ v ∈ {0, 1}ℓ,

– m1, ... , mw ∈ {0, 1}ℓ (s.t. ∀i, j : m∗

i = mj)

– κ in the range of TrapGen’s first output

we have: Pr

• am∗

i = 0

for i = 1, ... , v

∧

amj = 0 for j = 1, ... , w

• ≥ γ,

where Pr is over τ from (κ, τ) ← TrapGen(g, h) (cond. on κ)

Digital Signatures 2020-05-05 24

Waters’ programmable hash function

Waters’ group hash function:

• Gen(1k): choose u0, ... , uℓ ← G.

κ = (u0, ... , uℓ)

• Eval(κ, m = m1 · · · mℓ): compute

Hκ(m) = u0

ℓ

• i=1

umi

i

(mi ∈ {0, 1}) Theorem: Let q = q(k) be a polynomial. Then, Waters’ group hash function is (1, q, γ)-programmable for γ = 1/O(q

√

k).

Digital Signatures 2020-05-05 26

Waters’ programmable hash function

Proof sketch:

• TrapGen(g, h): choose

ai ∈ Zp suitably, bi ← Zp. Let ui := h

aig bi

for i ∈ {0, ... , ℓ},

κ = (u0, ... , uℓ), τ = (

a0, ... , aℓ, b0, ... , bℓ).

• TrapEval(τ, m = m1 · · · mℓ): compute

am =

• a0 + ℓ

i=1 mi

ai and bm =

• b0 + ℓ

i=1 mi

bi. Then: hamgbm = h

a0

ℓ

• i=1

h

aimi · g b0

ℓ

• i=1

g

bimi = (h a0g b0)

• u0

·

ℓ

• i=1

(h

aig bi) ui mi

= Hκ(m)

Digital Signatures 2020-05-05 27

Waters’ programmable hash function

• Distribution of (real/trapdoor) κ?

– Gen(1k): all ui uniform over G – TrapGen(g, h):

◮

bi uniform over Zp

◮

=

⇒ g

bi uniform over G (g generator!)

◮

=

⇒ ui = h

ai g bi uniform over G

• (v, w, γ)-well-distribution:

– Need to define ai suitably (next slide)

Digital Signatures 2020-05-05 28

Waters’ programmable hash function

Closer look at (1, q, γ)-well-distribution:

• Recall: am =

a0 +

i mi

ai

• Idea: set up all

ai as random walks of length L = O(q2):

• ai =

L

• j=1
• ai,j

for

• ai,j ← {−1, 0, 1}
• Random walks: back at origin after n steps with prob. 1/Θ(√n)
• Hence: 1/Θ(q

√

k) ≤ Pr[am = 0] ≤ 1/Θ(q) for any m

• In fact: Pr[am = 0|am∗ = 0] ≥ 1 − 1/(2q) for any m = m∗
• ⇒ (by union bound:) Pr[∀i : ami = 0|am∗ = 0] ≥ 1/2
• ⇒ Pr[∀i : ami = 0 ∧ am∗ = 0] ≥ 1/O(q

√

k)

Digital Signatures 2020-05-05 29