Skip to content


Switch branches/tags

Name already in use

A tag already exists with the provided branch name. Many Git commands accept both tag and branch names, so creating this branch may cause unexpected behavior. Are you sure you want to create this branch?

Latest commit


Git stats


Failed to load latest commit information.
Latest commit message
Commit time

OpenSSE Schemes

License: AGPL v3 build status static analysis Coverage Status Codacy Badge

Implementation of SSE schemes. For now, the repo includes a C++ implementation of the following schemes:

Name Comments Authors Reference
Σoφoς (Sophos) First forward-private SSE scheme. Optimal asymptotic performance, but slow in practice because of its use of RSA. Bost [1]
Diana Very fast (practical) forward-private scheme, using only symetric cryptography. Bost, Minaud and Ohrimenko [2]
Janus First 'practical' backward-private scheme, based on puncturable encryption. In practice, very slow when the number of deletions grows. Bost, Minaud and Ohrimenko [2]
Tethys Static scheme designed for flash storage. Best in class throughput (as of 2021) and small ciphertext expansion, but with building time that can become prohibitively high. Bossuat, Bost, Fouque, Minaud, Reichle [3]
Pluto Practical improvement over Tethys for the setup time, but at the cost of an increased ciphertext expansion. Bossuat, Bost, Fouque, Minaud, Reichle [3]


Article Authors
[1] Σoφoς – Forward Secure Searchable Encryption Bost
[2] Forward and Backward Private Searchable Encryption from Constrained Cryptographic Primitives Bost, Minaud and Ohrimenko
[3] SSE and SSD: Page-Efficient Searchable Symmetric Encryption Bossuat, Bost, Fouque, Minaud, Reichle



OpenSSE's schemes implementation dependencies need a compiler supporting C++14 (although the core codebase doesn't). It has been successfully built and tested on Ubuntu 16.04 LTS using both clang 10 and gcc 5.4.0 and on Mac OS X.10 using clang 12.

The Cryptographic Toolkit

This repository uses a cryptographic toolkit specially designed for searchable encryption applications: crypto-tk. This toolkit is integrated as a git submodule, and will be automatically compiled when building the schemes. However, it has its own set of dependencies, and you should make sure they are available on your computer. Take a look at the build instructions for detailed information.


[sudo] apt-get install build-essential autoconf libtool yasm openssl cmake libaio-dev

The libaio-dev dependency is optional. However, if you are willing to use the Tethys and/or the Pluto schemes, we strongly advise you to install it, for performance's sake.

Installing gRPC

OpenSSE uses Google's gRPC as its RPC machinery. On Linux, there is, for now, no other way than installing gRPC from source. The procedure is described here. Note that OpenSSE has been tested with gRPC v1.34.

Installing RocksDB

OpenSSE uses Facebook's RocksDB as its storage engine. See the installation guide. Note that the build system currently used by this project does not support static builds of RocksDB. If you see linker errors involving compression libraries (libzstd, libz4, libsnappy, ...), it probably comes from OpenSSE linking against RocksDB's static library.

Mac OS X

[sudo] xcode-select --install

If you still haven't, you should get Homebrew. You can then directly install all the dependencies using Homebrew:

brew install automake autoconf yasm openssl cmake grpc rocksdb

Getting the code

The code is available via git:

git clone

You will also need to fetch the submodules (this might take a while):

git submodule update --init --recursive


Building is done using CMake. The minimum required version is CMake 3.1.

Then, to build the code itself, just enter in your terminal

mkdir build && cd build
cmake ..

Build Configuration and Options

As the library builds using CMake, the configuration is highly configurable. Like other CMake-based projects, options are set by passing -DOPTION_NAME=value to the cmake command. For example, for a debug build, use -DCMAKE_BUILD_TYPE=Debug. Also, you can change the compiler used for the project by setting the CC and CXX environment variables. For example, if you wish to use Clang, you can set the project up with the following command CC=clang CXX=clang++ cmake ...


  • ENABLE_COVERAGE=On|Off: Respectively enables and disables the code coverage functionalities. Disabled by default.
  • SANITIZE_ADDRESS=On|Off: Compiles the library with AddressSanitizer (ASan) when set to On. Great to check for stack/heap buffer overflows, memory leaks, ... Disabled by default.
  • SANITIZE_UNDEFINED=On|Off: When set to On, compiles the library with UndefinedBehaviorSanitizer (UBSan). UBSan detects undefined behavior at runtime in your code. Disabled by default.
  • opensse_ENABLE_WALL=On|Off: Toggles the -Wall compiler option. On by default
  • opensse_ENABLE_WEXTRA=On|Off: Toggles the -Wextra compiler option. On by default
  • opensse_ENABLE_WERROR=On|Off: Toggles the -Werror compiler option to turn all warnings into errors. On by default
  • CMAKE_BUILD_TYPE: Sets the build type. See CMake's documentation for more details. The Debug build type is used by default. Use Release for an optimized build.

To see all the available options, and interactively edit them, you can also use the ccmake tool.

For more information about how to use CMake, take a look at CMake's FAQ, or at the documentation.

In this project, CMake can also be used to configure the cryptographic toolkit. See crypto-tk's documentation for details and configuration points.


This repository provides implementations of SSE as a proof of concept, and cannot really be used for real sensitive applications. In particular, the cryptographic toolkit most probably has many implementation flaws.

The building script builds basic test programs for Sophos, Diana and Janus (respectively sophos_debug, diana_debug, and janus_debug), that are of no use per se, and two pairs of client/server programs for Sophos and Diana (sophos_server and sophos_client for Sophos, and diana_server and diana_client for Diana). These are the ones you are looking for.


The clients usage is as follows sophos_client [-b client.db] [-l inverted_index.json] [-p] [-r count] [-q] [keyword1 [... keywordn]]

  • -b client.db : use file as the client database (test.csdb by default)
  • -l file.json : load the reversed index file.json and add it to the database. file.json is a JSON file with the following structure :
	"keyword1" : [1,2,3,4],
	"keyword2": [11,22,33,44,55]

In the repo, inverted_index.json is an example of such file.

  • -p : print stats about the loaded database (number of keywords)
  • -r count : generate a database with count entries. Look at the aux/db_generator.* files to see how such databases are generated
  • keyword1 … keywordn : search queries with keyword1 … keywordn.


The servers usage is as follows sophos_server [-b server.db] [-s]

  • -b server.db : use file as the server database (test.ssdb by default)
  • -s : use synchronous searches (when searching, the server retrieves all the results before sending them to the client. By default, results are sent once retrieved). In the papers, this option was used for the benchmarks without RPC.


Unless otherwise stated, the code has been written by Raphael Bost.


OpenSSE Schemes is licensed under the GNU Affero General Public License v3.