# In-band secret distribution

## Overview

To ensure a recipient receives the secret information required to spend their commitment, the sender encrypts the secrets (salt, value, tokenId, ercAddress) of the commitment sent to the recipient and proves using zkp that they encrypted this correctly with the recipient's public key. We use the KEM-DEM hybrid encryption paradigm.

## KEM-DEM Hybrid Encryption

### Key Creation

Use Elliptic curve (here we use Baby Jubjub curve) `E` over a finite field `Fp` where `p` is a large prime and `G` is the generator.

Alice generates a random ephemeral asymmetric key-pair $$(x\_e, Q\_e)$$:\
$$x\_e ; \leftarrow; {0, 1}^{256} \qquad Q\_e \coloneqq x\_eG$$

These keys are only used once, and are unique to this transaction.

### Encryption

The encryption process involves 2 steps: a KEM step to derive a symmetric encryption key from a shared secret, and a DEM step to encrypt the plaintexts using the encryption key.

### Key Encapsulation Method (Encryption)

Using the previously generated asymmetric private key, we obtain a shared secret, $$key\_{DH}$$, using standard Diffie-Hellman. This is hashed alongside the ephemeral public key to obtain the encryption key. $$key\_{DH} \coloneqq x\_eQ\_r \qquad key\_{enc} \coloneqq H\_{K}(key\_{DH} ; + ;Q\_e)$$

where:\
$$Q\_r$$ is the recipient's public key\
$$H\_{K}(x) \coloneqq \text{Poseidon}(Domain\_{K}, x)$$\
$$Domain\_{K} \coloneqq \text{to\_field}(\text{SHA256}(\text{'nightfall-kem'}))$$

### Data Encapsulation Method (Encryption)

For circuit efficiency, the encryption used is a block cipher in counter mode where the cipher algorithm is a mimc hash. Given the ephemeral keys are unique to each transaction, there is no need for a nonce to be included. The encryption of the $$i^{th}$$ message is as follows:

$$c\_i \coloneqq H\_{D}(key\_{enc} + i) + p\_i$$

where:\
$$H\_{D}(x) \coloneqq \text{Poseidon}(Domain\_{D}, x)$$\
$$Domain\_{D} \coloneqq \text{to\_field}(\text{SHA256}(\text{'nightfall-dem'}))$$

The sender then provides the recipient with $$(Q\_e, \text{ciphertexts})$$. These are included as part of the transaction struct sent on-chain.

### Decryption

In order to decrypt, the recipient performs a slightly modified version of the KEM-DEM steps.

### Key Encapsulation Method (Decryption)

Given $$Q\_e$$, the recipient is able to calculate the encryption key locally by performing the following steps.

$$key\_{DH} \coloneqq x\_rQ\_e \qquad key\_{enc} \coloneqq H\_{K}(key\_{DH} ; + ;Q\_e)$$

where:\
$$Q\_e$$is the ephemeral public key\
$$H\_{K}(x) \coloneqq \text{Poseidon}(Domain\_{K}, x)$$\
$$Domain\_{K} \coloneqq \text{to\_field}(\text{SHA256}(\text{'nightfall-kem'}))$$

### Data Encapsulation Method (Decryption)

With $$key\_{enc}$$ and an array of ciphertexts, the $$i\_{th}$$ plaintext can be recovered with the following:

$$p\_i \coloneqq c\_i - H\_{D}(key\_{enc} + i)$$

where:\
$$H\_{D}(x) \coloneqq \text{Poseidon}(Domain\_{D}, x)$$\
$$Domain\_{D} \coloneqq \text{to\_field}(SHA256(\text{'nightfall-dem'}))$$

## Derivation and generation of the various keys involved in encryption, ownership of commitments and spending

Using BIP39 generate a 12 word `mnemonic` and from this generate a `seed` by calling `mnemonicToSeedSync`. Then following the standards of BIP32 and BIP44, generate a `rootKey` based on this `seed` and `path`.

```
zkpPrivateKey = Poseidon(rootKey, 2708019456231621178814538244712057499818649907582893776052749473028258908910)
where 2708019456231621178814538244712057499818649907582893776052749473028258908910 is keccak256(`zkpPrivateKey`) % BN128_GROUP_ORDER

nullifierKey = Poseidon(rootKey, 7805187439118198468809896822299973897593108379494079213870562208229492109015n)
where 7805187439118198468809896822299973897593108379494079213870562208229492109015n is keccak256(`nullifierKey`) % BN128_GROUP_ORDER

zkpPublicKey = zkpPrivateKey * G
```

The apps which will use the `ZkpKeys` to generate these keys can store the `rootKey` in different devices by splitting this into shares using Shamir Secret Sharing. If either `rootKey` or `mnemonic` is compromised, then the adversary can calculate the `zkpPrivateKey` and `nullifierKey`. The `zkpPrivateKey` can be used to decrypt secrets of a commitment whilst the `nullifierKey` can be used to spend the commitment. Hence `rootKey` and `mnemonic` must be stored very securely. It is also recommended to store `zkpPrivateKey` and `nullifierKey` separately to avoid theft of commitments in case one of these is compromised.