Fully Homomorphic Encryption 2026: Was shipped und was noch Hype ist

Fully Homomorphic Encryption hat den seltsamsten Ruf in der angewandten Kryptographie: gleichzeitig "der heilige Gral" und "für immer zehn Jahre entfernt". Beide Rufe sind inzwischen falsch. FHE läuft heute auf Hunderten Millionen iPhones, prüft Passwörter in Microsoft Edge und settelt verschlüsselte Transaktionen auf Ethereum. Sie ist außerdem noch immer drei bis vier Größenordnungen langsamer als Klartext, was das meiste ausschließt, wofür Leute sie sich vorstellen. Dieser Post zieht die Linie präzise: was FHE 2026 in Produktion leistet, was die ehrlichen Zahlen sind, und welche Claims du abwerten solltest. Der begleitende pragmatische Guide behandelt, wann FHE überhaupt das richtige Werkzeug ist.

Engineering-Perspektive, kein Vendor-Pitch. Wo eine Zahl von einem Hersteller stammt oder eine Roadmap-Projektion statt eines ausgelieferten Ergebnisses ist, kennzeichnen wir sie. Die Referenzpunkte stammen aus Wavects Frontier-Tech- und KI-Arbeit.

Was ist FHE, und warum wurde sie plötzlich interessant?

FHE lässt einen Server auf verschlüsselten Daten rechnen, ohne sie je zu entschlüsseln. Der Client verschlüsselt den Input, der Server rechnet blind, und nur der Client kann das Ergebnis entschlüsseln. Der Server erfährt nichts, nicht einmal die Antwort. Das ist ein kategorisch stärkeres Versprechen als Verschlüsselung at rest, und stärker als ein Trusted Execution Environment, weil kein Hardware-Hersteller im Trust Model steckt.

Interessant wurde sie aus zwei Gründen. Erstens Performance: Eine TFHE-Bootstrapping-Operation, die Grundeinheit unbegrenzter verschlüsselter Berechnung, fiel von Dutzenden Millisekunden auf einer CPU auf unter eine Millisekunde auf einer NVIDIA H100. Zweitens Glaubwürdigkeit: Apple shipped sie in Consumer-Skala, und Zama wurde mit einer 57-Millionen-Dollar-Series-B bei einer Bewertung über 1 Milliarde Dollar im Juni 2025 das erste Unicorn des Felds (Zama). Geld und Produktions-Deployments haben das Gespräch verändert.

Welches Scheme für welchen Job?

"FHE" ist eine Familie, und das falsche Mitglied zu wählen ist ein häufiger erster Fehler:

Daumenregel: Logik und Vergleiche wollen TFHE, ML will CKKS, exakte Lookups wollen BFV. Eine gute Einführung in die Schemes ist das 2025 erschienene "Beginner's Textbook for Fully Homomorphic Encryption" (arXiv 2503.05136). Moderne Stacks wechseln zunehmend mitten in der Berechnung das Scheme, genau dafür gibt es Compiler-Projekte wie Googles HEIR.

Was shipped tatsächlich in Produktion?

Die Produktionsliste ist kurz, real und lehrreich:

• Apple Live Caller ID Lookup (iOS 18+). Dein iPhone prüft einen unbekannten Anrufer gegen die Datenbank eines Caller-ID-Anbieters, ohne dem Server die Telefonnummer zu verraten, mit BFV-basiertem Private Information Retrieval. Apple hat den Stack als swift-homomorphic-encryption open-sourced (Swift.org, 2024). Zusammen mit Enhanced Visual Search unten ist das vermutlich der größte Consumer-FHE-Footprint überhaupt.
• Apple Enhanced Visual Search. Photos matcht Sehenswürdigkeiten in deinen Bildern gegen einen Server-Index, mit FHE plus Differential Privacy. Kryptographisch exzellent, und trotzdem eine Consent-Fallstudie: Apple aktivierte es per Default, ohne zu fragen, und kassierte im Januar 2025 einen berechtigten öffentlichen Backlash (The Register). Privacy-Tech entschuldigt kein übersprungenes Opt-in.
• Microsoft Edge Password Monitor. Prüft deine Credentials homomorph gegen Breach-Korpora, sodass Microsoft das Passwort nie sieht. Gleiche architektonische Form wie Apples Deployment: ein Private Set Lookup.
• Zama Protocol auf Ethereum. Mainnet seit Dezember 2025, ermöglicht verschlüsselte Token-Balances und vertrauliche Transfers auf öffentlichen Chains via TFHE (Zama Docs). Der Durchsatz liegt heute bei Dutzenden Transaktionen pro Sekunde; die veröffentlichte Roadmap Richtung Tausende via FPGAs und ASICs ist eine Projektion, kein ausgeliefertes Ergebnis.
• Enterprise-Datenkollaboration. Duality Technologies betreibt homomorphe und föderierte Analytics mit Healthcare-Partnern wie Dana-Farber, typischerweise als Kombination aus HE und Federated Learning statt alles unter FHE laufen zu lassen.

Beachte, was jedes Consumer-Deployment gemeinsam hat: Es ist ein Private Lookup gegen ein Server-Dataset, in der Literatur als Private Information Retrieval bekannt. Kleine Query, begrenzte Berechnung, asynchron-tolerante Latenz. Das ist das Muster, das shipped. Niemand betreibt sein Backend unter FHE, auch nicht die Firmen mit dem meisten Geld der Welt.

"Jedes FHE-Deployment, das wirklich shipped ist, ist ein enger Private Lookup. Die Teams, die scheitern, sind die, die das ganze Backend verschlüsseln wollen."

Wie langsam ist FHE wirklich?

Die ehrlichen Zahlen, Stand Mitte 2026:

• Genereller Overhead: grob 1.000x bis 10.000x gegenüber derselben Berechnung in Klartext, je nach Scheme und Workload. Additionen sind billig, Multiplikationen und Vergleiche teuer.
• TFHE-Bootstrapping: einstellige Millisekunden auf einem modernen CPU-Kern, unter einer Millisekunde auf einer GPU der H100-Klasse, mit Berichten von rund 189.000 Bootstraps pro Sekunde auf einem 8-GPU-Node (Hersteller-Zahl).
• Small-Model-ML-Inferenz: Logistische Regression, Decision Trees und kleine neuronale Netze laufen in Sekunden unter CKKS oder via Zamas Concrete ML, das quantisierte Modelle konvertiert und die Genauigkeit bei 4-Bit-Quantisierung innerhalb weniger Punkte von Klartext hält (Hugging Face / Zama).
• PIR in Skalierung: heute praktikabel. Apple beantwortet verschlüsselte Lookups für einen großen Teil der iPhones der Welt mit akzeptabler Latenz und Serverkosten.

Plane mit der 1.000x-Regel: Braucht die Klartext-Berechnung eine Mikrosekunde, braucht die verschlüsselte Version eine Millisekunde und ist vermutlich machbar. Braucht die Klartext-Version eine Sekunde, braucht die verschlüsselte Version aufwärts von 15 Minuten und ist kein Produkt.

Kannst du ein LLM unter FHE laufen lassen?

Nein, nicht interaktiv, und diese Sektion existiert, weil die Zahlen, die am häufigsten als Gegenbeweis zitiert werden, auf lehrreiche Weise falsch sind. Die weit verbreitete Zahl "8,2 Minuten pro Token für GPT-2 mit 25,3 GB Kommunikation" stammt aus Forschung zu Secure Two-Party Computation, nicht FHE (arXiv 2410.13060). Die Gigabytes an Netzwerk-Traffic sind das verräterische Detail: MPC verbrennt Bandbreite zwischen Parteien, während FHE lokale Rechenleistung verbrennt, mit fast keiner Kommunikation. Die beiden zu verwechseln ist der häufigste technische Fehler in Content über Private AI.

Das tatsächliche FHE-Bild: GPU-beschleunigte Forschung lässt einen Forward Pass der GPT-2-Klasse grob 200x schneller laufen als CPU-Baselines (ICML 2025), was immer noch weit von interaktivem Chat entfernt ist. Hybride Schemes (Attention-Layer im Klartext, sensible Layer verschlüsselt) tauschen Privacy gegen Geschwindigkeit und bleiben Forschung. Was in Produktionsbegriffen funktioniert, ist Small-Model-Inferenz auf wirklich sensiblen Daten: Credit Scoring, medizinisches Pre-Screening, Fraud-Signale, wo ein paar Sekunden Latenz auf einem begrenzten Modell akzeptabel sind. Brauchst du heute private Frontier-Model-Inferenz, ist die pragmatische Antwort eine Confidential GPU (TEE der NVIDIA-H100-Klasse), und diese Trust Models vergleichen wir im Decision-Framework-Post.

Wird Hardware den Overhead beheben?

Teilweise, auf einer glaubwürdigen Timeline:

• Heute lieferbar: GPUs. Die Unter-einer-Millisekunde-Bootstrap-Zahlen oben sind real und heute reproduzierbar, während Zamas Mainnet seine Coprozessoren weiterhin auf CPUs bei Dutzenden Transaktionen pro Sekunde betreibt, mit der GPU-Migration auf der 2026er-Roadmap. GPU-Beschleunigung liefert ein bis zwei Größenordnungen und ist die einzige Beschleunigung, die du jetzt kaufen kannst.
• Prototyp-Silizium: Intel HERACLES. Intel demonstrierte im Februar 2026 auf der ISSCC einen gefertigten 8192-Way-SIMD-FHE-Beschleuniger und meldete über sieben Primitive hinweg 1.074x bis 5.547x Speedup gegenüber einem Xeon (IEEE Spectrum). Das korrigiert zwei gegensätzliche Fehler: HERACLES wurde nicht eingestellt und ist nicht mehr bloß eine Simulation. Es bleibt aber ein Forschungsprototyp ohne angekündigte kommerzielle Verfügbarkeit. Architektiere daher für heute einsetzbare GPUs und behandle ASICs als künftiges Upside.

Mit welcher Library solltest du starten?

Default-Picks: TFHE-rs für Logik, Apples Library für PIR und ein Workload-Benchmark vor jeder CKKS-Entscheidung. Starte den CPU-Bake-off mit Poulpy, Lattigo, SEAL und OpenFHE; nimm eine GPU-native Library wie FIDESlib dazu, wenn NVIDIA-Deployment passt. OpenFHE bleibt wertvoll für Breite und Interoperabilität, doch spezialisierte Libraries können auf wichtigen CKKS-Pfaden ein bis zwei Größenordnungen schneller sein. Wähle nicht nach einem generischen Leaderboard: Ringgröße, Tiefe, Präzision, Bootstrapping-Häufigkeit, Batch-Größe und Zielhardware müssen deinem echten Workload entsprechen.