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. The Sender...

   1. generates an ephemeral, single-use symmetric encryption key.

   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. encrypts the message using the symmetric key using an authenticated encryption scheme to prevent malicious actors from modifying the ciphertext in transit.

   4. sends encapsulated key along with the ciphertext to the recipient

2. The recipient...

   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. 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:

• $\mathbb{B}^{N}$ is the set of all $N$-byte strings. $\mathbb{B}$ is the set of all byte strings of any length.
• $\text{randomFr}() \rightarrow \mathbb{F}_r$: a function that uniformly samples a random element of Baby Jubjub's scalar field.
• $\text{secret} \in \mathbb{F}_r$: A secret, random field element from which the protocol is "seeded".
• $\text{encapsulatedSecret} \in \mathbb{G}$: A Baby Jubjub curve point that "encapsulates" $\text{ephemeralKey}$. Specifically, it's the sender's portion of a non-interactive Diffie-Hellman exchange (see below).
• $\text{sharedSecret} \in \mathbb{G}$: a shared "secret" Baby Jubjub curve point used to derive $\text{ephemeralKey}$ using $\text{HKDF}$. It is shared between the sender and the receiver via a non-interactive Diffie-Hellman exchange (see below).
• $\text{ephemeralKey} \in \mathbb{B}^{32}$: A 32-byte ephemeral encryption key used for the symmetric part of the encryption scheme
• $\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 $\text{ikm}$ for short. We use it to derive $\text{ephemeralKey}$ from $\text{sharedSecret}$. We use HKDF as defined by [RFC-5869](https://datatracker.ietf.org/doc/html/rfc5869) and instantiate it over SHA256.
• $\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:

  • $\text{seal}(\text{key}, \text{nonce}, \text{plaintext}) \rightarrow \mathbb{B}$: encrypts the given $\text{plaintext}$using the given 32-byte $\text{key}$ and 12-byte $\text{nonce}$.
  • $\text{open}(\text{key}, \text{nonce}, \text{ciphertext}) \rightarrow \mathbb{B} \cup \bot$: attempts to decrypt the given $\text{ciphertext}$using the given $\text{nonce}$ and $\text{ciphertext}$. If it fails, it returns an error ($\bot$).
• $\text{deriveBaseNonce}(\text{sharedSceret}) \rightarrow \mathbb{B}^{12}$: a function that derives a 12-byte nonce for $\text{ChaCha20Poly1305}$ from $\text{sharedSecret}$.

Spelled out, encryption takes as input:

• the message $\text{msg}$
• and the recipient's canonical address $R$, which we use as their public key in this scheme (the corresponding secret key is their viewing key $\text{vk}$)

And proceeds as follows:

1. $\text{secret} \leftarrow \text{randomFr}()$
2. $\text{encapsulatedSecret} \leftarrow \text{secret} \times G$ (the $g^a$ part of Diffie-Hellman)
3. $\text{sharedSecret} \leftarrow \text{secret} \times R$ (the $g^{ab}$ part of Diffie-Hellman, where $b$ is the recipient's $\text{vk}$)
4. $\text{ephemeralKey} \leftarrow \text{HKDF}(\text{encapsulatedSecret}\ ||\ \text{sharedSecret})$
5. $\text{nonce} \leftarrow \text{deriveBaseNonce}(\text{sharedSecret})$
6. $\text{plaintext} \leftarrow \text{secret}\ ||\ \text{msg}$
7. $\text{ciphertext} \leftarrow \text{ChaCha20Poly1305.seal}(\text{ephemeralKey}, \text{nonce}, \text{plaintext})$
8. return $(\text{encapsulatedSecret}, \text{ciphertext})$

Decryption takes as input:

• the ciphertext $\text{ciphertext}$
• the encapsulated secret $\text{encapsulatedSecret}$
• the recipient's viewing key $\text{rvk}$

And proceeds as follows:

1. $\text{sharedSecret} \leftarrow \text{rvk} \times \text{encapsulatedSecret}$(the receiver's side of Diffie-Hellman,$(g^a)^b = g^{ab}$)
2. $\text{ephemeralKey} \leftarrow \text{HKDF}(\text{encapsulatedSecret}\ ||\ \text{sharedSecret})$
3. $\text{nonce} \leftarrow \text{deriveBaseNonce}(\text{sharedSecret})$
4. $\text{plaintext} \leftarrow \text{ChaCha20Poly1305.open}(\text{ephemeralKey}, \text{nonce}, \text{ciphertext})$
5. if $\text{plaintext} = \bot$, reject the message
6. otherwise, parse $(\text{secret}, \text{msg})$ from $\text{plaintext}$
7. $\text{expectedEncapsulatedSecret} \leftarrow \text{secret} \times G$ (extra check requiring the sender to prove that they know $\text{secret}$)
8. if $\text{expectedEncapsulatedSecret} \neq \text{encapsulatedSecret}$, reject the message
9. otherwise, return $\text{msg}$