ZK vs FHE vs MPC vs TEE: Wie du 2026 wählst

Vier Technologien konkurrieren inzwischen um dieselbe Architektur-Folie: Zero-Knowledge-Proofs, Fully Homomorphic Encryption, Secure Multi-Party Computation und Trusted Execution Environments. Sie werden routinemäßig als austauschbare "Privacy-Tech" präsentiert, was sie nicht sind. Sie beantworten unterschiedliche Fragen, kosten wild unterschiedlich viel und scheitern auf unterschiedliche Weise. Dieser Post ist der Vergleich, den wir uns wünschen würden, wenn Kunden fragen "welche brauchen wir": Trust Models, ehrliche 2026er-Performance-Zahlen und die EU-Regulierungen, die die Wahl zunehmend erzwingen. Für die volle Build-Methodik starte mit unserem pragmatischen Guide zu ZK und FHE.

Engineering-Perspektive, kein Vendor-Pitch. Alle Zahlen sind belegt oder als Daumenregeln gekennzeichnet. Die Referenzpunkte stammen aus Wavects Zero-Knowledge- und Frontier-Tech-Arbeit.

Was tut jede Technologie eigentlich?

• Zero-Knowledge-Proofs (ZK): beweisen, dass eine Aussage wahr ist, ohne die Evidenz offenzulegen. Der Verifier erfährt "diese Person ist über 18" oder "diese Berechnung lief korrekt", sonst nichts. Siehe unser Glossar und den Produktions-Deep-Dive.
• Fully Homomorphic Encryption (FHE): auf verschlüsselten Daten rechnen. Der Server, der deine Query verarbeitet, sieht nie die Query, die Daten oder das Ergebnis. Deep Dive: was in FHE shipped.
• Secure Multi-Party Computation (MPC): Mehrere Parteien berechnen gemeinsam ein Ergebnis über Inputs, die keine von ihnen offenlegt. Drei Krankenhäuser berechnen eine gemeinsame Statistik; kein Krankenhaus sieht die Patienten eines anderen.
• Trusted Execution Environments (TEE): hardware-isolierte Enklaven (Intel TDX, AMD SEV-SNP, NVIDIA Confidential GPUs), die Klartext-Berechnungen selbst für den Cloud-Betreiber unsichtbar ausführen, mit einer kryptographischen Attestation, dass der erwartete Code läuft.

Am saubersten ordnest du sie danach, was du zu vertrauen aufgefordert wirst. ZK vertraut nur der Soundness eines Proof-Systems. FHE vertraut Lattice-Kryptographie. MPC vertraut darauf, dass ein Schwellenwert der beteiligten Parteien nicht kolludiert. TEE vertraut dem Design und der Supply Chain eines Chip-Herstellers, plus dem fortgesetzten Ausbleiben von Side-Channel-Breaks. Jede Stufe zusätzlichen Vertrauens kauft dir zwischen einer und vier Größenordnungen Performance. Architektur heißt, deine Sprosse zu wählen, nicht Sicherheit im Abstrakten zu maximieren.

Welche vier Fragen wählen die Technologie?

1. Wer darf die Daten nicht sehen? Lautet die Antwort "niemand außerhalb unserer Firma", stopp: Access Control, TLS und Verschlüsselung at rest lösen das, und jede Technologie auf dieser Seite ist Overkill. Lautet die Antwort "der Betreiber der Berechnung", lies weiter.
2. Ist der Kernbedarf Verifikation oder Berechnung? Muss eine dritte Partei etwas prüfen (ein Alter, eine Reserve, die Integrität einer Berechnung), ist das ZK, Punkt. Muss eine nicht vertrauenswürdige Partei etwas auf versteckten Daten berechnen, ist es FHE, MPC oder TEE.
3. Wie groß ist die versteckte Berechnung? Ein Lookup, ein Score, ein kleines Modell: FHE liegt auf dem Tisch. Eine Datenpipeline, ein LLM, alles, worauf ein User interaktiv wartet: realistischerweise TEE, weil der FHE-Overhead von 1.000x bis 10.000x nicht aufgeht.
4. Wie viele unabhängige Parteien halten die Inputs? Ein Client und ein Server favorisieren FHE oder TEE. Mehrere sich gegenseitig misstrauende Organisationen mit ordentlichen Netzwerkverbindungen favorisieren MPC, das genau für diese Form gebaut wurde und übers öffentliche Internet leidet, wo seine Kommunikationskosten zubeißen.

Wie vergleichen sie sich Seite an Seite?

"Niemand wird gefeuert, weil er ein TEE gewählt hat, und meistens liegen sie damit richtig. Die teuren Fehler passieren, wenn ein Team FHE für einen Workload wählt, den ein TEE tragen sollte, oder ein TEE für ein Versprechen, das nur Mathematik halten kann."

Wie gut sind TEEs inzwischen, ehrlich?

Gut genug, dass sie die Default-Antwort für Confidential Compute in Skalierung sind, weshalb die kryptographischen Optionen eine klare Begründung brauchen, um sie zu verdrängen:

• CPU-Enklaven sind gereift. Intel TDX und AMD SEV-SNP haben die Isolationseinheit vom Prozess auf die ganze VM verschoben, was die Integrationskosten gegenüber dem alten SGX-Modell dramatisch senkt. Der Overhead auf typischen Workloads liegt im niedrigen bis mittleren einstelligen Prozentbereich, wobei speichergebundene und sehr kleine Workloads mehr zahlen.
• GPUs sind dazugekommen. NVIDIAs H100 war die erste Confidential-Computing-GPU, fortgeführt über die H200- und Blackwell-Generationen. Confidential LLM-Inferenz shipped inzwischen als Cloud-Produkt, mit Fine-Tuning auf denselben Confidential-GPU-VMs möglich, und der Overhead wird oft von verschlüsselten PCIe-Transfers dominiert statt vom Compute (arXiv 2505.16501).
• Der Trust-Haken bleibt. Ein TEE beweist, dass du den erwarteten Code auf echter Hardware ausführst. Es kann dich nicht vor einem kompromittierten Hersteller schützen, vor bestimmten physischen Angriffen oder dem steten Tropfen veröffentlichter Side-Channel-Papers. Für die meisten kommerziellen Threat Models ist dieses Restrisiko akzeptabel. Für "wir müssen unfähig sein, einer Subpoena nach Userdaten nachzukommen" ist es das nicht, und genau das ist die Linie, an der FHE und MPC ihren Overhead verdienen.

Warum ist das Gewinner-Muster Komponieren statt Wählen?

Die stärksten 2026er-Architekturen stapeln diese Tools, statt eines zu wählen:

• TEE für die Masse, Kryptographie für den Kern. Lass die schwere Pipeline in einer Confidential VM laufen und reserviere FHE oder MPC für die kleine Berechnung mit hohem Einsatz, bei der Hardware-Vertrauen inakzeptabel ist.
• ZK obendrauf für Verifizierbarkeit. Ein TEE oder MPC-Cluster rechnet; ein ZK-Proof überzeugt Außenstehende, dass die Berechnung korrekt war, ohne sie erneut auszuführen. Verifikation bleibt für alle Downstream-Beteiligten billig.
• Echte Beispiel-Formen: ein Confidential-GPU-Inferenz-Service, der eine ZK-Attestation zurückgibt, welche Modellversion lief; ein MPC-Konsortium, dessen Ergebnis mit einem Proof kommt, den Regulierer prüfen können; ein FHE-Lookup in einer ansonsten konventionellen App, was buchstäblich die Art ist, wie Apple es shipped.

Projekte wie Nillion orchestrieren MPC, HE und ZK hinter einer Developer-Oberfläche, und das Muster "TEE als billiger Rahmen um kryptographische Kerne" zeigt sich quer durch ernsthafte Deployments. Komposition de-riskt auch die Roadmap: Du kannst dieses Quartal auf einem TEE starten und den Kern auf FHE umstellen, wenn die Zahlen aufgehen, ohne das Produkt neu zu schreiben.

Was erzwingt EU-Regulierung, und wann?

Für EU-gerichtete Produkte macht Regulierung dieses Menü still zur Pflichtlektüre:

• eIDAS 2.0 / EUDI Wallet, Deadline Ende 2026. Jeder Mitgliedstaat muss ein digitales Identitäts-Wallet anbieten, gebaut um selektive Offenlegung. Das ist ZKs Heimspiel. Eine scharfe Kante: Die fortgeschrittenen unlinkbaren Verfahren (BBS-Familie, ZK-SNARK-Credentials) sind noch nicht SOG-IS-zugelassen, was sie derzeit aus Public-Sector-Deployments heraushält; die Details stehen in unserem ZK Deep Dive.
• EHDS (European Health Data Space). Die Sekundärnutzung von Gesundheitsdaten stützt sich explizit auf Privacy-Enhancing Technologies und zieht HE, MPC und föderierte Muster in Health-Data-Plattformen.
• DSGVO. Ob FHE-verarbeitete oder ZK-verifizierte Daten als anonymisiert gelten, ist eine offene juristische Debatte, keine gefestigte Doktrin. PETs stärken deine Data-Protection-by-Design-Story nach Artikel 25; sie nehmen Daten nicht automatisch aus dem DSGVO-Scope. Hol juristischen Rat, bevor Marketing-Claims dem Recht davonlaufen. Unser Post zu EU-Datenresidenz für KI-Apps deckt das angrenzende Terrain ab.
• Finance (DORA) und der AI Act addieren Resilienz- und Governance-Druck, der attestierbare, vertrauliche Infrastruktur begünstigt, was in der Praxis TEEs zuerst bedeutet, mit kryptographischen Upgrades dort, wo Aufseher stärkere Garantien verlangen.

Das Muster über allem: Regulierer schreiben keine bestimmte Kryptographie vor, sie schreiben Eigenschaften vor (Minimierung, selektive Offenlegung, Vertraulichkeit), die dieser Werkzeugkasten nun mal als einziger in Skalierung liefern kann.

Wann gewinnt schlichte Access Control?

Öfter, als die Existenz dieses Posts vermuten lässt. Wähl langweilige Technologie, wenn:

• Alle Parteien, die die Daten anfassen, sich bereits vertraglich vertrauen (eine Firma, ein AVV, eine Cloud).
• Das Privacy-Versprechen Marketing ist, nicht Architektur. User zahlen selten für kryptographische Garantien, die sie nicht wahrnehmen können; sie zahlen für Produkte, die funktionieren.
• Die sensible Berechnung groß, interaktiv und latenzgebunden ist und keine Regulierung die Frage erzwingt. Ein TEE plus striktes IAM plus Audit-Logging ist eine vertretbare, shippbare Antwort.
• Dein Team die Observability, das Key Management und die Audit-Kadenz noch nicht betreiben kann, die kryptographische Deployments verlangen. Die Mathematik ist der leichte Teil; die operative Reife ist der schwere.