27. Juni 2025·8 Min
Adi Shamirs Durchbrüche: RSA, Secret Sharing und Sicherheit
Erfahre die zentralen Ideen von Adi Shamir zu RSA und Secret Sharing — und wie elegante Mathematik reale Sicherheit, Risiko und Schlüsselverwaltung prägt.
Erfahre die zentralen Ideen von Adi Shamir zu RSA und Secret Sharing — und wie elegante Mathematik reale Sicherheit, Risiko und Schlüsselverwaltung prägt.
Adi Shamir ist einer der seltenen Forscher, deren Ideen nicht in Papers oder Konferenzen verharrten — sie wurden Bausteine alltäglicher Sicherheit. Wenn du jemals HTTPS benutzt, ein Software‑Update überprüft oder einer digitalen Signatur vertraut hast, profitierst du von Arbeiten, die er mit geprägt hat.
Shamir war Mitentdecker von RSA, einem Public‑Key‑Kryptosystem, das es praktisch machte, dass Fremde sichere Nachrichten austauschen und Identität im großen Maßstab beweisen können. Er entwickelte auch Shamirs Secret Sharing, eine Methode, ein Geheimnis (z. B. einen kryptographischen Schlüssel) in Teile zu zerlegen, sodass keine einzelne Person oder Server die volle Kontrolle hat.
Beide Ideen teilen ein Thema: eine klare mathematische Einsicht kann eine praktikable Sicherheitsfähigkeit freisetzen, die Organisationen tatsächlich einsetzen können.
Dieser Artikel konzentriert sich auf jene Brücke — von eleganten Konzepten zu Werkzeugen, die reale Systeme stützen. Du siehst, wie RSA Signaturen und sichere Kommunikation ermöglichte und wie Secret Sharing Teams erlaubt, Vertrauen mit k‑von‑n‑Regeln zu verteilen (zum Beispiel können beliebige 3 von 5 Schlüsselinhabern eine kritische Aktion genehmigen).
Wir erklären die Kernideen ohne schwere Gleichungen oder fortgeschrittene Zahlentheorie. Ziel ist Klarheit: zu verstehen, was diese Systeme erreichen wollen, warum die Designs clever sind und wo die scharfen Kanten liegen.
Es gibt Grenzen: starke Mathematik bedeutet nicht automatisch starke Sicherheit. Reale Ausfälle entstehen oft durch Implementationsfehler, schlechte Schlüsselverwaltung, schwache betriebliche Verfahren oder unrealistische Annahmen über Bedrohungen. Shamirs Arbeit hilft, beide Seiten zu sehen: die Kraft guter kryptographischer Gestaltung — und die Notwendigkeit sorgfältiger, praxisnaher Umsetzung.
Ein echter kryptographischer Durchbruch ist nicht nur „wir haben Verschlüsselung schneller gemacht“. Es ist eine neue Fähigkeit, die verändert, was Menschen sicher tun können. Denk daran als Erweiterung der Probleme, die Sicherheitstools lösen können — besonders in großem Maßstab, zwischen Fremden und unter realen Einschränkungen wie unzuverlässigen Netzen und menschlichen Fehlern.
Klassische „Geheimcodes" konzentrieren sich darauf, eine Nachricht zu verbergen. Moderne Kryptographie zielt breiter und praktischer:
Dieser Wandel ist wichtig, weil viele Fehlfunktionen nicht vom Abhören stammen — sondern von Manipulation, Identitätsfälschung und Streitigkeiten darüber, „wer was getan hat".
Bei symmetrischer Kryptographie teilen beide Seiten denselben geheimen Schlüssel. Sie ist effizient und wird weiterhin breit eingesetzt (z. B. zur Verschlüsselung großer Dateien oder Netzwerkverkehr). Die praktische Schwierigkeit ist: wie teilen zwei Parteien diesen Schlüssel sicher, insbesondere wenn sie sich nie getroffen haben?
Public‑Key‑Kryptographie teilt den Schlüssel in zwei Teile: einen öffentlichen Schlüssel, den du offen teilen kannst, und einen privaten Schlüssel, den du geheim hältst. Leute können dir mit deinem öffentlichen Schlüssel Nachrichten verschlüsseln — nur dein privater Schlüssel kann sie entschlüsseln. Oder du signierst mit deinem privaten Schlüssel, sodass jeder mit dem öffentlichen Schlüssel verifizieren kann.
Als Public Keys praktisch wurden, brauchten sichere Kommunikation und Vertrauensbildung keinen vorab geteilten Schlüssel oder einen vertrauenswürdigen Kurier mehr. Das ermöglichte sichere Internet‑Skalensysteme: sichere Logins, verschlüsselten Webverkehr, überprüfbare Software‑Updates und digitale Signaturen, die Identität und Rechenschaft stützen.
Das ist die Art von „neuer Fähigkeit“, die als Durchbruch gilt.
RSA hat eine der besten Entstehungsgeschichten in der Kryptographie: drei Forscher — Ron Rivest, Adi Shamir und Leonard Adleman — die versuchten, eine neue Idee (Public‑Key‑Kryptographie) in etwas Praktisches zu verwandeln.
1977 publizierten sie ein Schema, das schnell zur bekanntesten praktischen Antwort auf eine einfache Frage wurde: „Wie können zwei Personen sicher kommunizieren, ohne zuvor ein Geheimnis geteilt zu haben?" Ihre Namen bildeten das Akronym.
Die große Verschiebung von RSA ist leicht im Alltag zu beschreiben. Du kannst ein Schloss veröffentlichen (deinen öffentlichen Schlüssel), während du den einzigen Schlüssel, der es öffnet, für dich behältst (deinen privaten Schlüssel).
Wenn jemand dir eine geheime Nachricht schicken will, muss er dich nicht zuerst treffen. Er nimmt dein öffentliches Schloss, schließt die Nachricht ein und sendet die verschlossene Box. Nur du besitzt den privaten Schlüssel zum Öffnen.
Dieses „veröffentliche das Schloss, verstecke den Schlüssel“ ist, warum RSA damals magisch wirkte — und warum es grundlegend für moderne Vertrauenssysteme wurde.
RSA beruht auf einer speziellen Art von Puzzle:
Beim RSA erlaubt der öffentliche Schlüssel jedem, „die Farben zu mischen“, um eine Nachricht zu schützen; der private Schlüssel ist das verborgene Rezept zum Entmischen.
RSA tritt in mehreren Rollen auf:
Auch wenn neuere Werkzeuge populär wurden, erklärt RSAs Alltagsidee — öffentliches Schloss, privater Schlüssel — viel darüber, wie modernes Vertrauen im Internet aufgebaut ist.
RSA wirkt mysteriös, bis du auf zwei alltägliche Ideen zoomen: Zahlen in einem festen Bereich „einwickeln" und auf ein Problem vertrauen, das schmerzhaft langsam zu rückgängig machen scheint.
Modulare Arithmetik ist, wenn Zahlen „herumwickeln“, wie Stunden auf einer Uhr. Auf einer 12‑Stunden‑Uhr ergibt 10 + 5 nicht 15, sondern 3.
RSA verwendet denselben Wrap‑Around‑Gedanken, nur mit einer viel größeren „Uhr“. Man wählt eine große Zahl (den Modulus) und führt Berechnungen durch, deren Ergebnisse immer in den Bereich 0 bis Modulus−1 zurückgeführt werden.
Warum das wichtig ist: Modulare Arithmetik erlaubt Operationen, die in eine Richtung leicht sind, während die Umkehr schwer bleibt — genau die Asymmetrie, die Kryptographie braucht.
Kryptographie beruht oft auf einer Aufgabe, die:
Bei RSA ist das „spezielle Wissen“ der private Schlüssel. Ohne ihn steht der Angreifer vor einem Problem, das als extrem teuer gilt.
Die Sicherheit von RSA basiert auf der Schwierigkeit des Faktorisierens: eine große Zahl zu nehmen und die beiden großen Primzahlen zu finden, deren Produkt sie ist.
Das Multiplizieren zweier großer Primzahlen ist einfach. Wenn dir aber nur das Produkt gegeben ist und man dich nach den Originalprimzahlen fragt, scheint dieser Schritt mit zunehmender Größe enorm viel Aufwand zu erfordern.
Diese Faktorisierungsschwierigkeit ist der Kern, warum RSA funktionieren kann: öffentliche Informationen sind sicher zu teilen, der private Schlüssel bleibt praktisch nutzbar, aber schwer zu rekonstruieren.
RSA ist nicht durch einen mathematischen Beweis geschützt, dass Faktorisierung unmöglich ist. Stattdessen steht es auf Jahrzehnten von Erfahrung: kluge Forscher haben viele Ansätze versucht, und die besten bekannten Methoden sind bei richtig gewählten Größen immer noch zu langsam.
Das heißt: nicht für immer garantiert, aber so vertrauenswürdig, wie die aktuelle Forschung es erlaubt.
Die Schlüssellänge steuert, wie groß diese modulare „Uhr" ist. Größere Schlüssel machen Faktorisierung in der Regel dramatisch teurer und treiben Angriffe jenseits realistischer Zeit‑ und Budgetgrenzen. Deshalb wurden ältere, kürzere RSA‑Schlüssel zurückgezogen — und weshalb Schlüssellängen eine Entscheidung über den Aufwand des Angreifers sind.
Digitale Signaturen beantworten eine andere Frage als Verschlüsselung. Verschlüsselung schützt Geheimhaltung: „Kann nur der vorgesehene Empfänger das lesen?“ Eine Signatur schützt Vertrauen: „Wer hat das erstellt, und wurde es verändert?"
Eine digitale Signatur beweist typischerweise zwei Dinge:
Beim RSA nutzt der Signierer seinen privaten Schlüssel, um ein kurzes Datenstück zu erzeugen — die Signatur —, die an die Nachricht gebunden ist. Jeder mit dem passenden öffentlichen Schlüssel kann sie prüfen.
Wichtig: man signiert nicht direkt die komplette Datei. In der Praxis signiert man einen Hash (einen kompakten Fingerabdruck) der Datei. Deshalb funktioniert Signieren gleichermaßen für eine kleine Nachricht oder einen mehrgigabytegroßen Download.
RSA‑Signaturen tauchen überall dort auf, wo Systeme Identität in großem Maßstab prüfen müssen:
Einfach „die RSA‑Mathematik machen" reicht nicht. Reale RSA‑Signaturen verlassen sich auf standardisierte Padding‑ und Kodierungsregeln (z. B. PKCS#1 oder RSA‑PSS). Denk an sie als Leitplanken, die subtile Angriffe verhindern und Signaturen eindeutig machen.
Du kannst verschlüsseln, ohne zu beweisen, wer gesendet hat, und du kannst signieren, ohne die Nachricht zu verbergen. Viele sichere Systeme tun beides — aber sie lösen unterschiedliche Probleme.
RSA ist eine starke Idee, aber die meisten realen „Brüche" schlagen nicht die zugrundeliegende Mathematik; sie nutzen die unordentlichen Teile drumherum: wie Schlüssel erzeugt werden, wie Nachrichten gepaddet werden, wie Geräte sich verhalten und wie Menschen Systeme betreiben.
Wenn Schlagzeilen sagen „RSA geknackt", geht es häufig um einen Implementierungsfehler oder eine Deployment‑Abkürzung. RSA wird selten als „rohes RSA" verwendet; es ist in Protokollen eingebettet, mit Padding‑Schemata versehen und mit Hashing und Zufälligkeit kombiniert. Wenn eines dieser Teile fehlt oder falsch ist, kann das System zusammenbrechen, selbst wenn der Kernalgorithmus intakt bleibt.
Typische Lücken, die immer wieder zu Vorfällen führen:
Moderne Krypto‑Bibliotheken und Standards existieren, weil Teams diese Lektionen teuer gelernt haben. Sie bringen sichere Defaults, konstante‑Zeit‑Operationen, geprüfte Padding‑Schemata und Protokoll‑Leitplanken mit. "Dein eigenes RSA schreiben" oder bestehende Schemata abändern ist riskant, weil kleine Abweichungen neue Angriffsflächen schaffen können.
Das gilt umso mehr, wenn Teams schnell ausliefern. Wenn du einen schnellen Entwicklungsworkflow nutzt — ob traditionelle CI/CD‑Pipelines oder eine Plattform wie Koder.ai — gilt der Zeitvorteil nur, wenn Sicherheitsdefaults ebenfalls standardisiert sind. Koder.ai kann Full‑Stack‑Apps generieren und deployen (React im Web, Go + PostgreSQL im Backend, Flutter für Mobile) und damit den Weg zur Produktion verkürzen, doch disziplinierte Schlüsselverwaltung bleibt unerlässlich: TLS‑Zertifikate, Secret‑Management und Release‑Signing sind betriebliche Erstklassobjekte, keine Nachgedanken.
Wenn du mehr praktische Sicherheitsanleitungen jenseits der Mathematik willst, stöbere unter /blog nach verwandten Guides zur Implementierung und Schlüsselverwaltung.
Sich auf ein einziges „Master‑Geheimnis" zu verlassen, ist eine unsichere Art Sicherheit zu betreiben. Wenn eine einzelne Person den Schlüssel hält (oder ein einziges Gerät ihn speichert), bist du anfällig für reale Ausfälle: Verlust, Diebstahl, Insider‑Missbrauch oder Zwang. Das Geheimnis kann perfekt verschlüsselt sein und trotzdem fragil, weil nur eine Person die Macht hat.
Shamirs Secret Sharing löst das, indem es ein Geheimnis in n separate Anteile aufteilt und eine Regel setzt, dass jede k Anteile das ursprüngliche Geheimnis rekonstruieren können — während weniger als k nichts Nützliches verraten.
Statt „Wer hat das Master‑Passwort?“ lautet die Frage: „Können wir k autorisierte Personen/Geräte zusammenbringen, wenn wir es wirklich brauchen?"
Schwellen‑Sicherheit verteilt Vertrauen über mehrere Inhaber:
Das ist besonders wertvoll für Geheimnisse mit großem Impact wie Wiederherstellungsschlüssel, Zertifizierungsstellenmaterial oder Root‑Zugangsdaten für kritische Infrastruktur.
Shamirs Einsicht war nicht nur mathematische Eleganz — sie bot eine praktische Methode, Vertrauen von einer einzelnen Wette in eine messbare, prüfbare Regel zu verwandeln.
Shamirs Secret Sharing löst ein sehr praktisches Problem: du willst nicht, dass eine Person, ein Server oder ein USB‑Stick "der Schlüssel" ist. Stattdessen teilst du das Geheimnis so auf, dass eine Gruppe kooperieren muss, um es wiederherzustellen.
Stell dir vor, du zeichnest eine glatte Kurve auf Millimeterpapier. Wenn du nur einen oder zwei Punkte auf der Kurve siehst, kannst du unendlich viele Kurven finden, die durch diese Punkte gehen. Wenn du aber genug Punkte hast, ist die Kurve eindeutig bestimmt.
Das ist das Kernprinzip der Polynominterpolation: Shamir kodiert das Geheimnis als Teil einer Kurve (eines Polynoms) und gibt Punkte auf dieser Kurve als Anteile aus. Mit genügend Punkten kannst du die Kurve rekonstruieren und das Geheimnis ablesen. Mit zu wenigen Punkten hast du viele gültige Kurven — das Geheimnis bleibt verdeckt.
Ein Anteil ist einfach ein Punkt auf dieser verborgenen Kurve: ein kleines Datenbündel, das allein wie Zufall aussieht.
Das Schema ist normalerweise als k‑von‑n beschrieben:
Secret Sharing funktioniert nur, wenn Anteile nicht am selben Ort oder unter derselben Kontrolle landen. Gute Praxis ist, sie über Personen, Geräte und Standorte zu verteilen (z. B. eines in einem Hardware‑Token, eines beim Rechtsbeistand, eines in einem sicheren Tresor).
Die Wahl von k ist ein Balanceakt:
Die Eleganz liegt darin, dass die Mathematik „geteiltes Vertrauen" in eine präzise, durchsetzbare Regel verwandelt.
Secret Sharing ist primär ein Werkzeug zur Aufteilung von Kontrolle, nicht einfach zur „sicheren Speicherung" im Alltag. Es ist ein Governance‑Tool: du verlangst bewusst, dass mehrere Personen/Systeme kooperieren müssen, bevor ein Schlüssel rekonstruiert werden kann.
Diese Tools reduzieren alle Risiken, aber unterschiedliche:
Secret Sharing ist ideal, wenn das Geheimnis extrem wertvoll ist und starke Checks & Balances gewünscht sind:
Wenn dein Hauptproblem „Ich könnte Dateien löschen" oder „ich muss Benutzerpasswörter zurücksetzen" ist, ist Secret Sharing oft Overkill. Es ersetzt auch nicht gute Betriebs‑Sicherheit: wenn ein Angreifer genug Anteilinhaber täuscht oder deren Geräte kompromittiert, kann die Schwelle trotzdem erfüllt werden.
Der offensichtliche Fehler ist Verfügbarkeit: Verlier zu viele Anteile, verlierst du das Geheimnis. Subtilere Risiken sind menschlicher Natur:
Dokumentiere den Prozess, verteile klare Rollen und probiere die Wiederherstellung regelmäßig — wie eine Brandschutzübung. Ein Secret‑Sharing‑Plan, der nie getestet wurde, ist eher Hoffnung als Kontrolle.
RSA und Shamirs Secret Sharing sind berühmte „Algorithmen“, doch ihre wahre Wirkung zeigt sich, wenn sie in Systeme eingebettet werden, die Menschen und Organisationen tatsächlich betreiben: Zertifizierungsstellen, Genehmigungs‑Workflows, Backups und Incident‑Recovery.
RSA‑Signaturen tragen die Idee, dass ein öffentlicher Schlüssel eine Identität repräsentieren kann. Praktisch wird daraus PKI: Zertifikate, Zertifikatketten und Richtlinien darüber, wer was unterschreiben darf. Ein Unternehmen wählt nicht nur „RSA vs. etwas anderes" — es entscheidet, wer Zertifikate ausstellen darf, wie oft Schlüssel rotieren und was passiert, wenn ein Schlüssel kompromittiert wird.
Schlüsselrotation ist die betriebliche Schwester von RSA: du planst Veränderung. Kurzlebigere Zertifikate, geplante Ersetzungen und klare Widerrufsverfahren reduzieren die Auswirkungen unvermeidlicher Fehler.
Secret Sharing macht aus „ein Schlüssel, ein Besitzer" ein Vertrauensmodell. Du kannst verlangen, dass k‑von‑n Personen (oder Systeme) ein Wiederherstellungsgeheimnis rekonstruieren, eine empfindliche Konfigurationsänderung genehmigen oder ein Offline‑Backup entsperren. Das ermöglicht sicherere Wiederherstellung: kein Admin kann heimlich die Kontrolle übernehmen, und kein verlorenes Credential führt zu dauerhaftem Lockout.
Gute Sicherheit fragt: Wer darf Releases signieren, wer kann Accounts wiederherstellen, und wer genehmigt Policy‑Änderungen? Aufgabentrennung reduziert Betrug und unbeabsichtigten Schaden, indem hochwirksame Aktionen unabhängige Zustimmung erfordern.
Hier zeigt sich auch, warum betriebliche Werkzeuge wichtig sind. Plattformen wie Koder.ai bieten z. B. Snapshots und Rollback‑Funktionen, die den Schaden eines fehlgeschlagenen Deployments verringern — aber diese Funktionen sind nur wirkungsvoll, wenn sie mit diszipliniertem Signing, Least‑Privilege‑Zugriff und klaren Genehmigungsregeln kombiniert werden.
Für Teams mit unterschiedlichen Sicherheitsebenen — z. B. Basiszugriff vs. Schwellenwert‑Genehmigungen — mache die Entscheidungen explizit (siehe /pricing).
Ein Algorithmus kann auf dem Papier „sicher" sein und doch scheitern, sobald er auf reale Menschen, Geräte und Arbeitsabläufe trifft. Sicherheit ist immer relativ: relativ zu dem, wer dich angreifen könnte, was dieser Täter tun kann, was du schützt und was der Ausfall kosten würde.
Nenne zuerst deine wahrscheinlichen Bedrohungsakteure:
Jeder Akteur zwingt dich zu anderen Abwehrmaßnahmen. Bei Sorge vor externen Angreifern priorisierst du gehärtete Server, sichere Defaults und schnelles Patchen. Wenn Insider das größere Risiko sind, brauchst du Trennung der Aufgaben, Prüfprotokolle und Genehmigungen.
RSA und Secret Sharing zeigen, warum „gute Mathematik" nur der Anfang ist:
Eine praktische Gewohnheit: dokumentiere dein Bedrohungsmodell als kurze Liste von Annahmen — was du schützt, vor wem und welche Ausfälle tolerierbar sind. Überprüfe es, wenn sich Bedingungen ändern: neue Teammitglieder, Umzug in die Cloud, eine Fusion oder neue regulatorische Anforderungen.
Wenn du global ausrollst, füge Standort‑ und Compliance‑Annahmen hinzu: wo Schlüssel leben, wo Daten verarbeitet werden und welche grenzüberschreitenden Beschränkungen gelten. (Koder.ai betreibt z. B. global auf AWS und kann Apps in verschiedenen Ländern deployen, um regionale Datenschutz- und Datenübertragungsanforderungen zu unterstützen — die Verantwortung, das Modell zu definieren und korrekt zu konfigurieren, bleibt beim Team.)
Adi Shamirs Arbeit erinnert an eine einfache Regel: großartige kryptographische Ideen machen Sicherheit möglich, aber dein Tagesgeschäft macht sie real. RSA und Secret Sharing sind elegante Bausteine. Der tatsächliche Schutz hängt davon ab, wie Schlüssel erzeugt, gespeichert, genutzt, rotiert, gesichert und wiederhergestellt werden.
Betrachte Kryptographie als Engineering, nicht als Magie. Ein Algorithmus kann solide sein, während das System darum herum fragil ist — wegen überstürzter Deployments, unklarer Zuständigkeiten, fehlender Backups oder „temporärer" Abkürzungen, die dauerhaft werden.
Wenn du praktische Guides zu Schlüsselverwaltung und operativer Sicherheit suchst, stöbere in verwandten Beiträgen unter /blog.
Ein Durchbruch fügt eine neue Fähigkeit hinzu — nicht nur mehr Geschwindigkeit. In der Praxis bedeutet das meist, dass man zwischen Parteien, die kein gemeinsames Geheimnis teilen, Vertraulichkeit, Integrität und Authentizität in Internet‑Skala ermöglicht.
Symmetrische Kryptographie ist schnell, setzt aber voraus, dass beide Seiten bereits denselben geheimen Schlüssel teilen. Public‑Key‑Kryptographie führt einen öffentlichen Schlüssel ein, den man weit verbreiten kann, und einen privaten Schlüssel, den man geheim hält — dadurch wird das Schlüsselverteilungsproblem für Fremde und große Systeme gelöst.
RSA erlaubt es, ein „Schloss“ (den öffentlichen Schlüssel) zu veröffentlichen, das jeder benutzen kann, während nur der Besitzer den „Schlüssel“ (privaten Schlüssel) behält, um zu entschlüsseln oder zu signieren. Heute wird RSA vor allem für digitale Signaturen und historisch für Schlüsselaustausch/-transport in sicheren Protokollen genutzt.
RSA baut auf modularer Arithmetik („Uhr‑Mathematik“) auf und auf der Annahme, dass das Faktorisieren einer sehr großen Zahl (Produkt zweier großer Primzahlen) bei korrekter Schlüssellänge praktisch unlösbar ist. Das ist ein "als schwer angenommenes" Problem, kein mathematisch bewiesenes Unmöglichkeitsresultat — deshalb sind Parameter und Best Practices wichtig.
Verschlüsselung beantwortet: „Wer kann das lesen?“ Signaturen beantworten: „Wer hat das erstellt/abgesegnet und wurde es verändert?“ In der Praxis signiert man meist einen Hash der Daten; Prüfer nutzen den öffentlichen Schlüssel, um die Signatur zu verifizieren.
Die meisten echten Zusammenbrüche betreffen das Umfeld von RSA, zum Beispiel:
Verwende geprüfte Bibliotheken und moderne Padding‑Standards statt "raw RSA".
Shamirs Secret Sharing teilt ein Geheimnis in n Anteile, wobei k Anteile ausreichen, um das Geheimnis wiederherzustellen, während weniger als k nichts Brauchbares enthüllen. Es ersetzt die Idee „ein Master‑Schlüsselinhaber“ durch ein kontrolliertes Schwellenwert‑(threshold)‑Modell.
Nutze es für sehr wertvolle Geheimnisse, bei denen du keinen Single Point of Failure und keine Einzelperson mit Alleinentscheidungsbefugnis willst, z. B.:
Vermeide es für alltägliche Backups oder geringwertige Geheimnisse, wo der Betriebsaufwand den Nutzen übersteigt.
Wähle k nach realen Vorgaben:
Stelle außerdem sicher, dass Anteile über Personen, Geräte und Standorte verteilt sind; sonst entsteht derselbe Single Point of Failure wieder.
Sicherheit hängt von Bedrohungsmodellen und Betrieb ab, nicht nur von Algorithmen. Praktische Maßnahmen:
Für Implementierungsdetails siehe verwandte Beiträge unter /blog.