OpenHuFu and secure queries across databases that refuse to share

Why sharing raw rows is the wrong default in a data federation

The problem OpenHuFu attacks is not query speed. It is that data isolation has become an obstacle to scaling query processing over big data, because sharing raw data between data owners is often prohibitive for security reasons. A federation of databases that cannot exchange rows cannot answer most cross-source questions, and the usual workaround, exporting copies to a central warehouse, reintroduces exactly the exposure the arrangement was meant to remove.

The alternative OpenHuFu implements is to run the query itself over the federation using cryptographic techniques, so the owners participate in the computation without handing over their data. The README names secure multi-party computation and differential privacy as the ingredients, and points at recent work on data federation and federated learning as the precedent.

Concretely, this is a spatial data federation system. The open-source version is the counterpart of Hu-Fu, the system described in a VLDB 2022 paper, and the repository also ships a journal version of the full paper as a PDF. The intended audience is researchers who want to implement federated query algorithms quickly and then measure them on benchmark data, rather than a team that wants to deploy a query service on Monday.

Secret sharing, garbled circuits and oblivious transfer as pipeline elements

The framework's real contribution is making cryptographic operators look like ordinary query implementations. The README states that it provides flexibility for researchers to implement algorithms for processing federated queries with SMC techniques, such as secret sharing, garbled circuit and oblivious transfer, and that this lets them run experimental evaluation on benchmark datasets to obtain the performance of the designed algorithms.

The mapping is visible in the supported query types: filter, projection, equi and theta join, cross products, aggregate including group-by, limited window aggregates, distinct, sort, limit, common table expressions, and a spatial block with range query, range counting, knn query, distance join and knn join. Aggregate and join are where the SMC operators get selected, and the operator choice is configuration, not code, which is what makes the same query comparable across implementations.

The evaluation metrics listed in the README match that framing: communication cost, and running time broken into total query time, local query time, encryption time and decryption time. Separating encryption and decryption time tells you whether a design is bottlenecked by the cryptography or by the query itself.

Plugging in your own operator through the owner implementor config

Extension happens at the owner side, and the README describes it in two steps: write your algorithm, then point the configuration at it.

An aggregate function extends com.hufudb.openhufu.owner.implementor.aggregate.OwnerAggregateFunction, and the class must contain a constructor with the parameters OpenHuFuPlan.Expression, Rpc, ExecutorService and OpenHuFuPlan.TaskInfo. A join implements com.hufudb.openhufu.owner.implementor.join.OwnerJoin.

The wiring is a YAML block in the owner configuration, and the README gives this example:

openhufu:
    implementor:
      aggregate:
        sum: com.hufudb.openhufu.owner.implementor.aggregate.sum.SecretSharingSum
        max: null
        min: null
      join: com.hufudb.openhufu.owner.implementor.join.HashJoin

The null entries are meaningful. Setting max and min to null means no operator is registered for those aggregates, so a query using them has nothing to dispatch to. The default sum is a secret sharing implementation and the default join is a hash join, which gives you a baseline pair to benchmark a new operator against.

That the operator registry is per aggregate function and per join means every secure primitive you add becomes selectable by name in the query, which is how the framework supports comparing several SMC schemes on the same workload.

Building on Linux or macOS with Java 11 and Maven

The build prerequisites are spelled out: Linux or MacOS, Java 11, Maven with version at least 3.5.2, C++ for generating TPC-H data, Python3 for spatial data, and Git with Git LFS for the large files.

Cloning is the usual first step:

git clone https://github.com/BUAA-BDA/OpenHuFu.git

Large files are pulled through Git LFS, and the build itself is a shell script:

cd OpenHuFu
bash scripts/build/package.sh

After that OpenHuFu is installed in the release directory. macOS users need one extra step: the README says to add a macos profile to the maven settings.xml so that the detected classifier becomes osx-x86_64, which tells the native build which platform to target.

The build runs through Maven, and the repository layout shows the module split clearly: adapter, benchmark, common, core, data, dataset, docker, dp, mpc, owner, plan, proto, release, rpc, scripts, udf and user. The mpc and dp directories correspond to the two technique families, plan holds the query plan, and proto and rpc carry the inter-party protocol.

Generating TPC-H and synthetic spatial data for experiments

Benchmark data is part of the repository, and two generators are documented.

For relational data the flow is to extract TPC-H with a script, build the dbgen utility, then run a generator script that takes the number of databases and the volume of each in megabytes. The dbgen step needs a C++ toolchain, and the README notes a macOS specific fix, replacing a malloc.h include with the sys variant in dbgen.

For spatial data the generator is a Python script that takes the number of databases, the data size, and optionally a distribution name and parameters:

pip3 install numpy
python3 scripts/test/genSyntheticData.py databaseNum dataSize [distribution name] [params]

Three distributions are documented: uniform with low and high bounds, normal with mu and sigma, and exponential with mu. Defaults are given for each parameter, and the README says the script can be modified if you need something else. A small spatial sample ships as dataset/newyork-taxi-sample.data.

Each generated table is described by two files, one in CSV and one in SCM format, and the file names become the table names. The CSV holds column names and data, the SCM holds column names and column types, and the delimiter is configurable in the owner's configuration file. That file pair convention is worth knowing before you write a loader, because the platform reads the pair rather than a schema.

Running three owners locally and measuring communication cost

Sample configurations for three owners live in the release/config folder. You can run the demo on a single machine with the bundled script, or edit the configuration files to deploy across several machines. One detail matters: the configuration files use relative paths, so you have to cd into release before running anything.

Benchmarks have their own entry point:

bash benchmark.sh

Communication cost, the metric that matters most for secure computation, is measured with a separate pair of scripts. The monitor has to run as root, and the port is passed as an argument:

sudo bash scripts/test/network_mmonitor/start.sh 8888

The script then calculates the cost from what the monitor captured:

sudo bash scripts/test/network_mmonitor/monitor.sh

Running these as root on a shared machine is worth thinking about before you do it, since the scripts are invoked with sudo purely to capture raw socket traffic. Running the owners as separate processes on one host also means they share a machine, which inflates the local query time relative to a real distributed deployment.

The documentation gaps that will slow you down

Several sections of the README are headings with nothing under them. The Configuration File section has OwnerSide and UserSide as bare headings, so the full set of configuration keys is not written down anywhere in the README. The Data Query Language section lists Plan and Function Call and stops. The OwnerSide and UserSide split is the right shape for a two-sided protocol, but you will be reading the sample YAML in release/config to learn the keys, and those are samples for three owners rather than a specification.

The security story is also worth reading carefully, because this is a system whose purpose is to keep raw data from moving. The README mentions differential privacy as one of the techniques it draws on, and the repository has a dp module, but it does not document the noise mechanism, the privacy budget accounting, or the configuration of epsilon. Differential privacy without a documented budget is not something you would want to claim to a regulator.

The last push to the repository was on 2026-07-23, and the only tagged release is v1.0.0 from 2023-03-01. The project is licensed Apache-2.0, so use is unrestricted, but the gap between the release and current commits means you are likely running unreleased code, and there is no upgrade note in the README describing what changed since v1.0.0.

Editorial conclusion

OpenHuFu is a good fit for research groups that need to prototype and measure secure federated query algorithms, especially spatial ones, and for teachers who want a concrete codebase behind a published VLDB paper. It is a poor fit for a production federation, because the query plan format, the owner configuration and the data query language are all documented only as section headings, and because the only tagged release is v1.0.0 from 2023-03-01. Before committing, generate a small dataset with scripts/test/generateData.sh, run the three-owner demo from release/config with bash owner_all.sh, and check that the owner.yaml implementor keys match the SMC operators you intend to benchmark.

Frequently asked questions

Official sources

1. BUAA-BDA/OpenHuFu on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases