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 eine Aussage, ohne die ausgewählten Witness-Daten offenzulegen. Der Verifier kann "diese Person ist über 18" oder "diese Berechnung lief korrekt" erfahren, zusätzlich aber öffentliche Inputs und beobachtbare Metadaten. Siehe unser Glossar und den Produktions-Deep-Dive.
• Fully Homomorphic Encryption (FHE): rechnet auf verschlüsselten Inputs, sodass der Evaluator Ciphertext statt geschütztem Klartext verarbeitet. Was verborgen bleibt, hängt von Funktion, öffentlichen Inputs, Output-Empfänger und Key Custody ab. Deep Dive: was in FHE shipped.
• Secure Multi-Party Computation (MPC): Mehrere Parteien rechnen gemeinsam auf privaten Inputs. Jede kennt ihren eigenen Input und erhält den autorisierten Output; die Privatsphäre hängt von Threshold und Korruptionsannahmen des Protokolls ab.
• Trusted Execution Environments (TEE): hardware-isolierte Umgebungen wie Intel TDX, AMD SEV-SNP und NVIDIA Confidential GPUs. Sie sollen Code und Daten in Nutzung vor dem Host außerhalb der Trust Boundary schützen; Attestation liefert Evidenz über den gemessenen Hardware- und Softwarezustand, abhängig von der Trust Chain der Plattform.

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. Attestation kann zeigen, dass erwarteter Code auf erkannter Hardware läuft, vorbehaltlich der Attestation- und Supply-Chain-Annahmen der Plattform. Sie beseitigt nicht jedes Hersteller-, Firmware-, Betreiber-, physische oder Side-Channel-Risiko. Ob das Restrisiko akzeptabel ist, hängt von Architektur und Rechtsraum ab. Rechtliche Resistenz-Claims brauchen juristische Prüfung und eine vollständige Datenflussanalyse, nicht nur eine TEE-Produktwahl.

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, Bereitstellung bis Ende 2026. Jeder Mitgliedstaat muss innerhalb von 24 Monaten nach den relevanten Durchführungsrechtsakten mindestens eine Wallet bereitstellen. Aktuelle offizielle Arbeit bewertet BBS-basierte und Circuit-basierte ZK-Pfade; Änderungen vom Juli 2026 zeigen, dass Standards, zertifizierte Hardware, Assurance-Level und nationale Umsetzung weiterlaufen. Leite aus einer explorativen Spezifikation 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. European Union (2026). July 2026 amendments to EUDI Wallet standards and specifications. eur-lex.europa.eu
7. NVIDIA (2026). Supported confidential-computing GPU platforms and modes. docs.nvidia.com
8. Google Cloud (2026). Supported confidential VM and GPU configurations. docs.cloud.google.com
9. Confidential GPU research (2025). Performance analysis of confidential GPU workloads. arxiv.org