sequential aggregate signatures with lazy verification ...goldbe/papers/seqsigskyle.pdftwo prior...

Sequential Aggregate Signatures with Lazy Verification

from Trapdoor Permutations

Kyle Brogle1

Sharon Goldberg2

Leo Reyzin2

1Stanford University; work done while at Boston University 2Boston University

Asiacrypt 2012

Beijing, China

6 December 2012

BU:

18.*.*.* has path

Bob Alice MIT

BU:

18.*.*.* has path

Bob MIT

Bob

Internet Routing between Autonomous Systems (ASes)

BGP

MIT Owns

18.*.*.*

Alice

Bob

Alice:

18.*.*.* has path

MIT

BU:

18.*.*.* has path

Alice MIT Bob:

18.*.*.* has path

Alice MIT

BU

Sign announcements sent

Include announcements you received for the path

Problem: Announcements get big!

BGPSEC

MIT Alice

BU Bob

Alice: (MIT,18.*.*.*)

Alice: (MIT,18.*.*.*)

Bob: (Alice,MIT,18.*.*.*)

Alice: (MIT,18.*.*.*)

BU: (Alice,MIT,18.*.*.*)

BU: (Bob,Alice,MIT,18.*.*.*)

Alice: (MIT,18.*.*.*)


Problem: To verify these signatures, routers need to retrieve and maintain ~40,000 public keys. Hard to do with low latency packet forwarding.

Want to be able to defer verification of signatures time permits (but can’t afford to defer sending announcements) Must be able to sign before verifying.

Lazy Verification

MIT Alice

BU Bob

Alice: (MIT,18.*.*.*)

Alice: (MIT,18.*.*.*)


Alice: (MIT,18.*.*.*)

BU: (Alice,MIT,18.*.*.*)

BU: (Bob,Alice,MIT,18.*.*.*)

Alice: (MIT,18.*.*.*)


Sequential Aggregate Signatures

Based on Pairings over Elliptic Curves

What about an alternative built from TDPs?

All known constructions without

pairings:

• Don’t allow for lazy verification

• Some operations using other

signers’ public keys

• Has desired properties, but would

be nice to have alternative from

different assumptions.

Best known aggregate signature scheme is BGLS [Boneh-Gentry-Lynn-Shacham 03]

m3,

sig3

m2,

sig2

m1,

sig1 [Fischlin-Lehmann-Schröder 11] • Variant of BGLS with stronger

security guarantees.

• Guarantees aren’t needed in BGP,

but are interesting in other contexts.


m3,

sig3

m2,

sig2

m1,

sig1

Sequential Aggregate Sigs can solve the

problem of large announcements

• One signature instead of n

But can Sequential Aggregate Sigs also

Handle lazy verification?

Two prior schemes from TDPs: • By Lysyanskaya-Micali-Reyzin-Shacham (LMRS)

• By Neven

Both require verifying the aggregate-so-far

before signing (no lazy verification), and both

use other signer’s public keys in signing operation.

Goal: Build a scheme from TDPs, removing

requirement for verify before sign to allow

for lazy verification.

• To do so, we will have to let sig grow

by a small amount per signer

(much less than growth in msg length)

Previous Sequential Aggregate Signature Schemes

Going to use RSA as an example for today, but can be done with any TDP.

Hash function H (full RSA domain outputs; “random oracle”).

Public key PK = (n, e). Secret key SK = (n, d).

Full-Domain Hash RSA [Rivest-Shamir-Adleman 78, Bellare-Rogaway 93]

y x RSA1 m H

RSA y

x m H

?

=

Signer:

Verifier:

• y = H (m)

• x = y d mod n

• y = H (m)

• y = x e mod n

?

LMRS Signature Scheme [LMRS 04]

x1 RSA1 y1

m1 PK1 H

RSA1 y2 x2 m2

PK1, H 2

Signer 1:

Signer 2:

• 2 = H (PK1, PK2, m1, m2)

• Verify x1 using PK1, m1

• Check that PK1 specifies permutation

• y2 = 2 x1

• x2 = y2 mod n2 d2

Possible to generate a

malicious PK that doesn’t

specify a permutation.

Prevents Lazy Verification

(Need to verify aggregate-

so-far before you add your

sig)

m1, PK2

Steps for Signer 2:

Signer 2 wants to sign m2

But Signer 1 wants to

get a sig on bad-m2

(Chosen Message Attack)

LMRS Fails Under Lazy Verification

Valid aggregate sig on (m1, bad-m2)

x1 RSA1 m1 PK1 H

x2 RSA1 y2 Signer 2: PK1, PK2

m1, m2 H

2

PK1, PK2 H bad-x1

bad-2

m1, bad-m2

m1, m2

PK1, PK2 H 2

Signer 1:

Neven Signature Scheme [Neven 08]

Hash functions H (short outputs), G (full RSA domain outputs)

Signature has two components: (x, h)

h3

RSA1 y3 m1, m2, m3

3

PK1, PK2, PK3

H G x3

2 m1, m2

PK1,PK2

RSA1 y2

Signer 2:

• 2 = H (PK1, PK2, x1, m1, m2)

• h2=2 h1

• y2 = G(h2) x1

• Verify (x1, h1) using PK1, m1

Signer 3:

No more certified permutations

Without verification, same

“bad-m2” attack works!

Will always work if signer i

knows exactly what goes

into RSA-1 for signer i+1

Need something to be out of

previous signer’s control!

h2 x2

h1 x1

H G

• x2 = y2 mod n2 d2

• h2=2 h1

• 2 = H (PK1, PK2, x1, m1, m2 PK1 m1 , r2)

• Verify (x1, h1) using PK1, m1

Our Scheme [BGR 12]

Hash functions H (short outputs), G (full RSA domain outputs)

Signature has two components: (x, h)

h3

RSA1 y3 3 H G x3

h1

h2

x1

2 H RSA1

y2 x2

G

Signer 2:

Signer 3:

plus an r value per signer

r2

r3

No more verification

necessary…malicious

signer i cannot predict input

to RSA-1 for signer i+1

Lazy Verification Achieved!

• y2 = G(h2) x1

• x2 = y2 mod n2 d2

• Random r2

PK1,PK2

m1, m2

PK1

m1

m1, m2, m3 PK1, PK2, PK3 PK1, PK2,

m1, m2,

)

Note: Security proof improves if r is

pseudorandom; see paper for

interesting combinatorial tricks.

Need for Lazy Verification


Our Scheme

Proof

Benchmarks

Security Proof

Warm Up: Full-Domain-Hash Proof [Bellare-Rogaway 93]

RSA1 y

x m H

Proof logic: if forger F succeeds, we can invert RSA on a given y

H is a random oracle F has to query it answer one query with y

By programming the random oracle H to respond with y, we can

ensure that if the forger succeeds, we will have inverted RSA

on a given y.

F

H

H(m)? y

x = RSA1(y)

y

Reduction sees

all queries to H.

Need to find one

to match to x1.

Note G(h1) = RSAPK1(x1).

This can be used to pair

the two.

Reduction

needs to find x1

Security Proof cont’d

h1 x1

RSA1 y2 x2 m2

r2

2

h2

PK2 G

RSA1 y1 m1

r1

1

PK1 H G

G H

G(h2)?

x1

y2 x2 = RSA1(y2) F

?? H

H(x1,…)? H(…)?

Now we have a

pair of matched

queries, so we’ve

found x1!

Need for Lazy Verification


Our Scheme

Proof

Benchmarks

Implemented our scheme with OpenSSL primitives

Benchmarks computed with software implementations.

Things may look different in hardware.

Benchmarks computed using OpenSSL:

2GB Ram, 2.4GHz Core i3

BLGS benchmark computed with MIRACL crypto library, as OpenSSL did

not have an implementation.

Benchmarks considered were signature length, verify time, and

sign time.

Benchmarks

Signature Length

0

5000

10000

15000

20000

25000

1 2 3 4 5 6 7 8 9 10

Bit

Le

ngt

h

RSA-2048

BGR-2048

ECDSA-256Weaker routers see

longer k => BGR more

efficient

ECDSA shorter

for small k

Average path length

Path length k

BGLS-256

Verify Time

0

5

10

15

20

25

30

1 2 3 4 5 6 7 8 9 10

Tim

e (

ms)

RSA-2048

BGR-2048

ECDSA-256

Average path length

Path length k

BGLS-256

BGLS costs approx 20ms + 6ms per signer

Sign Time

0

10

20

30

40

50

60

70

1 2 3 4 5

Tim

e (

ms)

RSA-2048

BGR-2048

ECDSA-256

BGLS-256

Out Degree


From any TDP (in RO model)

Lazy Verification (In fact, don’t need to know previous signers at all)

Signature grows ~128 bits/signer

• Already have linear growth due to messages, which are on average longer than 128 bytes.

± Speed comparable to RSA (fast verify, slower sign).

Conclusions

sequential aggregate signatures with lazy verification ...goldbe/papers/seqsigskyle.pdftwo prior...

Documents