Hash-Based Signatures

Hash-Based SignaturesJohannes Buchmann, Andreas HülsungSupported by DFG and DAAD

Part VIII: Authentication Path Generation

Tree Traversal Algorithms

How to Compute Authentication Path Nodes?

TreeHash(Mer89)

TreeHash

TreeHash(v,i): Computes node on level v with leftmost descendant Li

Public Key Generation: Run TreeHash(h,0)

L0 L1 L2 L3 . . . L7

=

h

v = h = 3

v = 2

v = 1

v = 0

TreeHash

TreeHash(v,i)1: Init Stack, N1, N22: For j = i to i+2v-1 do3: N1 = LeafCalc(j)4: While N1.level() == Stack.top().level() do5: N2 = Stack.pop()6: N1 = ComputeParent( N2, N1 )7: Stack.push(N1)8: Return Stack.pop()

TreeHash

Li Li+1 . . . Li+2v-1

TreeHash(v,i)

Efficiency?

Key generation: Every node has to be computed once. cost = 2h leaves + 2h-1 nodes => optimal

Signature: One node on each level 0 <= v < h.cost 2h-1 leaves + 2h-1-h nodes.

Many nodes are computed many times! (e.g. those on level v=h-1 are computed 2h-1 times)

-> Not optimal if state allowed

The BDS Algorithm

Motivation(for all Tree Traversal Algorithms)

No Storage:Signature: Compute one node on each level 0 <= v < h.

Costs: 2h-1 leaf + 2h-1-h node computations.

Example: XMSS with SHA2 and h = 20 ~25min

Store whole tree: 2hn bits.

Example: h=20, n=128; storage: 228bits = 32MB

Idea: Look for time-memory trade-off!

Use a State

Authentication Paths

Observation 1

Same node in authentication path is recomputed many times!Node on level v is recomputed for 2v successive paths.

Idea: Keep authentication path in state.

-> Only have to update “new” nodes.

ResultStorage: h nodesTime: ~ h leaf + h node computations (average)

But: Worst case still 2h-1 leaf + 2h-1-h node computations!-> Keep in mind. To be solved.

Observation 2

When new left node in authentication path is needed, its children have been part of previous authentication paths.

Computing Left Nodes

i

)1( iA )21( 1 viA

v = 2

Result

Storing nodes all left nodes can be computed with one node computation / node

2h

Observation 3

Right child nodes on high levels are most costly.

Computing node on level v requires2v leaf and 2v-1 node computations.

Idea: Store right nodes on top k levels during key generation.

ResultStorage: 2k-2 n bit nodes Time: ~ h-k leaf + h-k node computations (average)

Still: Worst case 2h-k-1 leaf + 2h-k-1-(h-k) node computations!

Distribute Computation

Intuition

Observation: For every second signature only one leaf computation Average runtime: ~ h-k leaf + h-k node computations

Idea: Distribute computation to achieve average runtime in worst case.

Focus on distributing computation of leaves

TreeHash with Updates

TreeHash.init(v,i)1: Init Stack, N1, N2, j=i, j_max = i+2v-1 2: Exit

TreeHash.update()1: If j <= j_max 2: N1 = LeafCalc(j)3: While N1.level() == Stack.top().level() do5: N2 = Stack.pop()6: N1 = ComputeParent( N2, N1 )7: Stack.push(N1)8: Set j = j+19: Exit

One leaf per update

Distribute Computation

Concept Run one TreeHash instance per level 0 <= v < h-k Start computation of next right node on level v when current

node becomes part of authentication path. Use scheduling strategy to guarantee that nodes are finished in

time. Distribute (h-k)/2 updates per signature among all running

TreeHash instances

Distribute Computation

Worst Case RuntimeBefore:2h-k-1 leaf and 2h-k-1-(h-k) node computations.With distributed computation:(h-k)/2 + 1 leaf and 3(h-k-1)/2 + 1 node computations.

Add. Storage Single stack of size h-k nodes for all TreeHash instances.+ One node per TreeHash instance.= 2(h-k) nodes

BDS Performance

Storage:

n bit nodes

n bit seeds for forward secure XMSS.

Runtime:(h−k)/2+1 leaf and 3(h−k−1)/2+1 node computations.

+(h−k) calls to FSPRG for forward secure XMSS in the worst case.

kkhh 2232

3

kh 22