Skip to main content

Preliminary knowledge

This section will help in understanding some of the terminology we use in SPF. Note that it is a brief introduction and we do have a more comprehensive section for those interested in learning more. The knowledge provided here is primarily related to cryptography; we assume readers are already familiar with the C programming language and (for web3) Solidity.

FHE is the next generation of public key cryptography. In addition to being able to encrypt and decrypt data, you can perform arithmetic, logical, and comparison operations directly over the encrypted data. This enables applications such as matching algorithms over an encrypted order book, sorting an encrypted list, and more.

Please note this section is intended to provide high level details and intuition, not rigorous technical definitions. If you’re interested in learning more about the details, we highly recommend this textbook as an introduction to cryptography.

Cryptography basics​

Here are some key concepts to understand before diving into FHE:

  • Plaintext vs. ciphertext: Plaintext refers to unencrypted data (i.e. data in the clear) whereas ciphertext refers to encrypted data.
  • Public key vs. private key: In public key cryptography, there are two types of keys. The public key only allows for data to be encrypted. The public key can be shared with anyone. In FHE we have an additional type of public key known as a compute key, which enables computations to be performed on ciphertexts. The private key is kept secret, as it allows for data to be decrypted (and encrypted too).
  • “Homomorphic”: We use this term to denote computations performed directly on encrypted data. For example, if we say “homomorphic addition,” we are referring to the operation that adds the underlying plaintexts of two ciphertexts without decrypting them first.

Threshold FHE computing model​

The SPF supports applications where multiple users’ private data can be used as program inputs (e.g. in an auction, voting). For these apps, all parties will use the same public key to encrypt their data. To keep the private key secure while still enabling decryption, the private key is sharded into pieces (aka shares) and held by a semi-trusted “threshold committee” as part of the SPF infrastructure using a technique known as threshold FHE. A threshold set of committee members must come together to decrypt any ciphertext in the system. This ensures no single committee member ever has access to the private key, and that the entirety of the private key is never revealed to anyone.

For more privacy-conscious users, we also support re-encryption. This technique enables users to keep ciphertexts decryptable under their own private key rather than the threshold committee key.

FHE vs other privacy-preserving technologies​

If you’re wondering how FHE differs from other privacy-preserving technologies, some nice things about FHE include:

  • The computation itself is non-interactive, so it’s great for decentralized settings where parties may be in very different locations around the world.
  • FHE is quite “fault-tolerant” from a developer’s standpoint, e.g. FHE is not susceptible to the broad range of attacks trusted execution environments are susceptible to.
  • FHE allows you to combine your private data with others’ private data in apps, unlike many zero-knowledge proof systems.
  • FHE is post-quantum, meaning FHE is secure against attacks from a quantum computer. An alternative way of thinking about this property is that FHE is “future-proof,” even in the case of harvest now, decrypt later attacks.