Frage:
Warum sollte man für die Verschlüsselung nicht denselben asymmetrischen Schlüssel verwenden wie für die Signatur?
Iszi
2011-01-22 02:06:42 UTC
view on stackexchange narkive permalink

In einer Antwort auf eine Frage zu RSA und PGP stellte PulpSpy Folgendes fest:

Mit GPG kann ein RSA-Schlüsselpaar generiert werden (für beide Verschlüsselungen) und Signieren - Sie sollten nicht für beide den gleichen Schlüssel verwenden.

Was ist der Grund dafür?

Vielleicht ist mein Verständnis der Verschlüsselung mit öffentlichen Schlüsseln fehlerhaft, aber ich dachte, die Vorgänge verliefen ähnlich:

  • Wenn Bob eine Nachricht an Alice verschlüsseln möchte, verwendet er den öffentlichen Schlüssel von Alice für die Verschlüsselung. Alice verwendet dann ihren privaten Schlüssel, um die Nachricht zu entschlüsseln.
  • Wenn Alice eine Nachricht digital an Bob signieren möchte, verwendet sie ihren privaten Schlüssel, um sie zu signieren. Bob verwendet dann den öffentlichen Schlüssel von Alice, um die Signatur zu überprüfen.

Warum ist es wichtig, unterschiedliche Schlüssel für die Verschlüsselung und Signatur zu verwenden? Würde dies nicht auch bedeuten, dass Sie zwei öffentliche Schlüssel an alle Personen verteilen müssen, mit denen Sie kommunizieren möchten? Ich kann mir vorstellen, dass dies leicht zu Verwirrung und Missbrauch von Schlüsseln führen kann.

Sechs antworten:
nealmcb
2011-01-22 02:13:26 UTC
view on stackexchange narkive permalink

In den meisten Fällen unterscheiden sich die Verwaltungsansätze und Zeitrahmen für die Verwendung von Signatur- und Verschlüsselungsschlüsseln.

Bei Nicht-Zurückweisung möchten Sie niemals, dass jemand anderes die Kontrolle über Ihren Signaturschlüssel erhält, da dieser sich als Identitätswechsel ausgeben kann Sie. Möglicherweise möchte Ihr Arbeitsplatz jedoch Ihren Verschlüsselungsschlüssel hinterlegen, damit andere Benutzer auf die von Ihnen verschlüsselten Informationen zugreifen können.

Möglicherweise möchten Sie auch, dass ein Signaturschlüssel für eine lange Zeit gültig ist, damit die Benutzer in der Nähe sind Die Welt kann Signaturen aus der Vergangenheit überprüfen, aber mit einem Verschlüsselungsschlüssel möchten Sie ihn häufig früher verschieben und alte ohne so viele Probleme widerrufen können.

Ja, das ist ein guter Grund. Ein weiterer Grund ist, dass die Wiederverwendung desselben Schlüsselpaars für beide Zwecke ** möglicherweise unsicher ** ist.
"Möglicherweise möchte Ihr Arbeitsplatz jedoch Ihren Verschlüsselungsschlüssel hinterlegen, damit andere Benutzer auf die von Ihnen verschlüsselten Informationen zugreifen können." - Dies kann für symmetrische Schlüssel relevant sein, nicht jedoch für PKI.
@user93353 Wenn ein öffentlicher Schlüssel nur zur Verschlüsselung verwendet wird, was würden Sie dagegen haben, ihn an einem Arbeitsplatz zu hinterlegen?
@nealmcb - Ich hätte überhaupt nichts dagegen.
@user93353 Gibt es etwas an Ihrem früheren Kommentar zu symmetrischen und öffentlichen Schlüsseln, das mir dann fehlt?
@nealmcb - Ihre Antwort besagt, dass Sie nicht dasselbe Schlüsselpaar für die Verschlüsselung und Signatur verwenden sollten. In PKI verwenden Sie Ihren privaten Schlüssel zum Signieren und einen öffentlichen Schlüssel zur Verschlüsselung. Was genau ist das Problem bei der Verwendung des gleichen Schlüsselpaars für die Verschlüsselung und Signatur?
@nealmcb und wenn der Arbeitsplatz Ihren öffentlichen Schlüssel hinterlegen möchte - na und? Ich verstehe deine Antwort überhaupt nicht.
@user93353 Wenn Ihr Arbeitsplatz einen Signaturschlüssel hinterlegt, können diese sich als Sie ausgeben, Erklärungen in Ihrem Namen unterschreiben, Sie in Schwierigkeiten bringen usw. Ich habe noch nie von einem guten Anwendungsfall dafür gehört. Ihr Signaturschlüsselpaar sollte also allein Ihnen gehören. Wenn ein Treuhand-Schlüsselpaar hinterlegt werden muss (um Zugriff auf Daten zu gewähren, die von Ihnen erstellt wurden, aber beispielsweise Ihrem Arbeitsplatz gehören), sollte es sich um ein separates Schlüsselpaar handeln.
@user93353-Arbeitsplätze hinterlegen häufig Ihren * privaten * Verschlüsselungsschlüssel. Auf diese Weise haben sie immer noch Zugriff auf Ihre Akten, wenn sie Sie feuern, von einem Bus angefahren werden oder mit der Tochter des Chefs fliehen. Jeder Arbeitgeber, der die Verschlüsselung von Arbeitsprodukten mit einem Schlüssel erlaubt, den er nicht im Treuhandkonto hat, bittet um Ärger.
@nealmcb, Re "möchte es früher umdrehen";Warum?Warum nicht einen mit mehr Beständigkeit verwenden?
@pacerier Je länger ein Verschlüsselungsschlüssel lebt, desto größer ist die Wahrscheinlichkeit eines Kompromisses und je mehr Inhalte verschlüsselt werden, desto mehr Probleme verursacht ein Kompromiss.Ein häufiger Rollover hat also viele Vorteile.Es gibt also Schemata, die es den Menschen ermöglichen, nur einem sehr gut geschützten Stammschlüssel zu vertrauen, der wiederum verwendet wird, um kurzlebigere Verschlüsselungsschlüssel als authentisch zu identifizieren.
D.W.
2011-03-09 11:35:46 UTC
view on stackexchange narkive permalink

Es ist möglicherweise unsicher , dasselbe Schlüsselpaar sowohl für die Signatur als auch für die Verschlüsselung zu verwenden. Dies kann je nach verwendetem Public-Key-Schema Angriffe ermöglichen. Diese Art der Verwendung ist nicht das, wofür das System entwickelt wurde. Wenn Sie das System also so verwenden, dass es nicht entwickelt wurde, erlischt die Garantie.

Tun Sie es nicht. Es bittet um Ärger.

Können Sie einige Details angeben? Welche Art von Angriffen unterbricht diese Verwendung? (Obwohl ich zustimme, unabhängig davon, ob das System nicht für diese Verwendung ausgelegt ist ...)
Sicher. Wenn Sie in einem schlecht gestalteten System die Entschlüsselung eines beliebigen Chiffretextes C anfordern und die entsprechende Entschlüsselung (C) zurückerhalten können, können Sie möglicherweise eine Signatur für die Nachricht M fälschen, indem Sie C = Hash (M) und lassen dann nach Entschlüsselung fragen (C). Moderne Systeme sind nicht anfällig für * diesen * bestimmten Angriff, aber es ist schwierig zu wissen, ob es möglicherweise komplexere Versionen dieser Art von Angriff auf ein bestimmtes System gibt. Wenn Sie einen Schlüssel sowohl für die Verschlüsselung als auch für die Signatur wiederverwenden, werden in der Regel alle Sicherheitsnachweise oder sonstigen Überprüfungen ungültig.
Aha. Das macht Sinn, danke! Aber ich verstehe, dass es derzeit keine * bekannten * praktischen Angriffe gibt? (Abgesehen von schlechten Praktiken und vor allem ** mangelnder Sicherheit **)
@AviD, Ich weiß es nicht. Könnte sein. Ich weiß nicht, ob es bekannte Angriffe gibt. Das würde eine sorgfältige Literaturrecherche erfordern, was ich nicht getan habe. Selbst wenn die Antwort "keine bekannt" ist, würde ich mich nicht darauf verlassen. Wenn jeder Kryptograf weiß, dass dies ein schlechter Weg ist, um Systeme zu entwerfen, dass er gegen die Nutzungsbedingungen bei ordnungsgemäßer Verwendung eines Kryptosystems verstößt, weiß ich nicht, ob Kryptoanalytiker ihre Zeit damit verbringen werden, nach praktischen Angriffen dieser Form zu suchen, und selbst wenn Sie gefundene Angriffe, ich weiß nicht, ob sie veröffentlichbar wären. Fazit: Die Verwendung eines Schlüssels für beide Zwecke wird nicht empfohlen.
Je nachdem, wo (sonst) die Schlüssel verwendet werden, kann es zu praktischen Angriffen kommen. Wie DW sagt, müssen Sie nur in der Lage sein, jedes C für Sie zu entschlüsseln - dies könnte beispielsweise bei Authentifizierungs-Handshakes möglich sein, bei denen zufällige Nonces verwendet werden. Während es wahrscheinlich möglich ist, dies aus dem Authentifizierungsprotokoll heraus zu entwerfen, ist es einfacher und sicherer, es einfach unmöglich zu machen, indem Schlüssel überhaupt nicht für mehrere Zwecke verwendet werden.
Ich stimme zu, dass es eine schlechte Idee ist. Trotzdem scheint S / MIME beide (Verschlüsselung und Signatur) mit einem einzigen Schlüssel / Zertifikat-Paar zu versehen, wenn ich mich nicht irre.
Am1rr3zA
2011-01-23 04:51:04 UTC
view on stackexchange narkive permalink

Es gibt einige Gründe, warum wir nicht denselben Schlüssel für die Verschlüsselung und Signatur verwenden sollten.

  1. Wir müssen unseren geheimen Schlüssel für verschlüsselte Daten sichern. Später möchten wir einige alte verschlüsselte Nachrichten entschlüsseln, müssen jedoch unseren geheimen Schlüssel zum Signieren nicht sichern. Wenn der Angreifer den Schlüssel findet, können wir unsere Zertifizierungsstelle anweisen, ihn zu widerrufen und einen neuen geheimen Schlüssel zum Signieren zu erhalten, ohne dass eine Sicherung erforderlich ist.

  2. Wichtiger: Wenn wir denselben Schlüssel für die Verschlüsselung und Signatur verwenden, kann der Angreifer damit unsere verschlüsselte Nachricht entschlüsseln. Dies würde er / sie tun:

    Der Angreifer muss eine Zufallszahl r auswählen, wobei

    r sein muss GDC (N, r) = 1 ,
    und N ist die Nummer, die zum Erstellen eines privaten und öffentlichen Schlüssels verwendet wird ( N = pq ).

    Dann wählt der Angreifer eine neue Nachricht ( m ′ ) und sendet diese zum Signieren an den Absender:

    m ′ = m ^ er ^ e (hier ist (e, n) der öffentliche Schlüssel)

    Wenn der Absender m ′ wir bekommen

    m '^ d ≡ (m ^ er ^ e) ^ d ≡ mr (mod N)

    Jetzt nur noch der Angreifer muss es durch r "teilen", um m (die geheime Nachricht) zu erhalten.

  3. ol>
Dies scheint spezifisch für RSA zu sein und nicht für alle asymmetrischen Chiffren.
Warum sollte der Angreifer Zugriff auf N und dergleichen haben?
@Avid Attacker haben standardmäßig Zugriff auf N, da Sie (N, e) veröffentlichen müssen, wenn Sie Ihren öffentlichen Schlüssel veröffentlichen möchten.
"Wenn der Absender m 'unterschreibt, erhalten wir m' ^ d" Warum? Um etwas mit RSA zu signieren, wenden Sie nicht einfach die Operation des privaten Schlüssels darauf an. Sie hashen es und wenden Polsterung an. Ihr Angriff funktioniert also nicht. (Es gibt Ausnahmen, die Verwendung eines Schlüssels für Blindsignatur und Verschlüsselung wäre für diesen Angriff offen, aber Blindsignatur ist eine spezielle Anwendung und keine normale Signatur.)
@CodesInChaos Die Beschreibung des Risikos bei Verwendung des gleichen Schlüssels für die Signatur und Verschlüsselung wird zu stark vereinfacht. Im Bereich der Sicherheit sollte jedoch ein vereinfachtes Beispiel dafür ernst genommen werden, warum etwas ein Problem sein könnte. Auf der anderen Seite möchten Sie strenge Beweise, bevor etwas als sicher gilt. Wenn Sie nur handwedelnde Argumente für und gegen die Sicherheit einer Praxis haben, müssen Sie auf Nummer sicher gehen.
Die Anforderung GDC (N, r) = 1 ist nicht sehr wichtig. Sollte der Angreifer zufällig ein r auswählen, für das dies nicht der Fall ist, hat er die Verschlüsselung trotzdem aufgehoben.
@kasperd "er hat die Verschlüsselung sowieso gebrochen" nur im Zwei-Prim-Fall. Im Prinzip könnte der Modul zwei große und eine Reihe kleiner Faktoren enthalten. Während dies bei normalen RSA-Schlüsseln im Allgemeinen nicht der Fall ist, ist die Generierung böswilliger Schlüssel bei Blindsignaturschemata ein Problem.
@CodesInChaos Das ist interessant. Ich habe nicht versucht, die Berechnungen durchzuführen, um festzustellen, ob Informationen durchgesickert sind, wenn N mehr als zwei Primfaktoren hat.
@kasperd Sie verlieren Informationen, wenn Sie nicht sicherstellen, dass die (aufgefüllte) Nachricht den Modul nicht teilt. Dies kann ein Problem sein, wenn der Modul viele kleine Faktoren aufweist.
Einige Quellen / Links wären hier toll ..
moo
2014-05-29 06:25:40 UTC
view on stackexchange narkive permalink

Gründe für die Verwendung separater Schlüssel zum Signieren und Verschlüsseln:

  1. Nützlich in der Organisation war, dass Verschlüsselungsschlüssel gesichert oder in einem Treuhandkonto aufbewahrt werden müssen, um Daten zu entschlüsseln, sobald ein Mitarbeiter / Benutzer der Organisation Nein ist länger Erhältlich. Im Gegensatz zum Verschlüsselungsschlüssel darf der Entwurfsschlüssel niemals von jemand anderem als dem Mitarbeiter / Benutzer verwendet werden und darf und sollte nicht in einem Treuhandkonto aufbewahrt werden.
  2. Ermöglicht unterschiedliche Ablaufzeiten für das Signieren eines Verschlüsselungsschlüssels.
  3. Da die zugrunde liegende Mathematik für die Verschlüsselung und das Signieren dieselbe ist, nur in umgekehrter Reihenfolge, wenn ein Angreifer einen Schlüsselhalter überzeugen / austricksen kann, eine unformatierte verschlüsselte Nachricht mit demselben Schlüssel zu signieren, wenn der Angreifer das Original erhält.
  4. Referenzen

    1. https://www.entrust.com/what-is -pki /

    2. https://www.gnupg.org/gph/en/manual/c235.html

    3. http://www.di-mgt.com.au/rsa_alg.html

    4. ol>
Alle Links / Quellen für 3 verfügbar bitte ...
@alfonx Ich habe möglicherweise die ursprünglichen Links vergessen, von denen ich diese Punkte erhalten habe, aber ich habe sie in der angegebenen Reihenfolge in Referenzen bearbeitet. Ich hoffe das hilft. Ich bin mir nicht sicher, ob all dies die zuverlässigsten Referenzen sind, aber die Punkte sind sinnvoll, wenn Sie mit [PKI] gearbeitet haben (https://www.comodo.com/resources/small-business/digital-certificates1.php).
@moo Punkt 3 ist nur eine gute Bemerkung zum asymmetrischen RSA-Schlüsselkonzept.Der Angriff existiert jedoch nicht in der Praxis des Signierens von Dokumenten in der realen Welt (wie PGP, das in dieser Frage berücksichtigt wird).Dies liegt daran, dass PGP nur einen Nachrichtenauszug (auch als sicherer Hash bezeichnet) der ursprünglichen Nachricht signiert, anstatt den privaten Schlüssel auf die gesamte Nachricht anzuwenden.
@JohnnyWong stimmte zu, dass ein realer Angriff mit diesem Konzept von der Implementierung abhängen würde.Das OP erwähnte GPG / PGP als Beispiel, aber es scheint mir, dass das OP eine allgemeinere Begründung für diese Praxis wollte.Angesichts der Tatsache, dass sich Implementierungen häufig genug ändern, denke ich, dass dieser Punkt für jeden, der sich mit PKI befasst, sehr wichtig ist, und ich entscheide mich, Punkt 3 nicht zu entfernen. Vielleicht hätte ich eine Notiz dazu machen können, aber ich denke, dass unsere Kommentare jetzt diesem Zweck dienen.Vielen Dank.
David Bakker
2015-04-01 15:13:56 UTC
view on stackexchange narkive permalink

Für mich hängen die Hauptgründe eher mit der Schlüsselverwaltung als mit der kryptografischen Sicherheit an sich zusammen.

Bei asymmetrischer Krypto kann insbesondere der Zeitraum, in dem ein öffentlicher Schlüssel gültig sein soll, stark von der beabsichtigten Verwendung dieses Schlüssels abhängen. Stellen Sie sich beispielsweise ein System vor, in dem sich eine Komponente gegenüber anderen Komponenten authentifizieren muss. Darüber hinaus muss diese Komponente regelmäßig eine Signatur für einige Daten erstellen. Theoretisch könnte ein einziger privater Schlüssel für beide Zwecke verwendet werden. Angenommen, die PKI-Zertifizierungsstelle möchte aus Sicherheitsgründen den Zeitraum, in dem eine erfolgreiche Authentifizierung basierend auf einem einzelnen Zertifikat erfolgen kann, auf zwei Jahre beschränken. Gleichzeitig können die Gesetze zur Vorratsdatenspeicherung vorschreiben, dass die Daten fünf Jahre lang aufbewahrt werden und dass die Unterschrift über diese Daten während des gesamten Zeitraums überprüfbar sein muss. Die einzige (solide) Möglichkeit, dieses Problem zu lösen, besteht darin, der Komponente zwei private Schlüssel zu geben: einen zur Authentifizierung und einen zum Signieren. Das Zertifikat des ersten Schlüssels läuft nach zwei Jahren ab, das Zertifikat zum Signieren nach fünf Jahren.

Ähnliche Überlegungen können auf die symmetrische Kryptographie angewendet werden: Wenn Sie unterschiedliche Schlüssel für unterschiedliche Zwecke verwenden, können Sie entscheiden bei allen Fragen der Schlüsselverwaltung (z. B. Häufigkeit des Roll-Over des Hauptschlüssels, Zeitraum zum Sichern der Schlüssel usw.) auf der Grundlage der Anforderungen eines einzelnen Zwecks. Wenn Sie einen einzelnen (Haupt-) Schlüssel für mehrere Zwecke verwenden, kann dies zu widersprüchlichen Anforderungen führen.

Piquan
2019-07-29 13:59:16 UTC
view on stackexchange narkive permalink

Die RSA-Verschlüsselung basiert auf einer Trapdoor-Funktion, dh einem Funktionspaar. Ich werde sie D und E nennen. Die Funktionen sind so ausgelegt, dass D (E (x)) = x und E (D (x)) = x (für jedes x ). Mit anderen Worten sind D und E invers. Was es zu einer Trapdoor-Funktion macht, ist, dass Sie, wenn Sie einen öffentlichen Schlüssel haben, nur E (praktisch) berechnen können. Wenn Sie einen privaten Schlüssel haben, können Sie sowohl D als auch E berechnen.

Die Funktionsweise der Verschlüsselung ist aus dieser Beschreibung ziemlich offensichtlich. Wenn Bob Alice eine verschlüsselte Nachricht senden möchte, berechnet er chiffretext: = E (Klartext) . Dann sendet Bob Chiffretext an Alice. Alice berechnet D (Chiffretext) , was D (E (Klartext)) ist, was nur Klartext ist.

Lassen Sie uns nun darüber sprechen, wie das Signieren funktioniert. Wenn Alice eine Nachricht signieren möchte, berechnet sie die Signatur: = D (Nachricht) . Sie sendet dann sowohl die Nachricht als auch die Signatur an Bob. Bob berechnet dann die -Validierung: = E (Signatur) . Da Signatur D (Nachricht) ist, ist Validierung = E (D (Nachricht)) = Nachricht .

In Mit anderen Worten: Um eine Nachricht zu signieren, tun Sie so, als würden Sie sie entschlüsseln, und das ist Ihre Signatur. Um Ihre Signatur zu überprüfen, können Benutzer die Signatur verschlüsseln und sicherstellen, dass sie Ihre ursprüngliche Nachricht zurückerhalten.

Ich sage das noch einmal: Das Signieren ist der gleiche Vorgang wie das Entschlüsseln.

Dies ist das grundlegende Anliegen bei der Trennung von Signatur- und Verschlüsselungsschlüsseln. Wenn jemand Sie dazu bringen kann, etwas zu unterschreiben, hat er Sie gerade dazu gebracht, es zu entschlüsseln.

Angenommen, Sie führen eine Notarfirma. Wenn Ihnen jemand 10 US-Dollar und eine Nachricht (z. B. Songtexte) gibt, unterschreiben Sie diese Nachricht und senden sie Ihnen zurück. Wenn jemand später Ihre Songtexte kopiert, können Sie die Unterschrift des vertrauenswürdigen Notars vorlegen, um zu demonstrieren, dass Sie diese Songtexte geschrieben haben.

Nehmen wir nun an, Eve hat eine verschlüsselte Nachricht an Ihre Notarfirma abgefangen. Wie kann sie die Verschlüsselung untergraben? Sie sendet Ihnen dieselbe Nachricht zur Beglaubigung! Jetzt führen Sie die Signaturoperation aus (die, wie Sie sich erinnern, mit der Entschlüsselungsoperation identisch ist) und senden das Ergebnis an sie zurück. Sie hat jetzt die entschlüsselte Nachricht.

In der Praxis haben Protokolle Schritte, die diesen Angriff erschweren. Zum Beispiel signiert PGP (womit ich das Protokoll meine; gpg ist hier die häufigste Implementierung) nicht die ursprüngliche Nachricht; Es signiert einen Hash der Nachricht. Sicherheitsnachweise sind jedoch in einfachen Situationen am besten. Sie möchten nicht, dass Ihr Beweis für die Sicherheit von RSA von der Hash-Funktion abhängt. (Zum Beispiel haben viele Leute MD5 lange Zeit als bevorzugten Hash verwendet, aber heute wird MD5 als ziemlich kaputt angesehen.) Allein die Sicherheit von RSA hängt von der Idee ab, dass Sie keine willkürlichen Nachrichten mit einem Schlüssel signieren, der für die Verschlüsselung verwendet wird. Die Einhaltung dieser Anforderung ist der beste Weg, um die Sicherheit von PGP zu gewährleisten. (Soweit ich mich erinnere, ist dies die am häufigsten wiederholte Ermahnung zur asymmetrischen Verschlüsselung in Bruce Scheiers Buch Angewandte Kryptographie .)

Lassen Sie uns nun darüber sprechen Eine weitere Frage, die Sie gestellt haben: "Würde dies nicht auch bedeuten, dass Sie zwei öffentliche Schlüssel an alle Personen verteilen müssen, mit denen Sie kommunizieren möchten?"

Ein "Schlüssel" bedeutet für Benutzer eine Sache und für andere eine andere die Krypto-Implementierungen. Sie müssen nur einen "Schlüssel" auf Benutzerebene kommunizieren, obwohl dieser möglicherweise viele öffentliche RSA-Schlüssel enthält.

PGP hat ein Konzept von Unterschlüsseln. Mein Hauptschlüssel ist ein Nur-Signatur-Schlüssel. Ich habe einen separaten Verschlüsselungsunterschlüssel. Dieser Unterschlüssel ist von meinem Hauptschlüssel signiert. Wenn Sie meinen PGP-Schlüssel von den Keyservern importieren oder von meiner Website herunterladen, erhalten Sie meinen Hauptschlüssel und alle meine Unterschlüssel. Auch wenn Sie möglicherweise nur meinen Hauptschlüssel signiert haben, hat mein Hauptschlüssel meinen Verschlüsselungsunterschlüssel signiert, sodass Sie wissen, dass er auch mir gehört. Das bedeutet, dass Sie durch das Herunterladen meines PGP-Schlüssels (der viele öffentliche RSA-Schlüssel umfasst) jetzt alles haben, was Sie zum Überprüfen meiner Signaturen und zum Verschlüsseln von Nachrichten an mich benötigen.

Mit Unterschlüsseln ist die Schlüsselverwaltung komplexer Vom kryptografischen Standpunkt aus (es muss noch ein zusätzlicher Schritt zur Schlüsselüberprüfung durchgeführt werden), aber nicht vom praktischen Standpunkt aus (mein PGP-Schlüssel enthält meinen Hauptschlüssel sowie alle meine Unterschlüssel). Die zusätzliche Komplexität ist in der Implementierung verborgen und dem Benutzer nicht zugänglich.



Diese Fragen und Antworten wurden automatisch aus der englischen Sprache übersetzt.Der ursprüngliche Inhalt ist auf stackexchange verfügbar. Wir danken ihm für die cc by-sa 2.0-Lizenz, unter der er vertrieben wird.
Loading...