Swift Homomorphic Encryption

Understanding homomorphic encryption (HE)

• Several commenters struggle to “grok” how computation on encrypted data can work.
• Others give intuitive explanations: simple modular “add 1” encryption; scaling numbers by a secret factor; and the role of algebraic structures like rings and finite fields.
• Examples show how operations like addition/multiplication can be preserved under encryption without revealing underlying values.

Existing and related real-world uses

• HE (or related techniques) is already used in password leak checking: Edge Password Monitor, Google reCAPTCHA Enterprise; Safari reportedly uses k‑anonymity instead.
• Some products mention HE but may actually use different approaches (e.g., Cipherstash says they do not use HE).
• There are references to HE used for ML, image processing, and previous demos, though usually too slow for broad deployment.

Apple Live Caller ID & PIR

• Core use case: checking incoming numbers against a spam/identity database without revealing to Apple who is calling.
• Discussion frames this as Private Information Retrieval (PIR) over a (plaintext) server database, with responses encrypted under the client’s key.
• A simple HE-based PIR example is given (one-hot queries over all rows).
• In practice, the server must touch the whole shard to avoid leaking which row is queried. Sharding leaks a few hash bits but improves performance.
• Debate over enumeration: phone numbers are low-entropy, but HE + PIR hides which number was queried, not the database contents.

Security properties and limitations

• Clarification of algebraic background: rings vs fields, finite fields modulo primes, multiplicative inverses.
• Swift HE uses the BFV leveled HE scheme (limited-depth add/mul, no bootstrapping).
• HE is incompatible with strong IND‑CCA2 security by design; discussion mentions weaker models (CCA1, variant notions).
• Failure mode is like symmetric crypto: if the scheme or key is broken, past ciphertexts can be decrypted. Concern raised that HE might encourage broader sharing of sensitive encrypted data, increasing impact of future breaks.

Performance and practicality

• HE described as many orders of magnitude slower than normal code; at least ~10⁴× slower is cited.
• Compared with TEEs/secure enclaves: those are simpler and faster but have been repeatedly broken and don’t protect against compelled server-side access.
• Some think HE is still too slow for general computation, but targeted use cases (like caller ID or leak checking) are now practical.

Trust, threat models, and use cases

• HE/PIR mainly protects against a curious or compelled server learning user queries; the database itself need not be secret.
• Skeptics note that if client and server software come from the same vendor, that vendor could silently bypass HE. Others point out practical constraints and reputational risks.
• HE seen as especially important for PII-heavy AI and for computing on untrusted infrastructure where you still trust the client.