Arcium Docs
arcium.com@ArciumHQ
  • Documentation
  • Developers
  • Intro to Arcium
  • Installation
    • Arcup Version Manager
  • Hello World with Arcium
  • Arcium Computation Lifecycle
  • Encryption
    • Sealing aka re-encryption
  • Arcis
    • Operations
    • Types
    • Input/Output
    • Best practices
  • Invoking a Computation from your Solana program
    • Computation Definition Accounts
    • Callback Accounts
  • JavaScript Client
    • Encrypting inputs
    • Tracking callbacks
  • Callback Server
  • Current Limitations
Powered by GitBook
On this page

Encryption

PreviousArcium Computation LifecycleNextSealing aka re-encryption

Last updated 1 day ago

Encrypted data is passed as an Enc<Owner, T> generic type, where Owner specifies who can decrypt the data (either Shared or Mxe), and T is the underlying data type being encrypted. In the case of Mxe, the nodes collectively can decrypt the data under dishonest majority assumptions, whereas if the Owner is Shared, then the data was encrypted using a shared secret between the user and the MXE. Underneath the hood, this generic wrapper type contains the encrypted data, as well as the public key (only for Shared owner) and nonce used to encrypt the data.

Encrypted data can be decrypted globally or selectively to a given user. For global decryption, you can call reveal method on any variable of . Read more about how we enable this using re-encryption (aka sealing) in Arcium .

Private inputs are encrypted using the arithmetization-oriented symmetric . Prior to the encryption, a elliptic curve Diffie-Hellman key exchange is performed between the client and the cluster to derive a common shared secret. The Rescue key is obtained by applying the key derivation to the shared secret. 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} - 19p=2255−19 elements, we implemented Rescue over the field Fp\mathbb{F}_{p}Fp​. States in the context of Rescue are elements of the mmm-dimensional vector space Fpm\mathbb{F}_p^mFpm​, i.e., the Rescue cipher transforms vectors of size mmm to vectors of the same size.

  2. The security level sss of the cipher is set to 128 bits.

  3. We use the Rescue block cipher in (see Section 6.5), with fixed m=5m = 5m=5. The choice m=5m = 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 the key derivation is over F2255−19\mathbb{F}_{2^{255}-19}F2255−19​, with m=6m = 6m=6 and capacity = 1 (yielding rate = 5, which matches the size of the states for the Rescue cipher, see 3.). According to , this offers 255 / 2 bits of security against collision, preimage and second-preimage attacks.

The decryption 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 decryption circuit in MPC). If the owner is Shared, the MXE and the client perform a key exchange first. Similarly, owner.from_arcis(output) encrypts the secret-shared output by running the Rescue encryption circuit in MPC. Note:

  1. After decrypting the user-provided inputs, the MXE increments the nonce by 1 and uses it for encrypting 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 encrypted to owner in one struct.

supported data type
here
Rescue cipher
x25519
HKDF
Counter (CTR) mode
Rescue-Prime
Section 2.2