Swift Homomorphic Encryption makes private lookups a server operation

A phone-number lookup can disclose something about the caller even when the connection is encrypted. The service still normally receives the number it must search for. Swift Homomorphic Encryption changes that relationship by allowing the service to compute over an encrypted query without receiving its decryption key.

The July 30 announcement introduces an open source Swift package and a companion backend example for Live Caller ID Lookup. The concrete use case is retrieving information about a phone number without revealing that number to the server handling the query. It gives a practical setting for a cryptographic capability that is otherwise easy to describe too broadly.

I am interested in the division of responsibility this permits. Swift's ordinary type system helps explain what code may do with a value inside a process. Homomorphic encryption addresses a different boundary, allowing a remote process to perform selected work without obtaining the underlying input in plaintext.

Transport encryption leaves the server informed

The workflow described in the announcement begins with the client encrypting sensitive data. Server computation uses that ciphertext, possibly alongside the server's own plaintext inputs, and produces an encrypted result. The client decrypts the response. Processing the request never requires the server to decrypt it.

This differs from the familiar arrangement in which encrypted transport terminates at the service and ordinary application code handles plaintext. Homomorphic computation preserves encryption through the server-side calculation itself. The protected input therefore remains unavailable to that operating process in the protocol described by the announcement.

That does not establish that every aspect of a request is hidden. The claim concerns the plaintext represented by the ciphertext and the absence of the decryption key at the server. Network identity and other protocol details require their own analysis. A private keyword lookup should not be described as automatically making the whole communication anonymous.

The operation also needs a cryptographic design compatible with computation on ciphertexts. A server cannot simply run its existing arbitrary plaintext handler against encrypted bytes. The package supplies an implementation of a homomorphic encryption scheme, while the caller-ID example supplies a particular application protocol built using it.

Private retrieval avoids copying the whole database

The announcement describes private information retrieval as looking up a value using a keyword that the server must not learn. A phone number is one such keyword. The client wants the associated record, while the database remains at the service.

Sending the whole database to every client would permit private local searches. The service would not see which entry the client chose. The announcement identifies the practical limitation, since this works only for small databases with infrequent changes. A large database with frequent updates makes that distribution strategy unattractive.

The described homomorphic approach synchronizes a small amount of database metadata instead. That metadata changes infrequently, allowing the server's database to receive updates without forcing each client to obtain the whole dataset. The encrypted request then supplies the information needed for private retrieval.

This identifies the operational reason for doing remote encrypted computation. Privacy through a local copy and privacy through an encrypted remote query have different distribution costs. The announcement supplies the latter design for a service whose database may be too large or change too often for full client replication.

BFV is a specific mathematical construction

The implementation uses the Brakerski-Fan-Vercauteren scheme, or BFV. The announcement connects its security to the ring learning with errors hardness problem. It also states that Live Caller ID Lookup requires BFV parameters offering post-quantum 128-bit security. Those are requirements on the selected parameters, not a guarantee conferred by importing the Swift module.

The underlying Fan and Vercauteren paper, received in 2012, develops the construction in the ring-LWE setting. Its abstract discusses homomorphic multiplication and relinearisation, together with bounds on noise introduced by operations. This is a useful reminder that encrypted arithmetic has constraints beyond the apparent plaintext computation.

Parameter selection connects the supported computation to a security target. The release announcement's smallest example explicitly uses insecure parameters for testing. It therefore cannot be copied into a deployed privacy service and treated as equivalent to the caller-ID configuration.

The paper's account of arithmetic also does not establish that the Swift package implements every technique discussed in that paper. BFV is the scheme identified in the package announcement. Its example demonstrates the public Swift interface for encoding, encryption and decryption, without proving the performance or supported depth of an arbitrary computation.

Encoding and encryption are separate steps

The Swift example constructs encryption parameters and a context. It then encodes an array of unsigned integers in coefficient format. Only after creating that plaintext representation does it generate a secret key and encrypt the encoded value.

Decrypting returns a plaintext representation, which is decoded back into the integer array. These distinctions make the API's responsibilities visible. Encoding establishes the representation used by the scheme. Encryption protects that representation under a key. Decoding interprets the decrypted representation as application values.

The announcement's sample verifies that the decoded values equal the original ones. That establishes an encryption round trip for the chosen test parameters. It does not itself demonstrate a complete private lookup or a server-side arithmetic operation. Those application concerns belong to the companion example and the larger protocol.

I prefer this explicit presentation to hiding parameter choice behind an apparently universal encrypt function. The insecure test configuration is clearly identified. It gives readers a way to learn the API without confusing a small demonstration with the security settings required by an actual service.

The server example supplies integration context

The accompanying backend uses the Hummingbird HTTP framework and Swift's server ecosystem. The announcement also identifies Swift Crypto for low-level cryptographic operations and the Benchmark library for performance work. This connects the cryptographic implementation to the code needed to expose an application service.

The authors suggest other possible applications, including private set intersection and secure aggregation. Those are directions for using the capability, not evidence that this release supplies a finished service for each one. The concrete integration provided with the announcement is Live Caller ID Lookup.

For that application, the resulting architecture keeps the lookup database remote while hiding the query keyword during computation. Clients need synchronized metadata and the key material required by their side of the protocol. The server operates on the encrypted query and returns a response the client can decrypt, without needing the query's plaintext to select the corresponding information.