DahLIAS 🌼: Discrete Logarithm-based Interactive Aggregate Signatures

 Yannick Seurin, Tim Ruffing, Jonas Nick

Signature Schemes

  • "single" signature
    • \(\mathsf{Verify}(pk, msg, sig) \rightarrow \{0, 1\}\)
  • multi-signature
    • \(\mathsf{Verify}((pk_1, \ldots, pk_n), msg, sig)\rightarrow \{0, 1\}\)
  • aggregate signature
    • \(\mathsf{Verify}(((pk_1, msg_1), \ldots, (pk_n, msg_n)), sig)\rightarrow \{0, 1\}\)
    • Trivial Example:
(s_1, ..., s_n) := sig
for i in 1..n:
	if Verify(m_i, pk_i, s_i) == 0:
    	return 0
return 1

DahLIAS 🌼

DahLIAS is the first aggregate signature scheme

  1. with constant-size signatures (64 bytes in practice)
    • verification time is not constant (linear in \(n\))
  2. directly based on discrete discrete logarithms in pairing-free groups.
    • we can continue using the curve secp256k1 we're familiar with

Application: Bitcoin transactions

  • Today: every transaction input typically contains a signature of a message (the "sighash")

  • With DahLIAS: every transaction could have only a single aggregate signature

     

Downside of DahLIAS, it is interactive

aggregate signature

Signer 1

Signer 2

(This is pretty much the same communication as in  MuSig2)

(First two half round trips can be preprocessed)

Alternative: Schnorr Signature Half-aggregation

  • Signature is not constant-size but half the size of the individual Schnorr signatures (32 + n*32 bytes).

  • Non-interactive!
    • Public algorithm: \(\mathsf{Aggregate}((sig_1, \ldots, sig_n)) \rightarrow aggsig \)

Alternative: Aggsigs from multisignatures

def VerifyAgg(((m_1, pk_1), ..., (m_n, pk_n)), s):
    return VerifyMulti(m_1 || ... || m_n,
                       (pk_1, ..., pk_n),
                       s)
  • Actually this is broken due to "Russell's [O'Connor] attack".
    • Easy fix: Let VerifyAgg abort when there are duplicate public keys.
    • We prove the security of this in the paper.
  • So we could just use MuSig2 (also interactive), why need a new scheme like DahLIAS?

 

Key Tweaking

  • Assume we have some function \(\mathsf{PubKey}(sk) \rightarrow pk\)
  • Key Tweaking
    • \(\mathsf{TweakSK}(sk, t) \rightarrow sk\)
    • \(\mathsf{TweakPK}(pk, t) \rightarrow pk\)
    • Property
      • \(PubKey(TweakSK(sk, t)) = TweakPK(PubKey(sk), t)\)
  • BIP 32 key derivation and Taproot commitments are examples of key tweaking.
    • We use it quite a lot in Bitcoin
    • Want our aggregate signature scheme to be secure even if signers tweak their keys (it's not obvious that this is secure)

ATTACK!

The translation multisig->aggsig is not secure if the signer is doing key tweaking!

If we had done that it would have been broken!

In other words:

(I believe this validates our slow-and-steady approach  to cryptography)

Comparison with other Discrete Log-based schemes

DahLIAS 🌼

DahLIAS is the first aggregate signature scheme

  1. with constant-size signatures (64 bytes in practice)
    • verification time is not constant (linear in \(n\))
  2. directly based on discrete discrete logarithms in pairing-free groups.
    • we can continue using the curve secp256k1 we're familiar with