swift-homomorphic-encryption puts BFV and PIR in a Swift package

What the BFV scheme actually does for a client and a server

Homomorphic encryption is described in the documentation as a cryptosystem that enables computation on encrypted data, with the computation performed directly on the encrypted data without revealing the plaintext to the operating process, and without decryption or access to the decryption key.

The four step workflow is the same in every deployment. The client encrypts its sensitive data and sends the ciphertext to the server. The server computes on that ciphertext, possibly combined with its own plaintext inputs, without learning what anything decrypts to. The server returns the resulting ciphertext, and the client decrypts it to learn the answer. The server is never in a position to read the data it processed.

Underneath, the package implements the Brakerski-Fan-Vercauteren scheme, which is based on the ring learning with errors hardness problem, and the documentation states the scheme can be configured to support post-quantum 128-bit security. That configuration claim matters for planning: the choice of parameters is yours to make, and the security level does not follow automatically from using the library.

The noise budget is a secret, not a diagnostic

The strongest paragraph in the documentation is a warning, and it deserves to be read twice.

BFV does not provide IND-CCA security, and it does not provide IND-CPA with decryption security when there is a non-negligible decryption error probability. The documentation says BFV should be used accordingly, then gives two concrete instructions. No information about each decrypted ciphertext should be sent back to the server. In particular, the noise budget of a ciphertext, computed via noiseBudget, must not be forwarded to any other party, because sharing the decrypted ciphertext or the noise budget acts as an oracle that can be used to recover the secret key.

The third instruction covers the defence against a malicious server: the client should validate that the decrypted content is in the expected format. And the warning closes by telling you to consult a cryptography expert when developing and deploying homomorphic encryption applications.

This is the real interface of the library. A developer who treats the noise budget as a number to log or to send in a response for diagnostics has turned a security parameter into a key leak, and no amount of correct ciphertext handling elsewhere in the application protects against that.

PIR: the server never learns the keyword

Private information retrieval is the first application built on top of the encryption, and the problem it solves is specific. A client wants to look up a value in a keyword-value database on a server without the server learning which keyword was queried.

The documentation is honest about the naive version. A trivial implementation sends a generic fetch database request independent of the private keyword, and the server returns the whole database. That satisfies the privacy and correctness requirements of PIR, but it is only feasible for small databases. The PIR implementation in the package uses homomorphic encryption to improve on it, so the query is encrypted and the server computes over the database without learning the keyword.

There is a second warning here, and it is about the client rather than the server. PIR is asymmetric, meaning the client may learn keyword-value pairs it did not request, as happens in trivial PIR for instance. A variant known as symmetric PIR would be needed to ensure the client learns nothing about values it did not request, and that variant is not what this package implements. If your threat model includes protecting the client from the server's data, this is the wrong construction.

PNNS searches for nearest neighbours with a private vector

Private nearest neighbour search extends the same idea to vector data. The client holds a private vector and wants the nearest vectors in a server-hosted database, without the server learning that vector.

The data model has three parts per row: a vector, an associated entry identifier, and entry metadata. The client issues a query built from its private vector, and learns the distance between its query vector and the nearest neighbour, together with that neighbour's entry identifier and entry metadata. The distance is computed according to a DistanceMetric, which is a named type in the library rather than a convention left to the caller.

The trivial alternative follows the PIR pattern exactly: a generic fetch database request, then the client computes the distances locally. The documentation says plainly that this satisfies the privacy and correctness requirements but is only feasible for small databases. Homomorphic encryption is what makes the query selective.

Both PIR and PNNS ship as separate libraries, PrivateInformationRetrieval and PrivateNearestNeighborSearch, with their own executables for building and processing databases, so a project can take the search half without the retrieval half.

Five libraries and five command line tools

The package is a collection rather than a single target, and the split tells you how the code is meant to be composed.

The libraries are HomomorphicEncryption, which holds the scheme itself, HomomorphicEncryptionProtobuf and ApplicationProtobuf for the serialisation layers, and then the two application libraries, PrivateInformationRetrieval and PrivateNearestNeighborSearch. Documentation for each is published separately on the Swift Package Index.

The executables are the operational half. PIRGenerateDatabase, PIRProcessDatabase and PIRShardDatabase cover the database lifecycle for private retrieval, including a sharding step that exists because a single shard is not always the right unit. PNNSGenerateDatabase and PNNSProcessDatabase do the same for the vector search case, with the difference that the generate step has to embed the vectors in a form the server can search over homomorphically.

That division between generate and process is worth noting when you plan a deployment. The server side runs the process executable against a database artefact produced by the generate executable, and the client side runs the query. A production system has to plan for regenerating that artefact when the source data changes, which is an operational task the library does not hide.

Adding the package to a Package.swift manifest

The package is distributed through Swift Package Manager, and the documented approach starts with choosing a tag from the repository, then adding the dependency to your manifest:

.package(
    url: "https://github.com/apple/swift-homomorphic-encryption",
    from: "tag"),

The trailing tag is a placeholder you replace with the version you picked, and the documentation gives 1.0.0 as the example. Choosing a tag rather than tracking the default branch is the right call for a cryptographic library, and the fact that the documentation says to choose a tag at all is a small signal about how the maintainers expect the library to be consumed.

The README ends after this point, so the remaining import steps are not shown, but the library list tells you what the module names are likely to be, and the Swift Package Index pages for each library are the reference to follow. The repository also ships a Package.resolved, Snippets/, Tests/ and a Benchmarks/ directory, so the project carries its own test and benchmark material.

Apple's own use case, Apache-2.0 terms and the release line

The applications the package is built for are named in the documentation. Live Caller ID Lookup and the Network Extension URL Filter are the two platform features cited, and a sample service for the first of them lives in a separate repository, apple/pir-service-example. That tells you the intended deployment shape: the sensitive value, a phone number or a URL, stays on the device, and the service holds the lookup data.

The licence is Apache-2.0, with LICENSE.txt and NOTICE.txt at the repository root. Apache-2.0 is a permissive licence with an explicit patent grant, which is a reasonable fit for a library intended to be embedded in application code, and the NOTICE file is the part to keep if you redistribute.

On maintenance, the repository is not archived and the last push was on 2026-10-21. The three most recent releases are 1.0.7 on 2026-06-03, 1.0.6 on 2026-03-10 and 1.0.5 on 2025-11-19, so the line is on a steady quarterly cadence with patch releases. The repository also carries CITATION.cff, a CODEOWNERS file and a set of linting and formatting configurations including.swift-format,.swiftlint.yml,.yamllint.yml and a pre-commit config, which is what you would expect from a library maintained as a long-lived Apple project rather than a research artefact.

Editorial conclusion

swift-homomorphic-encryption fits an Apple platform team that needs to query a server holding private data without revealing the query, particularly for caller ID or URL filtering where the client holds the sensitive value and the server holds the database. It does not fit anyone treating it as a general purpose encryption library, since the scheme is not IND-CCA secure and the noise budget is a secret. Before deploying anything built on it, read the noise budget warning, decide whether you can avoid returning any decrypted value or budget to the server, validate decrypted content against the expected format, and take the cryptography review the documentation asks for.

Frequently asked questions

Official sources

1. apple/swift-homomorphic-encryption on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases