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.

Vergleiche zuerst die konkreten Trust Boundaries. ZK hängt von Proof-Annahmen sowie Circuit, Compiler, Setup, Implementierung und Verifier ab. FHE hängt von Scheme, Parametern, Implementierung und Key Handling ab. MPC ergänzt eine protokollspezifische Threshold- und Non-Collusion-Annahme. Ein TEE ergänzt Hardware, Firmware, Attestation und Side-Channel-Abwehr. Daraus folgt kein fester Performance-Multiplikator; benchmarke den konkreten Stack.

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, Score oder kleines Modell kann FHE ermöglichen. Eine große Pipeline oder interaktives Modell ist zuerst ein TEE-Kandidat, sofern ein End-to-End-FHE-Benchmark auf dem echten Workload Latenz und Kosten nicht schließt.
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 isolieren ganze VMs und reduzieren damit Integrationsarbeit gegenüber SGX. Veröffentlichter Overhead variiert mit Virtualisierung, Memory, I/O, Attestation und Workload. Einstellige Ergebnisse sind kein universeller Planungswert.
• 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?

Einige 2026er-Architekturen stapeln diese Tools, statt nur 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. Komposition de-riskt die Roadmap aber nur, wenn Interfaces, Key Ownership, Datenformate und Fallback-Semantik von Anfang an auf Austausch ausgelegt sind. Von TEE zu FHE ist kein automatischer Drop-in-Swap.

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. Selektive Offenlegung ist zentral. Aktuelle offizielle Arbeit bewertet BBS- und hybride ZK-Konstruktionen, während Standardisierung, Hardware, Assurance-Level und nationale Umsetzung weiterlaufen. Leite daraus keine pauschale Zulassung oder Sperre ab.
• EHDS. Die Sekundärnutzung verlangt kontrollierten Zugriff, Pseudonymisierung oder Anonymisierung und sichere Verarbeitungsumgebungen. HE, MPC, Federated Learning oder TEEs können helfen, werden aber nicht als universelle Implementierung vorgeschrieben.
• 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.
• DORA und AI Act erzeugen Resilienz-, Evidence- und Governance-Pflichten. Sie schreiben TEE, ZK, FHE oder MPC nicht vor. Wähle die Kontrolle aus dem regulierten Prozess und dokumentiere die erfüllte Eigenschaft.

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.

Quellen und Verifikation

1. Mopro (2026). Circuit-specific proving and verification benchmarks. zkmopro.org
2. Apple Machine Learning Research (2024). Production HE and private information retrieval. machinelearning.apple.com
3. European Union (2025). Regulation (EU) 2025/327 on the European Health Data Space. eur-lex.europa.eu
4. European Digital Identity Wallet (2026). ZK proofs from multi-message signatures. github.com/eu-digital-identity-wallet
5. W3C (2026). Data Integrity BBS Cryptosuites v1.0, Candidate Recommendation Draft. w3.org
6. Confidential GPU research (2025). Performance analysis of confidential GPU workloads. arxiv.org