fhEVM v0.5: Enhanced Security and Efficiency for Encrypted Data

fhEVM v0.5 introduces many significant enhancements to improve the security and efficiency of handling encrypted data in your applications, including packed input mechanism, enhanced Access Control List (ACL), and updated decryption and re-encryption process. Most importantly, starting from fhEVM v0.5, the Solidity API comes into a stable and finalized version that will be compatible for future versions and across various chains.

Packed input mechanism

The new version introduces the packing of inputs, allowing multiple plaintext values to be packed into a single ciphertext. This update is crucial for future development of fhEVM, particularly with the anticipated introduction of proven inputs.

In the example, [.c-inline-code]inputProof[.c-inline-code] is used as the ciphertext that contains all the encrypted data. The variables [.c-inline-code]param1[.c-inline-code], [.c-inline-code]param2[.c-inline-code], and [.c-inline-code]param3[.c-inline-code] are used as pointers. To access the encrypted value, you need to pass these pointers along with the actual data using the function [.c-inline-code]TFHE.asEuintXX[.c-inline-code]. This method retrieves the encrypted values pointed to, enabling their use in further encrypted operations.

function myExample(
 address account
 einput param1,
 uint id,
 einput param2,
 einput param3,
 bool isAllowed,
 bytes calldata inputProof
) {
  euint64 amount = TFHE.asEuint64(param1, inputProof);
}

Enhanced Access Control List (ACL)

With v0.5, managing ciphertext permissions has never been more robust. Access Control List (ACL) allows developers to define which addresses have the right to manipulate a ciphertext, ensuring the permission to be handled more explicitly and securely.

For this, we introduced two new functions to explicitly grant access to encrypted data: [.c-inline-code]TFHE.allow(ciphertext, account)[.c-inline-code] and [.c-inline-code]TFHE.allowTransient(ciphertext, account)[.c-inline-code]. These new functions will store permanently or in transient storage the permission for the account to compute or decrypt this ciphertext.

// MySecret.sol

function giveMySecret(einput encryptedSecret, bytes calldata inputProof) {
 // Create my secret
 euint16 mySecret = TFHE.asEuint16(encryptedSecret, inputProof);

 // Allow temporary the SecretStore contract to manipulate `mySecret`
 TFHE.allowTransient(mySecret, address(SecretStore));

 // Call `storeSecret` with `mySecret`
 SecretStore.storeSecret(mySecret);
}



// SecretStore.sol
function storeSecret(callerSecret euint16) {
 // Verify that the caller has also access to this ciphertext   require(TFHE.isSenderAllowed(callerSecret), "The caller is not authorized to access this secret.");

 // Store this ciphertext
 secret = callerSecret;

 // Make the transient allowance permanent for this ciphertext and for current contract.
 TFHE.allow(callerSecret, address(this));
}

Previously, making an encrypted state variable public was risky because other contracts could potentially access and use your encrypted data. However, with the new release, this concern is mitigated. Now, although a contract can access any ciphertext handle, it cannot manipulate or use the encrypted data without the appropriate permissions specified in the Access Control List (ACL). This ensures that your encrypted data remains secure, even if it is accessible.

Updated decryption and re-encryption process

Security and efficiency in re-encryption have been significantly improved by utilizing an off-chain service. This adjustment not only enhances security but also optimizes the performance of cryptographic operations by delegating this process.

In the previous release, we introduced asynchronous decryption that allows developers to batch multiple decryptions of the same type. In fhEVM v0.5, the API has been upgraded to allow decryption batches of multiple types: It is now possible to receive the decryption of an ebool and an euint64 in the same callback. See the decryption guide for more details.

Definitive API

fHEVM has significantly evolved over the past year, and with these new features, we're pleased to announce that fhEVM v0.5 represents the finalized version of the Solidity API. All contracts developed on v0.5 are designed to be compatible with future versions and across various chains, including L1 fhEVM blockchains and future coprocessors running on non-FHE chains. This ensures long-term stability and broad usability.

Other changes and improvements

fhEVM v0.5 introduces some other changes and improvements:

Deprecation of old functions: The functions [.c-inline-code]TFHE.reencrypt[.c-inline-code] and [.c-inline-code]TFHE.decrypt[.c-inline-code] are deprecated in favor of new functions discussed in our updated documentation.‍
New permissions model: Permissions are now more explicitly managed through new functions, enhancing security and control over data.‍
Packed encrypted inputs: All encrypted inputs are now packed into a single ciphertext, reducing the size of transactions.

If you haven’t tried out fhEVM v0.5 already, check our documentation and start building confidential smart contracts in FHE! In the next release, we’ll add zero-knowledge proofs for inputs and new types. Stay tuned!