Skip to content

Instantly share code, notes, and snippets.

@RubenSomsen
Last active March 30, 2022 19:27
Show Gist options
  • Save RubenSomsen/97256945a1d139ad57c2cc067e1f8be1 to your computer and use it in GitHub Desktop.
Save RubenSomsen/97256945a1d139ad57c2cc067e1f8be1 to your computer and use it in GitHub Desktop.

Segregated Message Signature Scheme (SMSS)

This write-up formalizes a modest adaptation to the regular Schnorr and ECDSA signature scheme, using existing techniques, that allows for signature verification without requiring the message.

The regular signature scheme enables two functions:

  1. Proving knowledge of a secret key
  2. Tying that proof to a message

Signature verification requires:

  • The public key
  • The signature
  • The message

In some situations, it may be the case that a subset of the verifiers only cares about 1 and not 2. Nonetheless, the message is always required. The Segregated Message Signature Scheme separates these two steps and makes it possible to prove knowledge of the secret key without the message. This is achieved by taking the message out of the regular signature scheme, and placing it inside of the nonce via the taproot tweak.

REGULAR SCHNORR SIGNATURE

X = k*G                    <- public key
R = r*G                    <- nonce
e = hash(X, R, message)    <- challenge
s = r + e*k                <- signature

Verifier: s*G == R + e*X
(message required to calculate e)

SEGREGATED MESSAGE SCHNORR SIGNATURE

X = k*G                    <- public key
R = r*G                    <- nonce
e'= hash(R, message)       <- segregated message
R'= R + e'*G               <- tweaked nonce
e = hash(X, R')            <- challenge
s = r + e' + e*k           <- signature

Verifier: s*G == R'+ e*X
(message not required to calculate e)

Message verification (requires R): 
R' == R + hash(R, message)*G

Also applicable to ECDSA

The advantage of this scheme is that those who only want to verify knowledge of the secret key will no longer need to know the message (32 bytes saved), and the downside is that others will need to open the commitment inside the nonce (32 bytes added).

An example use case would be a blockchain which consists purely of signatures that everyone verifies, but for which all messages remain off-chain, and are only revealed to specific recipients (as in Peter Todd's client-side validation).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment