Nocturne
  • Introduction
    • Introduction
    • Protocol Overview
    • Compliance
  • Protocol Concepts
    • Keys and Stealth Addresses
    • Notes, Commitment Tree, Nullifiers, and JoinSplits
    • Deposits
    • Operations
  • Protocol Details
    • Algebraic Primitives & Notation
    • Keys & Key Derivation
    • Stealth Addresses
    • Signatures
    • Encodings
    • Commitment Tree
      • Subtree Update Circuit
    • JoinSplit Circuit
    • Note Encryption
    • Contracts
      • Deposit Manager
      • Teller
      • Handler
      • ETH Adapters
      • Canonical Address Registry
    • Offchain Actors
      • Deposit Screener
      • Bundler
      • Subtree Updater
  • Users
    • MetaMask Snap
    • FAQ
  • Developers
    • Contract Addresses
    • Trusted Setup
    • Security
    • Guardrails
    • Source Code
Powered by GitBook
On this page
  • Security Requirements
  • Security Argument
  1. Protocol Details

Signatures

PreviousStealth AddressesNextEncodings

Last updated 1 year ago

Nocturne uses a variant of Schnorr signatures over Baby Jubjub. The secret key is derived from the spending key sksksk, and the public key is the spending public key PK\text{PK}PK.

Spelled out, signing takes as input a message hash mmm and proceeds as follows:

  1. h←SHA512(sk)h \leftarrow \text{SHA512}(sk)h←SHA512(sk)

  2. s←h[0:32]s \leftarrow h[0:32]s←h[0:32](derive the signing secret key from the spending key)

  3. x←h[32:64]x \leftarrow h[32:64]x←h[32:64](extract 32 bytes of entropy from the spending key)

  4. v←randomBytes(32)v \leftarrow \text{randomBytes}(32)v←randomBytes(32) (sample another 32 random bytes)

  5. n←SHA512(x ∣∣ v ∣∣ m)mod  r∈Frn \leftarrow \text{SHA512}(x\ ||\ v\ ||\ m) \mod r \in \mathbb{F_r}n←SHA512(x ∣∣ v ∣∣ m)modr∈Fr​ ("reduce" hash output into Fr\mathbb{F}_rFr​, using extra entropy from sksksk addition to the rng)

  6. R←n×GR \leftarrow n \times GR←n×G (the rest is a "standard" Schnorr signature)

  7. c←H(PK.X ∣∣ R.X ∣∣ R.Y ∣∣ m)c \leftarrow H(\text{PK.X}\ ||\ R.X\ ||\ R.Y\ ||\ m)c←H(PK.X ∣∣ R.X ∣∣ R.Y ∣∣ m)

  8. z←n−sk⋅cz \leftarrow n - \text{sk} \cdot cz←n−sk⋅c

  9. The signature is the pair (c,z)(c, z)(c,z)

To verify, we take as input the message mmm and signature (c,z)(c, z)(c,z) and do the following (this is the standard verification procedure):

  1. Z←z×GZ \leftarrow z \times GZ←z×G

  2. P←c×PKP \leftarrow c \times \text{PK}P←c×PK

  3. R←Z+PR \leftarrow Z + PR←Z+P

  4. cp←H(PK.X ∣∣ R.X ∣∣ R.Y ∣∣ m)cp \leftarrow H(\text{PK.X}\ ||\ R.X\ ||\ R.Y\ ||\ m)cp←H(PK.X ∣∣ R.X ∣∣ R.Y ∣∣ m)

  5. Accept the signature if cp=ccp = ccp=c. Reject it otherwise.

Security Requirements

The signature scheme must be strongly unforgeable under chosen-message-attack (SUF-CMA).

Security Argument

Schnorr signature schemes are known to be secure under the discrete log assumption and the random-oracle model. In our case, it's secure based on the following assumptions:

  1. Poseidon is a random oracle

  2. The discrete log problem is infeasible in Baby Jubjub