--- title: "ZK vs FHE vs MPC vs TEE: Wie du 2026 wählst" canonical: https://wavect.io/de/blog/zk-vs-fhe-vs-mpc-vs-tee/ language: de description: "ZK, FHE, MPC und TEE im Vergleich: vier Trust Models, vier Preisschilder. Das 2026er-Decision-Framework mit ehrlichen Performance-Zahlen und EU-Blick." image: "https://wavect.io/img/blog/headers/header_zk-vs-fhe-vs-mpc-vs-tee.png" --- [**Zurück**](/de/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/de/team/kevin-riedl/) [Kevin Riedl](/de/team/kevin-riedl/) https://linkedin.com/in/wsdt 10 min Lesezeit · 5. Juli 2026 Zuletzt geprüft 7. August 2026 [**Weiter**](/de/blog/building-real-applications-zero-knowledge-fhe-2026/) # ZK vs FHE vs MPC vs TEE: Wie du 2026 wählst TL;DR ZK, FHE, MPC und TEEs schützen unterschiedliche Aussagen und öffnen unterschiedliche Trust Boundaries. Es gibt keinen festen Performance-Multiplikator: Circuit, Parameter, Implementierung, Threshold, Netzwerk, Hardware und Attestation zählen. Benchmarke das konkrete System. EU-Regeln schreiben meist Eigenschaften wie selektive Offenlegung, kontrollierten Zugriff, Resilienz und Vertraulichkeit vor, nicht eine bestimmte Technologie. EUDI-Arbeit bewertet weiterhin BBS und hybride ZK-Ansätze. Gegen Primärquellen geprüft am 2026-08-07. 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](/de/blog/building-real-applications-zero-knowledge-fhe-2026/). Engineering-Perspektive, kein Vendor-Pitch. Alle Zahlen sind belegt oder als Daumenregeln gekennzeichnet. Die Referenzpunkte stammen aus Wavects [Zero-Knowledge](/de/services/zero-knowledge/) - und [Frontier-Tech](/de/services/bleeding-edge/) -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](/de/glossary/zero-knowledge/) und den [Produktions-Deep-Dive](/de/blog/zero-knowledge-proofs-production-2026/). - 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](/de/blog/fully-homomorphic-encryption-practical-2026/). - 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? | | ZK | FHE | MPC | TEE | | --- | --- | --- | --- | --- | | Du vertraust | Proof-Annahmen plus Circuit und Implementierung | Scheme, Parameter, Implementierung und Key Handling | Einem protokollspezifischen Threshold | Hardware, Firmware, Attestation und Side-Channel-Abwehr | | Performance-Kosten | Meist Prover-lastig; Verifier variiert | Groß und operationsabhängig | Protokoll-, Threshold- und netzwerkabhängig | Oft nahe nativ, aber workload- und plattformabhängig | | 2026er-Kostensignal | Realtime-Block-Proving demonstriert; konkreten Proof kalkulieren | Schnelle Primitive existieren; Anwendungen end-to-end messen | Rounds und Datenmenge im Zielnetz messen | Confidential-Compute-Aufpreis und Attestation einrechnen | | Reife | Produktion (L2s, Google Wallet, World ID) | Produktion für enge Lookups (Apple, Microsoft) | Produktion in Finance und Key Management | Produktion überall, inkl. Confidential GPUs | | Vor dem Betreiber verborgen | Die Witness (Evidenz) | Alles | Alles (über Parteien verteilt) | Alles, wenn du der Hardware vertraust | | Killer-Use-Case | Selektive Offenlegung, Verifiable Compute | Private Lookups, kleines Private ML | Organisationsübergreifende Analytics | Confidential AI in Skalierung | | Haupt-Failure-Mode | Under-constrained Circuits, Trusted-Setup-Fehler | Fehlbesetzt auf interaktive Workloads | Kollusion, Netzwerk-Latenz | Side-Channel-Angriffe, Herstellervertrauen | ![Kevin Riedl](/img/team/kevin.webp) "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)](https://arxiv.org/abs/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](/de/blog/eu-data-residency-ai-apps-2026/) 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. ## Häufig gestellte Fragen ### Was ist der Unterschied zwischen ZK, FHE, MPC und TEE in je einem Satz? ZK beweist einen Fakt, ohne die Evidenz offenzulegen; FHE rechnet auf Daten, die verschlüsselt bleiben; MPC lässt mehrere Parteien gemeinsam rechnen, ohne Inputs zu teilen; ein TEE führt Klartext-Berechnungen in Hardware-Isolation aus, der du vertrauen musst. ### Was ist am sichersten: ZK, FHE, MPC oder TEE? Es gibt kein universelles Ranking. ZK und FHE hängen auch von Software, Parametern, Circuits, Setup und Key Handling ab. MPC ergänzt Threshold-Annahmen, TEE ergänzt Hardware, Firmware, Attestation und Side Channels. Vergleiche konkrete Systeme gegen das Threat Model. ### Reicht ein TEE für DSGVO-Compliance? Oft ja, als Teil einer Data-Protection-by-Design-Story: Confidential VMs oder GPUs mit Attestation reduzieren den Betreiberzugriff wesentlich. Aber TEEs machen Daten nicht anonym, und ob selbst FHE-Output dem DSGVO-Scope entkommt, ist juristisch ungeklärt. Compliance entsteht aus dem gesamten Verarbeitungsdesign, mit juristischem Review, nicht aus einer einzelnen Technologie. ### Können diese Technologien kombiniert werden? Ja. Ein TEE kann den Massen-Workload tragen, FHE oder MPC eine kleinere Berechnung ohne akzeptables Hardware-Vertrauen abdecken und ZK ein definiertes Ergebnis verifizierbar machen. Späterer Austausch braucht trotzdem explizite Interfaces, Key Ownership, Datenformate und Fallback-Semantik; er ist kein automatisches Drop-in-Upgrade. ### Was sollte ein EU-Unternehmen vor der eIDAS-Wallet-Deadline 2026 tun? Prototype gegen aktuelle EUDI-Selective-Disclosure-Flows und isoliere den Credential-Adapter. Prüfe Assurance-Level, Certified Hardware, nationalen Rollout und Relying-Party-Regeln vor dem Launch. BBS- und hybride ZK-Ansätze sind Teil laufender technischer Arbeit. ## Quellen und Verifikation 1. Mopro (2026). Circuit-specific proving and verification benchmarks. [zkmopro.org](https://zkmopro.org/docs/performance/) 2. Apple Machine Learning Research (2024). Production HE and private information retrieval. [machinelearning.apple.com](https://machinelearning.apple.com/research/homomorphic-encryption) 3. European Union (2025). Regulation (EU) 2025/327 on the European Health Data Space. [eur-lex.europa.eu](https://eur-lex.europa.eu/eli/reg/2025/327/oj) 4. European Digital Identity Wallet (2026). ZK proofs from multi-message signatures. [github.com/eu-digital-identity-wallet](https://github.com/eu-digital-identity-wallet/eudi-doc-standards-and-technical-specifications/blob/main/docs/technical-specifications/ts14-zkps-from-mms.md) 5. W3C (2026). Data Integrity BBS Cryptosuites v1.0, Candidate Recommendation Draft. [w3.org](https://www.w3.org/TR/vc-di-bbs/) 6. Confidential GPU research (2025). Performance analysis of confidential GPU workloads. [arxiv.org](https://arxiv.org/abs/2505.16501) ## Fazit Die vier Technologien sind nicht austauschbar. ZK beantwortet Verifikationsfragen, FHE Blind-Compute-Fragen mit passendem Operationsmix, MPC organisationsübergreifende Berechnung unter definiertem Threshold, und TEEs große vertrauliche Workloads mit anderer Hardware-Trust-Boundary. Wähle nach Threat Model, benchmarke den konkreten Stack und mappe EU-Regeln auf Eigenschaften statt auf vermeintlich vorgeschriebene Technologien. ## Das könnte dich auch interessieren.. [**Fully Homomorphic Encryption 2026: Was shipped und was noch Hype ist** Apples produktive FHE, Zamas Mainnet, die ehrlichen Overhead-Zahlen und der LLM-unter-FHE-Reality-Check.](/de/blog/fully-homomorphic-encryption-practical-2026/) [**Wavect vs eine klassische Dev-Agentur** Generalisten verkaufen Kapazität, wir verkaufen Produkturteil plus das Engineering, um Frontier-Tech sicher auszuliefern.](/de/compare/wavect-vs-dev-agencies/) Datenschutz und Kryptografie ## In diesem Cluster weiterlesen Zero Knowledge, FHE und Privacy-preserving Computing jenseits des Hypes. [Mit dem Grundlagenartikel starten**Zero-Knowledge-Proofs 2026: Was wirklich production-ready ist**](/de/blog/zero-knowledge-proofs-production-2026/) - [zkTLS für KI-Agenten: Webdaten beweisen, Secrets schützen](/de/blog/zktls-ai-agents/) - [Echte Anwendungen mit ZK und FHE bauen 2026: Ein pragmatischer Guide](/de/blog/building-real-applications-zero-knowledge-fhe-2026/) - [Zero-Knowledge-Proofs 2026: Was wirklich production-ready ist](/de/blog/zero-knowledge-proofs-production-2026/) - [Fully Homomorphic Encryption 2026: Was shipped und was noch Hype ist](/de/blog/fully-homomorphic-encryption-practical-2026/) - [Zero-Knowledge außerhalb von Crypto](/de/blog/zero-knowledge-use-cases-outside-crypto/) Postfach, ohne Lärm ## Folge der Arbeit, die für dich zählt Du bekommst eine kurze E-Mail, wenn wir etwas Neues veröffentlichen. Folge dem ganzen Blog oder nur den Themen, die dich interessieren. [**Zurück**](/de/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/de/team/kevin-riedl/) [Kevin Riedl](/de/team/kevin-riedl/) https://linkedin.com/in/wsdt 10 min Lesezeit · 5. Juli 2026 Zuletzt geprüft 7. August 2026 [**Weiter**](/de/blog/building-real-applications-zero-knowledge-fhe-2026/) Neue Beiträge per E-Mail × × Neue Beiträge per E-Mail Eine kurze E-Mail, wenn wir etwas veröffentlichen. Kostenlos, ohne Tracking. ## Structured Data ```json { "@context": "https://schema.org", "@graph": [ { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ], "employee": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "founder": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "legalRepresentative": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "name": "Wavect GmbH", "subjectOf": { "@id": "https://wavect.io/verified-claims.json#dataset", "@type": "Dataset", "creator": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "description": "A machine-readable registry of quantitative and qualitative claims published by Wavect, with review dates, localized page appearances and public third-party citations where available.", "inLanguage": "en", "isAccessibleForFree": true, "license": "https://creativecommons.org/licenses/by/4.0/", "name": "Wavect verified publication claims", "url": "https://wavect.io/verified-claims.json" }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "sameAs": [ "https://www.wikidata.org/wiki/Q139796365", "https://www.linkedin.com/in/wsdt", "https://github.com/wsdt" ], "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "sameAs": [ "https://www.wikidata.org/wiki/Q139796367", "https://www.linkedin.com/in/jocr77/", "https://github.com/jo-chris" ], "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/#website", "@type": "WebSite", "inLanguage": [ "en", "de", "es", "zh" ], "name": "Wavect", "potentialAction": { "@type": "SearchAction", "query-input": "required name=search_term_string", "target": { "@type": "EntryPoint", "urlTemplate": "https://wavect.io/search/?q={search_term_string}" } }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/de/blog/zk-vs-fhe-vs-mpc-vs-tee/#webpage", "@type": "WebPage", "dateModified": "2026-07-07", "inLanguage": "de", "isPartOf": { "@id": "https://wavect.io/#website", "@type": "WebSite" }, "lastReviewed": "2026-07-07", "url": "https://wavect.io/de/blog/zk-vs-fhe-vs-mpc-vs-tee/" } ] } ``` ```json { "@context": "https://schema.org", "@type": "BlogPosting", "abstract": "ZK, FHE, MPC und TEEs schützen unterschiedliche Aussagen und öffnen unterschiedliche Trust Boundaries. Es gibt keinen festen Performance-Multiplikator: Circuit, Parameter, Implementierung, Threshold, Netzwerk, Hardware und Attestation zählen. Benchmarke das konkrete System. EU-Regeln schreiben meist Eigenschaften wie selektive Offenlegung, kontrollierten Zugriff, Resilienz und Vertraulichkeit vor, nicht eine bestimmte Technologie. EUDI-Arbeit bewertet weiterhin BBS und hybride ZK-Ansätze. Gegen Primärquellen geprüft am 2026-08-07.", "articleBody": " Blog-Übersicht/Web3 und Datenschutz/Datenschutz und Kryptografie ZK vs FHE vs MPC vs TEE: Wie du 2026 wählst TL;DR ZK, FHE, MPC und TEEs schützen unterschiedliche Aussagen und öffnen unterschiedliche Trust Boundaries. Es gibt keinen festen Performance-Multiplikator: Circuit, Parameter, Implementierung, Threshold, Netzwerk, Hardware und Attestation zählen. Benchmarke das konkrete System. EU-Regeln schreiben meist Eigenschaften wie selektive Offenlegung, kontrollierten Zugriff, Resilienz und Vertraulichkeit vor, nicht eine bestimmte Technologie. EUDI-Arbeit bewertet weiterhin BBS und hybride ZK-Ansätze. Gegen Primärquellen geprüft am 2026-08-07. 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? 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. 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. 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. 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? ZKFHEMPCTEE Du vertraustProof-Annahmen plus Circuit und ImplementierungScheme, Parameter, Implementierung und Key HandlingEinem protokollspezifischen ThresholdHardware, Firmware, Attestation und Side-Channel-Abwehr Performance-KostenMeist Prover-lastig; Verifier variiertGroß und operationsabhängigProtokoll-, Threshold- und netzwerkabhängigOft nahe nativ, aber workload- und plattformabhängig 2026er-KostensignalRealtime-Block-Proving demonstriert; konkreten Proof kalkulierenSchnelle Primitive existieren; Anwendungen end-to-end messenRounds und Datenmenge im Zielnetz messenConfidential-Compute-Aufpreis und Attestation einrechnen ReifeProduktion (L2s, Google Wallet, World ID)Produktion für enge Lookups (Apple, Microsoft)Produktion in Finance und Key ManagementProduktion überall, inkl. Confidential GPUs Vor", "articleSection": "Engineering", "author": { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "name": "Kevin Riedl", "sameAs": [ "https://www.wikidata.org/wiki/Q139796365", "https://www.linkedin.com/in/wsdt", "https://github.com/wsdt" ], "url": "https://wavect.io/team/kevin-riedl/" }, "citation": [ { "@type": "WebPage", "name": "zkmopro.org", "url": "https://zkmopro.org/docs/performance/" }, { "@type": "WebPage", "name": "machinelearning.apple.com", "url": "https://machinelearning.apple.com/research/homomorphic-encryption" }, { "@type": "WebPage", "name": "eur-lex.europa.eu", "url": "https://eur-lex.europa.eu/eli/reg/2025/327/oj" }, { "@type": "WebPage", "name": "github.com/eu-digital-identity-wallet", "url": "https://github.com/eu-digital-identity-wallet/eudi-doc-standards-and-technical-specifications/blob/main/docs/technical-specifications/ts14-zkps-from-mms.md" }, { "@type": "WebPage", "name": "w3.org", "url": "https://www.w3.org/TR/vc-di-bbs/" }, { "@type": "WebPage", "name": "arxiv.org", "url": "https://arxiv.org/abs/2505.16501" } ], "dateModified": "2026-08-07", "datePublished": "2026-07-05", "description": "ZK, FHE, MPC und TEEs schützen unterschiedliche Aussagen und öffnen unterschiedliche Trust Boundaries. Es gibt keinen festen Performance-Multiplikator: Circuit, Parameter, Implementierung, Threshold, Netzwerk, Hardware und Attestation zählen. Benchmarke das konkrete System. EU-Regeln schreiben meist Eigenschaften wie selektive Offenlegung, kontrollierten Zugriff, Resilienz und Vertraulichkeit vor, nicht eine bestimmte Technologie. EUDI-Arbeit bewertet weiterhin BBS und hybride ZK-Ansätze. Gegen Primärquellen geprüft am 2026-08-07.", "headline": "ZK vs FHE vs MPC vs TEE: Wie du 2026 wählst", "image": "https://wavect.io/img/blog/headers/header_zk-vs-fhe-vs-mpc-vs-tee.svg", "inLanguage": "de", "mainEntityOfPage": { "@id": "https://wavect.io/de/blog/zk-vs-fhe-vs-mpc-vs-tee/", "@type": "WebPage" }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/de/blog/zk-vs-fhe-vs-mpc-vs-tee/", "wordCount": 1909 } ``` ```json { "@context": "https://schema.org", "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "item": "https://wavect.io/de/", "name": "Startseite", "position": 1 }, { "@type": "ListItem", "item": "https://wavect.io/de/blog/overview/", "name": "Blog-Übersicht", "position": 2 }, { "@type": "ListItem", "item": "https://wavect.io/de/blog/topics/web3-privacy/", "name": "Web3 und Datenschutz", "position": 3 }, { "@type": "ListItem", "item": "https://wavect.io/de/blog/clusters/privacy-cryptography/", "name": "Datenschutz und Kryptografie", "position": 4 }, { "@type": "ListItem", "item": "https://wavect.io/de/blog/zk-vs-fhe-vs-mpc-vs-tee/", "name": "ZK vs FHE vs MPC vs TEE: Wie du 2026 wählst | ", "position": 5 } ] } ``` ```json { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "ZK beweist einen Fakt, ohne die Evidenz offenzulegen; FHE rechnet auf Daten, die verschlüsselt bleiben; MPC lässt mehrere Parteien gemeinsam rechnen, ohne Inputs zu teilen; ein TEE führt Klartext-Berechnungen in Hardware-Isolation aus, der du vertrauen musst." }, "name": "Was ist der Unterschied zwischen ZK, FHE, MPC und TEE in je einem Satz?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Es gibt kein universelles Ranking. ZK und FHE hängen auch von Software, Parametern, Circuits, Setup und Key Handling ab. MPC ergänzt Threshold-Annahmen, TEE ergänzt Hardware, Firmware, Attestation und Side Channels. Vergleiche konkrete Systeme gegen das Threat Model." }, "name": "Was ist am sichersten: ZK, FHE, MPC oder TEE?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Oft ja, als Teil einer Data-Protection-by-Design-Story: Confidential VMs oder GPUs mit Attestation reduzieren den Betreiberzugriff wesentlich. Aber TEEs machen Daten nicht anonym, und ob selbst FHE-Output dem DSGVO-Scope entkommt, ist juristisch ungeklärt. Compliance entsteht aus dem gesamten Verarbeitungsdesign, mit juristischem Review, nicht aus einer einzelnen Technologie." }, "name": "Reicht ein TEE für DSGVO-Compliance?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Ja. Ein TEE kann den Massen-Workload tragen, FHE oder MPC eine kleinere Berechnung ohne akzeptables Hardware-Vertrauen abdecken und ZK ein definiertes Ergebnis verifizierbar machen. Späterer Austausch braucht trotzdem explizite Interfaces, Key Ownership, Datenformate und Fallback-Semantik; er ist kein automatisches Drop-in-Upgrade." }, "name": "Können diese Technologien kombiniert werden?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Prototype gegen aktuelle EUDI-Selective-Disclosure-Flows und isoliere den Credential-Adapter. Prüfe Assurance-Level, Certified Hardware, nationalen Rollout und Relying-Party-Regeln vor dem Launch. BBS- und hybride ZK-Ansätze sind Teil laufender technischer Arbeit." }, "name": "Was sollte ein EU-Unternehmen vor der eIDAS-Wallet-Deadline 2026 tun?" } ] } ```