sequential aggregate signatures with lazy verification ...goldbe/papers/seqsigskyle.pdftwo prior...
Post on 15-Jul-2020
4 Views
Preview:
TRANSCRIPT
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.*.*.*)
Bob: (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.*.*.*)
Bob: (Alice,MIT,18.*.*.*)
Alice: (MIT,18.*.*.*)
BU: (Alice,MIT,18.*.*.*)
BU: (Bob,Alice,MIT,18.*.*.*)
Alice: (MIT,18.*.*.*)
Bob: (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.
Sequential Aggregate Signatures
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
Sequential Aggregate Signatures
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
Sequential Aggregate Signatures
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
Sequential Aggregate Signatures
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
top related