Add threshold encryption for stored private transaction data

[huitseeker]

Background

Issue 0xMiden/node#2319 split private validator mode into three phases. PR 0xMiden/node#2342 merged phase 1. It added a validator transaction encryption key and a GetTransactionEncryptionKey endpoint.

This is phase 2. It protects private data after the validator receives it, decrypts it, and validates it.

Phase 2 does not change client submission encryption. It does not add TEE attestation. Those belong in phase 3.

Prerequisites

This needs the Golden work first.

• 0xMiden/golden-dkg#1 is merged.
• 0xMiden/golden-dkg#6 is closed.

Issue 0xMiden/golden-dkg#6 depends on 0xMiden/golden-dkg#5.

Flow

Keep the phase 1 submission path. The client still encrypts to the validator transaction encryption key. The validator still decrypts on reception.

After validation, the validator stores private data under a fresh content key. It then encrypts that content key under an EHTDH1 threshold key from Golden setup.

Use EHTDH1 only for the content key. The witness can be large, so the validator should not threshold encrypt the full witness.

sequenceDiagram
    participant Client
    participant Validator
    participant Store
    participant Operators as Validator operators
    participant Combiner

    Client->>Validator: submit private transaction data
    Validator->>Validator: decrypt with phase 1 submission key
    Validator->>Validator: validate transaction
    Validator->>Validator: encrypt record with fresh content key
    Validator->>Store: store encrypted record and EHTDH1 ciphertext
    Operators->>Combiner: send EHTDH1 shares for one record context
    Combiner->>Store: read encrypted record
    Combiner->>Combiner: open content key and decrypt record

Loading

Stored data

Store these fields:

• encrypted private record
• HPKE style envelope metadata
• EHTDH1 ciphertext for the content key
• key epoch
• setup context id
• record id
• transaction id
• schema version
• block height, when known

Index by key epoch, setup context id, record id, and transaction id. Add a block height index after inclusion.

Decryption context

Use a per record context. The first version should include chain id, key epoch, record id, transaction id, and schema version.

Do not include block height in the first context. A validator can store a record before it has a block height. Store block height as lookup data after inclusion.

Do not use only the key epoch as the context. It covers too many records.

Shares

Use the phase 1 naming from PR 0xMiden/node#2342. The GetTransactionEncryptionKey endpoint returns the submission key. The storage key needs its own setup, key id, and context metadata.

Each validator operator holds one EHTDH1 decryption share for the storage key. For a later access request, an operator can return a share for one stored content key and one context.

Keep Golden and EHTDH1 behind a small adapter at the validator storage boundary. Node should not spread Golden protocol details through the validator.

Add a keyed decryption flow. A request names the private record, key epoch, and context. Each operator checks the request under deployment policy. If allowed, the operator returns an EHTDH1 share for that content key ciphertext and that exact context.

A combiner verifies shares, combines enough valid shares, opens the content key, and decrypts the stored private record. Shares for another record, context, or key epoch must fail.

Glossary

Term	Meaning
TransactionEncryptionKey, or submission key	The phase 1 key returned by GetTransactionEncryptionKey. Clients use it to encrypt submissions.
storage key	The EHTDH1 key used to protect stored content keys.
EHTDH1	The threshold encryption scheme added by 0xMiden/golden-dkg#1.
Golden setup	The setup step that creates the EHTDH1 shares.
content key	A fresh key for one stored private record.
encrypted private record	The stored private data after the validator encrypts it with the content key.
HPKE style envelope metadata	Public bytes that describe the record encryption. This does not include the plaintext content key.
EHTDH1 ciphertext	The threshold encrypted content key.
key epoch	The version of the storage key.
setup context id	The id for the Golden and EHTDH1 setup used by this key epoch.
record id	The stable id for one stored private record.
decryption context	The bytes that bind shares to one record. Shares for another context must not combine.
validator operator	The party that runs a validator and holds one EHTDH1 decryption share.
combiner	The code that verifies enough EHTDH1 shares and opens the content key.

Done

• The validator stores private transaction data as encrypted records.
• Each stored record uses a fresh content key.
• The content key is encrypted under the EHTDH1 threshold key.
• Stored threshold values use canonical golden-ehtdh1 bytes.
• The storage schema indexes key epoch, setup context id, record id, transaction id, and block height when known.
• Validator operators can produce decryption shares for one stored record and one context.
• The combiner opens a record only with enough valid shares for the same context.
• Shares for the wrong record, context, or key epoch fail.

Out of scope

Do not change client submission encryption.

Do not add TEE attestation or TEE key custody.

Do not design the full Golden DKG ceremony for production operations.

Do not change remote proving.

References

• 0xMiden/node#2319
• 0xMiden/node#2342
• 0xMiden/golden-dkg#1
• 0xMiden/golden-dkg#6

[bobbinth]

This looks great! I think logically this splits into two parts - though, could be done in one PR or in two stacked PRs that basically come out together:

1. The setup and re-encryption part. At this point, we'd have the witness data in the validator's DB encrypted with the threshold key (i.e., the content key - one per witness).
2. The decryption part where each validator gives the shares needed to to decrypt a given content key, and then these shares get combined to decrypt a specific witness.