Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.arcium.com/llms.txt

Use this file to discover all available pages before exploring further.

Confidential data is passed as an Enc<Owner, T> generic type, where Owner specifies who can reveal the data (either Shared or Mxe), and T is the underlying data type being protected. In the case of Mxe, the nodes collectively can reveal the data under dishonest majority assumptions, whereas if the Owner is Shared, then the data was protected using a shared secret between the client and the MXE. Underneath the hood, this generic wrapper type contains the ciphertext, as well as the public key (only for Shared owner) and nonce used to produce it. Confidential data can be revealed globally or selectively to a given user. For global reveal, you can call the reveal method on any variable of supported data type. Read more about how we enable this using re-encoding (aka sealing) in Arcium here. Confidential inputs are protected using the arithmetization-oriented symmetric Rescue cipher. Before the cipher runs, a x25519 elliptic curve Diffie-Hellman key exchange is performed between the client and the cluster to derive a common shared secret. The Rescue key is derived by hashing the shared secret with the Rescue-Prime hash function, as described in Section 4, Option 1. This increases the min-entropy of the key.
Note:
  1. Since the x25519 key exchange natively returns shared secrets in the finite field with p=2255−19p = 2^{255} - 19 elements, we implemented Rescue over the field Fp\mathbb{F}_{p}. States in the context of Rescue are elements of the mm-dimensional vector space Fpm\mathbb{F}_p^m, i.e., the Rescue cipher transforms vectors of size mm to vectors of the same size.
  2. The security level ss of the cipher is set to 128 bits.
  3. We use the Rescue block cipher in Counter (CTR) mode (see Section 6.5), with fixed m=5m = 5. The choice m=5m = 5 is motivated by the fact that it is the smallest value that attains the minimum of recommended rounds (10), given the fixed finite field and security level. The counters are of the form [nonce, i, 0, 0, 0], where nonce are 16 random bytes provided by the user.
  4. The hash function used for key derivation is Rescue-Prime over F2255−19\mathbb{F}_{2^{255}-19}, with rate = 7 and capacity = 5 (i.e., m=12m = 12) and output truncated to 5 field elements. The target security level ss is set to 256. According to Section 2.2, this offers 256 bits of security against collision, preimage and second-preimage attacks for any field of size at least 102 bits.
The reveal of input_enc: Enc<Owner, T> can conveniently be obtained by calling input_enc.to_arcis() (the nodes do not learn input, they simply convert the ciphertext to secret-shares of input by running the Rescue decoding circuit in MPC). If the owner is Shared, the MXE and the client perform a key exchange first. Similarly, owner.from_arcis(output) protects the secret-shared output by running the Rescue encoding circuit in MPC.
Note:
  1. After revealing the user-provided inputs, the MXE increments the nonce by 1 and uses it for protecting the outputs. For the forthcoming interaction with the MXE, a new nonce must be provided.
  2. The performance will benefit from reducing the number of calls to owner.from_arcis(..) (per owner). Ideally, put all data destined for owner in one struct.
EncData<T> contains only ciphertext, omitting pubkey and nonce. Use for multiple outputs to reduce callback payload size.

​
What’s next?

Protecting Inputs

Implement confidentiality in your TypeScript client.

Sealing

Re-encode data between different parties.