Add a blinding factor to swap NFTs and make swap outputs deterministically generated from it

[hdevalence]

Is your feature request related to a problem? Please describe.

1544 flags an issue with the current implementation of the swap/swapclaim mechanism: because the output note plaintexts are generated by the claimer, and not verified as part of the proof, a malicious claimer (in possession of only a full viewing key) can burn output funds by correctly constructing output notes and proving correctness of their note commitments, but not correctly encrypting the notes themselves to the recipient.

Fixing this has two parts. In the first part, this issue, we change the swap/swapclaim mechanism so that the output notes are deterministically derived only from data in the original swap, so that the entity that signed the swap can always derive the output notes. In the second part, later, we would like to eliminate the deterministically-derived notes from the swapclaim, to save space on chain and work for other clients.

Describe the solution you'd like

• [x] Add a swap blinding factor (an Fq element) to the swap plaintext
  • [x] in the proto type
  • [x] the domain type
  • [x] in the fixed-length encoding we use to construct the swap ciphertext
• [x] Extend the Planner API to choose a random blinding factor when constructing the swap plan, similar to other blinding factors (e.g., the note blinding in an output plan, etc)
• [x] Change the derivation of the swap nft asset id (in SwapPlaintext::asset_id) to compute the asset id as hash_7(DOM_SEP, (swap_blinding, amount, ...)) instead of hash_6(DOM_SEP, (amount, ...)).
• [x] Add the swap blinding factor to the SwapProof. Currently, there's no asset id integrity check in the SwapProof to adjust -- this is actually a security-critical soundness bug. To fix it:
  • [x] Remove the swap_nft_asset_id field from the SwapProof. Instead, recompute what it should be inside of the proof verification, by using the data in the SwapProof to construct a SwapPlaintext, and compute the expected asset ID by calling SwapPlaintext::asset_id, rather than using the attacker-controlled asset ID.
• [x] Add the swap blinding factor to the SwapClaimProof, and adjust its checks too. Currently, the swap claim proof checks the asset ID using a swap_nft_asset_id_integrity gadget, which constructs a SwapPlaintext out of the data in the SwapClaimProof, recomputes the expected asset ID, and checks that the provided one matches. Instead, we should also remove the swap_nft_asset_id from the SwapClaimProof, and rather than checking it against the expected value we recompute, we should just use the recomputed value directly.

• [x] Change the SwapClaim to deterministically generate note blinding factors from the original randomness in the swap blinding:

  • [x] Add a pub SwapPlaintext::output_blinding_factors(&self) -> (Fq, Fq) method that generates the blinding factors for the two output notes, with something like the following (see also the SwapPlaintext::asset_id() implementation):

    
    pub static OUTPUT_1_BLINDING_DOMAIN_SEPARATOR: Lazy<Fq> =
    Lazy::new(|| Fq::from_le_bytes_mod_order(blake2b_simd::blake2b(b"penumbra.swapclaim.output1.blinding").as_bytes()));
    pub static OUTPUT_2_BLINDING_DOMAIN_SEPARATOR: Lazy<Fq> =
    Lazy::new(|| Fq::from_le_bytes_mod_order(blake2b_simd::blake2b(b"penumbra.swapclaim.output2.blinding").as_bytes()));

  impl SwapPlaintext { pub fn output_blinding_factors(&self) -> (Fq, Fq) { ( hash_1(OUTPUT_1_BLINDING_DOMAIN_SEPARATOR, self.swap_blinding), hash_1(OUTPUT_2_BLINDING_DOMAIN_SEPARATOR, self.swap_blinding), ) } }

  
  - [x] Remove the `output_1_blinding` and `output_2_blinding` fields from the `SwapClaimPlan`.  Instead, when constructing the swap claim in `swap_claim_body()`, use `SwapPlaintext::output_blinding_factors()` to generate them from `self.swap_plaintext`.
  - [x] Remove the `note_blinding_1` and `note_blinding_2` fields from the `SwapClaimProof`. Instead, recompute them inside the proof verification by calling `output_blinding_factors()` on the same `SwapPlaintext` used to recompute the asset ID.

This shouldn't require any changes to the view service, or downstream users of the planner API, because it only changes how the blinding factors are derived (deterministically, rather than internal randomness), and because it only changes the format of the SwapPlaintext, which is stored in the view service as a blob.

[aubrika]

```the fixed-length encoding we use to construct the swap ciphertext````

This part isn't entirely clear to me - since it's fixed length, how should I correctly add this new field without breaking any expectations unnecessarily?

[hdevalence]

@aubrika The fixed-length encoding is the one defined here:

https://github.com/penumbra-zone/penumbra/blob/main/crypto/src/dex/swap/plaintext.rs#L143-L155

We have to use a specially defined, fixed-length encoding when encrypting the swap plaintext, rather than the normal proto encoding, because proto encodings have lengths that vary based on contents (so the size of the ciphertext would leak information). We don't use it anywhere else, though, it's an internal implementation detail of the encryption mechanism.

To change it, increase SWAP_LEN_BYTES by 32 (the size of the blinding factor) and copy in self.blinding_factor.to_bytes() to the array, then do the same in the decoding here:

https://github.com/penumbra-zone/penumbra/blob/main/crypto/src/dex/swap/plaintext.rs#L163-L206

[aubrika]

Add the swap blinding factor to the SwapPlan, and extend the Planner API to choose a random blinding factor when constructing the swap plan, similar to other blinding factors (e.g., the note blinding in an output plan, etc)

Also asked elsewhere, but what should be the relationship between the blinding factor chosen when constructing the swap plan for the SwapPlan blinding factor field, and the blinding factor field present on the SwapPlaintext?

[hdevalence]

Add the swap blinding factor to the SwapPlan, and extend the Planner API to choose a random blinding factor when constructing the swap plan, similar to other blinding factors (e.g., the note blinding in an output plan, etc)

Also asked elsewhere, but what should be the relationship between the blinding factor chosen when constructing the swap plan for the SwapPlan blinding factor field, and the blinding factor field present on the SwapPlaintext?

Answered elsewhere, but for the record: the original scoping was wrong, and duplicated the blinding factor between the SwapPlaintext and the SwapPlan (which already has the blinding factor, transitively, via the SwapPlaintext).