Nocturne
Search
⌃K
Comment on page

Note Encryption

Within the nocturne protocol, notes created via a JoinSplit are encrypted and then published on-chain in a manner such that only the recipient's viewing key can decrypt it. This allows users to privately and trustlessly detect incoming notes.

Overview

Nocturne uses a variant of Hybrid Public Key Encryption (HPKE) to accomplish this. Before we describe Nocturne's scheme in detail, for context, we'll describe at a high level how HPKE works:
  1. 1.
    The Sender...
    1. 1.
      generates an ephemeral, single-use symmetric encryption key.
    2. 2.
      uses the recipient's public key to "encapsulate" the symmetric encryption key. Only the recipient can "decapsulate" it. This mechanism is commonly referred to as a Key Encapsulation Module (KEM).
    3. 3.
      encrypts the message using the symmetric key using an authenticated encryption scheme to prevent malicious actors from modifying the ciphertext in transit.
    4. 4.
      sends encapsulated key along with the ciphertext to the recipient
  2. 2.
    The recipient...
    1. 1.
      attempts to decapsulate the encapsulated key. If it succeeds, they can recover the ephemeral secret key. If it fails, they reject the message.
    2. 2.
      attempts to decrypt the message using the symmetric encryption key. If it fails, they reject the message.
Public key encryption allows us to encrypt a message to the recipient without sharing secret information but is slow. On the other hand, symmetric key encryption is fast but requires a secret to be shared between parties. HPKE gives us the best of both worlds, which is important because we need to encrypt many notes on resource-constrained devices, but we also have no trustless mechanism for sharing secret keys.

Detailed Description

Context out of the way, we'll now describe Nocturne's note encryption scheme in detail. First, some definitions:
  • ​
    BN\mathbb{B}^{N}
     is the set of all
    NN
    -byte strings.
    B\mathbb{B}
     is the set of all byte strings of any length.
  • ​
    randomFr()→Fr\text{randomFr}() \rightarrow \mathbb{F}_r
    : a function that uniformly samples a random element of Baby Jubjub's scalar field.
  • ​
    secret∈Fr\text{secret} \in \mathbb{F}_r
    : A secret, random field element from which the protocol is "seeded".
  • ​
    encapsulatedSecret∈G\text{encapsulatedSecret} \in \mathbb{G}
    : A Baby Jubjub curve point that "encapsulates"
    ephemeralKey\text{ephemeralKey}
    . Specifically, it's the sender's portion of a non-interactive Diffie-Hellman exchange (see below).
  • ​
    sharedSecret∈G\text{sharedSecret} \in \mathbb{G}
    : a shared "secret" Baby Jubjub curve point used to derive
    ephemeralKey\text{ephemeralKey}
     using
    HKDF\text{HKDF}
    . It is shared between the sender and the receiver via a non-interactive Diffie-Hellman exchange (see below).
  • ​
    ephemeralKey∈B32\text{ephemeralKey} \in \mathbb{B}^{32}
    : A 32-byte ephemeral encryption key used for the symmetric part of the encryption scheme
  • ​
    HKDF(ikm)→B32\text{HKDF}(\text{ikm}) \rightarrow \mathbb{B}^{32}
    : A key derivation function that derives a 32-byte key from an arbitrary-length byte string representing the "input keying material", or
    ikm\text{ikm}
     for short. We use it to derive
    ephemeralKey\text{ephemeralKey}
     from
    sharedSecret\text{sharedSecret}
    . We use HKDF as defined by [RFC-5869](https://datatracker.ietf.org/doc/html/rfc5869) and instantiate it over SHA256.
  • ​
    ChaCha20Poly1305\text{ChaCha20Poly1305}
    : The symmetric encryption part of our HPKE scheme. In case it's not clear from the name, we use the ChaCha20Poly1305 encryption scheme. It has two methods:
    • ​
      seal(key,nonce,plaintext)→B\text{seal}(\text{key}, \text{nonce}, \text{plaintext}) \rightarrow \mathbb{B}
      : encrypts the given
      plaintext\text{plaintext}
      using the given 32-byte
      key\text{key}
       and 12-byte
      nonce\text{nonce}
      .
    • ​
      open(key,nonce,ciphertext)→B∪⊥\text{open}(\text{key}, \text{nonce}, \text{ciphertext}) \rightarrow \mathbb{B} \cup \bot
      : attempts to decrypt the given
      ciphertext\text{ciphertext}
      using the given
      nonce\text{nonce}
       and
      ciphertext\text{ciphertext}
      . If it fails, it returns an error (
      ⊥\bot
      ).
  • ​
    deriveBaseNonce(sharedSceret)→B12\text{deriveBaseNonce}(\text{sharedSceret}) \rightarrow \mathbb{B}^{12}
    : a function that derives a 12-byte nonce for
    ChaCha20Poly1305\text{ChaCha20Poly1305}
     from
    sharedSecret\text{sharedSecret}
    .
​
Spelled out, encryption takes as input:
  • the message
    msg\text{msg}
    ​
  • and the recipient's canonical address
    RR
    , which we use as their public key in this scheme (the corresponding secret key is their viewing key
    vk\text{vk}
    )
And proceeds as follows:
  1. 1.
    ​
    secret←randomFr()\text{secret} \leftarrow \text{randomFr}()
    ​
  2. 2.
    ​
    encapsulatedSecret←secret×G\text{encapsulatedSecret} \leftarrow \text{secret} \times G
     (the
    gag^a
     part of Diffie-Hellman)
  3. 3.
    ​
    sharedSecret←secret×R\text{sharedSecret} \leftarrow \text{secret} \times R
     (the
    gabg^{ab}
     part of Diffie-Hellman, where
    bb
     is the recipient's
    vk\text{vk}
    )
  4. 4.
    ​
    ephemeralKey←HKDF(encapsulatedSecret ∣∣ sharedSecret)\text{ephemeralKey} \leftarrow \text{HKDF}(\text{encapsulatedSecret}\ ||\ \text{sharedSecret})
    ​
  5. 5.
    ​
    nonce←deriveBaseNonce(sharedSecret)\text{nonce} \leftarrow \text{deriveBaseNonce}(\text{sharedSecret})
    ​
  6. 6.
    ​
    plaintext←secret ∣∣ msg\text{plaintext} \leftarrow \text{secret}\ ||\ \text{msg}
    ​
  7. 7.
    ​
    ciphertext←ChaCha20Poly1305.seal(ephemeralKey,nonce,plaintext)\text{ciphertext} \leftarrow \text{ChaCha20Poly1305.seal}(\text{ephemeralKey}, \text{nonce}, \text{plaintext})
    ​
  8. 8.
    return
    (encapsulatedSecret,ciphertext)(\text{encapsulatedSecret}, \text{ciphertext})
    ​
Decryption takes as input:
  • the ciphertext
    ciphertext\text{ciphertext}
    ​
  • the encapsulated secret
    encapsulatedSecret\text{encapsulatedSecret}
    ​
  • the recipient's viewing key
    rvk\text{rvk}
    ​
And proceeds as follows:
  1. 1.
    ​
    sharedSecret←rvk×encapsulatedSecret\text{sharedSecret} \leftarrow \text{rvk} \times \text{encapsulatedSecret}
    (the receiver's side of Diffie-Hellman,
    (ga)b=gab(g^a)^b = g^{ab}
    )
  2. 2.
    ​
    ephemeralKey←HKDF(encapsulatedSecret ∣∣ sharedSecret)\text{ephemeralKey} \leftarrow \text{HKDF}(\text{encapsulatedSecret}\ ||\ \text{sharedSecret})
    ​
  3. 3.
    ​
    nonce←deriveBaseNonce(sharedSecret)\text{nonce} \leftarrow \text{deriveBaseNonce}(\text{sharedSecret})
    ​
  4. 4.
    ​
    plaintext←ChaCha20Poly1305.open(ephemeralKey,nonce,ciphertext)\text{plaintext} \leftarrow \text{ChaCha20Poly1305.open}(\text{ephemeralKey}, \text{nonce}, \text{ciphertext})
    ​
  5. 5.
    if
    plaintext=⊥\text{plaintext} = \bot
    , reject the message
  6. 6.
    otherwise, parse
    (secret,msg)(\text{secret}, \text{msg})
     from
    plaintext\text{plaintext}
    ​
  7. 7.
    ​
    expectedEncapsulatedSecret←secret×G\text{expectedEncapsulatedSecret} \leftarrow \text{secret} \times G
     (extra check requiring the sender to prove that they know
    secret\text{secret}
    )
  8. 8.
    if
    expectedEncapsulatedSecret≠encapsulatedSecret\text{expectedEncapsulatedSecret} \neq \text{encapsulatedSecret}
    , reject the message
  9. 9.
    otherwise, return
    msg\text{msg}
    ​
​
​
Protocol Details - Previous
JoinSplit Circuit
Next - Protocol Details
Contracts
Last modified 3mo ago