Skip to main content

Current limitations

There are a few limitations on what you can do with FHE programs today.

Integer operations​

We currently support integers up to 64 bits. We will add support for higher precision integers in later releases.

64 bit support does have a caveat; constants are not currently supported in 64 bit operations. For example, to use a zero value in a 64 bit comparison, you must pass in the zero value as a parameter.

[[clang::fhe_program]] void greater_than_zero(
    [[clang::encrypted]] uint64_t value,
    [[clang::encrypted]] uint64_t zero,
    [[clang::encrypted]] uint64_t *result
) {
    *result = value > zero;
}

While addition, subtraction, and multiplication are all supported, division by plaintext and ciphertext is not yet available.

Branching operations​

Branching over plaintext values works as expected. However, it is a fundamental limitation of FHE that generic branching over ciphertext values is not supported. This is because the program would need to change it’s executation path based on encrypted data, which would reveal information about the encrypted data. Hence it is not possible to have if statements or loops that depend on ciphertext values.

However, we do support a limited form of branching known as select (or iselect for signed values). This is essentially a ternary operator that allows you to choose between two values based on a condition. The syntax is result = select(cond, true_value, false_value), where cond, true_value, and false_value can all be any encryptedness (plaintext or ciphertext). This allows you to implement branching logic without revealing information about the encrypted data.

Result outputting​

This restriction applies to writing FHE programs that are uploaded to the current version of SPF. If the C function has a return value (e.g. uint32_t), it will be ignored so instead you should use a pointer argument to “receive” the return value instead. This should be a dedicated “output” parameter in the form of a pointer, because pointer parameter used for input will have the changes also ignored. For example, if you have a sorting program that takes in an array (in the form of pointer) and sort it “in place”, you won’t get result out of the function; you must copy it to another pointer argument that has the same space allocated and is dedicated to receive the sorted array as an output.

This is not a fundamental limitation and we are working to get this restriction removed soon.

WASM​

Today, we have limited support for WebAssembly. You can see an example of how to wrap the client functionality in WASM here.