it-swarm.com.de

Wie groß ist das Risiko, einen Teil eines privaten Schlüssels öffentlich zu teilen?

Wenn zwei Personen überprüfen möchten, ob sie denselben privaten Schlüssel (z. B. 256 Bit) haben, wie groß ist das Risiko, die ersten 8 Zeichen über einen potenziell öffentlichen Kanal zu teilen?

Kann ein Angreifer mehr Informationen als nur diese Charaktere wiederherstellen und/oder wie viel schneller könnte ein Angreifer angesichts dieser 8 Zeichen den Schlüssel knacken?

35
Jamie Bull

Durch die Bereitstellung eines beliebigen Teils des privaten Schlüssels wird dieser zumindest geringfügig weniger sicher, da ein Angreifer einen kleineren potenziellen Schlüsselbereich zum Erkunden hat.

Ich verstehe nicht, was Sie erreichen wollen. Das einzige, was zwei Personen tun müssen, um zu überprüfen, ob sie dieselben Informationen haben, ist den Austausch eines Hashs.

Wenn Sie ein Protokoll entwerfen und sich Sorgen über Wiederholungsangriffe machen, können Sie sich davor schützen, indem Sie mithilfe eines HMAC eine Challenge-Antwort ausführen.

Bearbeiten :

Wie in den Kommentaren vorgeschlagen und in D.W.'s aufschlussreiche Antwort erklärt, muss ich betonen, dass die Auswirkungen auf die Sicherheit Ihres privaten Schlüssels sehr viel davon abhängen, welchen Algorithmus Sie verwenden. Im schlimmsten Fall wird wenn nur ein kleiner Teil des privaten Schlüssels angezeigt wird, die Sicherheit dieses Schlüssels vollständig verletzt.

80
Stephane

Das Aufdecken eines Teils des privaten Schlüssels kann für einige asymmetrische Kryptosysteme (mit öffentlichem Schlüssel) katastrophal sein. Das genaue Risiko hängt davon ab, welches Kryptosystem Sie verwenden. Einige Beispiele:

  • Wenn Sie RSA mit e = 3 für den öffentlichen Schlüssel verwenden, reicht es aus, 1/4 des privaten Schlüssels (die niedrigen 1/4 Bits von d) freizulegen, damit ein Angreifer den gesamten privaten Schlüssel rekonstruieren kann. Wenn Sie beispielsweise 2048-Bit-RSA verwenden und die 512 niedrigstwertigen Bits des privaten Schlüssels anzeigen, kann ein Angreifer den Rest Ihres privaten Schlüssels wiederherstellen. Dieses Ergebnis ist Boneh, Durfee und Frankel zu verdanken. Es gibt ähnliche Ergebnisse in der Literatur (z. B. über die höchstwertigen Bits, eine zufällige Teilmenge von Bits usw.).

  • Wenn bei DSA einige Bits aus der in jeder Signatur verwendeten Nonce (für eine Vielzahl von Signaturen) verloren gehen, reicht dies aus, um den privaten Schlüssel wiederherzustellen. Wenn Sie beispielsweise 5 Bits der geheimen Nonce beobachten können, die in jeder der 4000 Signaturen verwendet wurde, reicht dies aus, um einen privaten 384-Bit-ECDSA-Schlüssel wiederherzustellen. Dies enthüllt nicht genau den privaten Schlüssel (es enthüllt einen anderen geheimen Wert, der während des Signierens generiert wird), aber es ist ähnlich.

Mir ist klar, dass andere Antworten sagen, dass es kein Problem ist. Bei diesen Antworten wird möglicherweise davon ausgegangen, dass Sie ein Kryptosystem mit symmetrischen Schlüsseln verwenden. Bei den meisten Kryptosystemen mit symmetrischen Schlüsseln sind sie wahrscheinlich immer noch sicher, wenn Sie einen Teil des Schlüssels offenlegen, aber genügend Schlüssel nicht offengelegt werden. Bei asymmetrischen Kryptosystemen sieht das anders aus. Andere Antworten scheinen davon auszugehen, dass Brute Force (erschöpfende Prüfung aller möglichen privaten Schlüssel) der bestmögliche Angriff gegen das Kryptosystem ist. Für viele asymmetrische Kryptosysteme ist diese Annahme nicht korrekt.

54
D.W.

Wie viel schneller könnte ein Angreifer angesichts dieser 8 Zeichen den Schlüssel knacken?

Es ist schwer zu beantworten, ohne zu wissen, um welche Art von Schlüssel es sich handelt und mit welchem ​​Algorithmus er verwendet wird.

Im Fall einer symmetrischen Verschlüsselung, bei der der Schlüssel vollständig zufällig ist (verstehen Sie, dass jedes Bit gleichermaßen an der globalen Unsicherheit des Schlüssels beteiligt ist), hängt dies hauptsächlich davon ab, was "1 Zeichen" in Bezug auf Binärdaten darstellt. Im Allgemeinen reduzieren Sie durch das Aufdecken von n bits Die Anzahl der möglichen Schlüssel effektiv um einen Faktor von mindestens 2^n.

  • Bei einer binären Textdarstellung mit 1 character = (0 or 1) = 1 bit: 8 Zeichen bedeutet dies einen Reduktionsfaktor von 2^8 = 256.
  • Bei einer hexadezimalen Darstellung mit 1 character = 4 bits Bedeutet 8 Zeichen einen Reduktionsfaktor von 2^32 = 4294967296.
  • Bei einer base64-Darstellung mit 1 character = 6 bits Bedeutet 8 Zeichen einen Reduktionsfaktor von 2^48 = 281474976710656.

Was - abhängig von der Menge der offenbarten Informationen - als Hebel verwendet werden kann (oder auch nicht), um Ihren Schlüssel zu brechen, abhängig von den möglichen (aktuellen oder zukünftigen) Schwächen Ihres Verschlüsselungsalgorithmus.

Beachten Sie auch, dass im Fall einer asymmetrischen Verschlüsselung, bei der der Schlüssel nicht vollständig zufällig ist (z. B. Primfaktor-Modul und Exponent in RSA), das Aufdecken von n bits Tatsächlich viel nützlichere Informationen enthüllen und zu einem katastrophalen Sicherheitsverlust führen kann.

Aber die eigentliche Frage ist:

Warum sollte jemand das jemals tun müssen?

Diese Methode stellt nicht nur eine potenzielle Sicherheitslücke dar, sie scheint auch nicht zu Ihrem Zweck zu passen. Was ist mit den verbleibenden 248 Bit?

Die von Ihnen beschriebene Methode ist nur eine sehr triviale Hash-Funktion, die vollständig kontinuierlich (sehr schlecht für die Integritätsprüfung) und teilweise reversibel (sehr schlecht für Sicherheitszwecke) ist.

Wenn Sie wirklich dies tun müssen, verwenden Sie eine sichere und weit verbreitete kryptografische Hash-Funktion wie SHA-256, die a generiert Hash, der viel mehr sicher (praktisch irreversibel und rechenintensiv) und viel mehr kollisionssicher ist als "die ersten 8 Zeichen".

Wenn Sie asymmetrische Verschlüsselung verwenden, sollten Sie niemals einen Teil (sogar einen Hash) des privaten Schlüssels freigeben müssen, verwenden Sie stattdessen den öffentlichen Schlüssel.

23
zakinster

Ich würde sagen, es reicht von "nicht kritisch, aber irgendwie dumm" bis "katastrophal", abhängig davon, was "8 Zeichen" bedeuten und welche Algorithmen verwendet werden.

Wenn man "8 Zeichen" als das liest, was sie buchstäblich sind, 64 Bit, dann reduzieren Sie Ihre Schlüsselgröße um 64 Bit (es ist etwas weniger drastisch, wenn man "Zeichen" als Base-64-codiertes Zeichen annimmt, dann wären es nur 48 Bit ).

Angenommen, "privater Schlüssel" bezieht sich tatsächlich auf einen symmetrischen Algorithmus (unwahrscheinlich?), Ist dies wahrscheinlich tolerierbar, da 192 Bits für Brute-Force weit über das Mögliche hinausgehen. Aber warum sollte man überhaupt einen 256-Bit-Schlüssel verwenden?

Angenommen, "privater Schlüssel, 256 Bit" bedeutet, dass Sie eine Art Krypto mit elliptischen Kurven verwenden (für symmetrische Chiffren ist "privat" wenig sinnvoll, da alle Schlüssel privat sind und für RSA et al. 256 Bit viel zu klein, um nützlich zu sein), senken Sie Ihre Sicherheitsstufe von etwas unter 128 Bit (was derzeit nicht möglich ist) auf etwas weniger als 96 Bit. Welches ist ... na ja, nicht genau machbar, aber fast. In Anbetracht dessen, dass Quantencomputer noch nicht ganz da ist, aber auf dem Weg ist "nicht ganz, aber fast" ein bisschen katastrophal.
Schließlich plant man den schlimmsten Fall, nicht den besten Fall.

Es ist umso katastrophaler, als dies absolut zu 100% unnötig ist.

Wenn zwei Parteien einen geheimen Schlüssel gemeinsam nutzen, besteht eine sehr offensichtliche Methode, um sicherzustellen, dass es sich um denselben Schlüssel handelt, darin, ein ausreichend langes (länger als die Hash-Ausgabe) zufälliges Bitmuster zu verschlüsseln, die andere Seite das Bitmuster entschlüsseln zu lassen und ein sicheres zurückzusenden Hash (z. B. SHA-256, SHA3, was auch immer) des Bitmusters.
Was die erste Partei trivial mit dem Ergebnis der Berechnung des Hash anhand des ursprünglichen Zufallsmusters vergleichen kann.

Zu keinem Zeitpunkt wird der private Schlüssel (oder ein Teil davon) übertragen oder sogar ein Hash dieses Schlüssels (der sehr, sehr unwahrscheinlich, aber möglicherweise umgekehrt sein könnte oder einen Hinweis auf einen Teil davon geben könnte), und da es mehr zufällige gibt Eingangsbits als Ausgangsbits ist es unmöglich, das ursprüngliche Bitmuster, das gehasht wurde, aus dem Hashwert zu bestimmen und dieses zu verwenden, um einen Winkel für die Verschlüsselung zu erhalten.

Der Angreifer sieht nur ein zufälliges Bitmuster, für das er den (unbekannten) Schlüssel kennen muss, um das Original zu erhalten, und den Hash eines anderen unbekannten Bitmusters, das eines von vielen Bitmustern sein kann (ohne zu wissen, welches ).

8
Damon

Andere haben bereits geantwortet, um wie viel die Informationen durchgesickert sind und um wie viel die Entropie für einen Angreifer verringert ist; und der Hauptpunkt, den man (öffentlich) Hashes vergleichen sollte, wurde ebenfalls erwähnt.

Dies setzt jedoch voraus, dass die beiden Personen, die Schlüssel vergleichen möchten, sich gegenseitig vertrauen. Wenn sie sich nicht vertrauen, besteht das Problem darin, dass B, wenn A Hash (K) an B sendet, wissen kann, dass A dasselbe oder ein anderes K als B hat, aber er kann denselben Hash betrügen und zurücksenden. A fälschlicherweise denken lassen, dass B auch den gleichen Schlüssel besitzt.

Eine Lösung für dieses Problem besteht darin, dass A Hash (K) an B sendet und erwartet, dass B Hash (nicht K) an A sendet, wobei nicht K der bitweise gespiegelte Wert von K ist. B kann diesen Hash nur an A senden, wenn dies der Fall ist besitzt wirklich K.

6
entrop-x

NOTE Das Folgende setzt eine lineare Beschleunigung voraus (wie sie bei einem Brute-Force-Angriff erzielt werden würde) - die Beschleunigung kann je nach Algorithmus EXPONENTIELL MEHR sein.

Es ist sehr schwierig, große Zahlen zu verstehen - selbst ich war überrascht, als die Antwort kam. Hier ist eine Art, darüber nachzudenken:

Wenn es ohne Informationen 13,8 Milliarden Jahre (das bisherige Alter des Universums) dauern würde, um einen Schlüssel mit Hilfe von 8 Binärzeichen zu knacken, würde es nur 0,023 Sekunden dauern.

Dies ist: 13,8 Milliarden Jahre/2(bits_per_symbol * number_of_symbols).

Sie sagten, die Anzahl der Symbole sei "8 Zeichen", und ich gehe von einer Binärdatei aus, die 8 Bits pro Symbol enthält. also: 13,8 Milliarden Jahre/2(8 * 8)

Wenn sie uuencodiert oder base64 sind, haben sie 6 Bits pro Symbol, sodass sie alle 25 Minuten benötigen, um die verbleibenden Kombinationen durchzuarbeiten.

Diese Proportionen gelten nur für die Anzahl der von Ihnen aufgedeckten Bits und sind unabhängig davon, wie lang der Schlüssel ist (nur, dass das Knacken des Schlüssels 13,8 Milliarden Jahre dauern würde).

Der springende Punkt bei der Kryptografie mit öffentlichen Schlüsseln ist, dass Sie NIEMALS den privaten Schlüssel freigeben müssen. Jeder private Schlüssel sollte nur an einem Ort vorhanden sein und niemals über ein Netzwerk übertragen werden. Das Senden von Schlüsseln verstößt gegen das Prinzip der Kryptographie mit öffentlichen Schlüsseln. Es ist NIEMALS erforderlich, private Schlüssel teilweise oder auf andere Weise zu senden.

Wenn Sie möchten, dass zwei (oder mehr) verschiedene Geräte dieselbe Nachricht dekodieren können, lassen Sie jedes seinen eigenen privaten Schlüssel erstellen, senden Sie ihm seinen öffentlichen Schlüssel (sicher !!) und verschlüsseln Sie die Nachricht mit beiden Schlüsseln. Normalerweise werden bei PKC lange Nachrichten mithilfe einer symmetrischen Verschlüsselung mit einem zufälligen Schlüssel verschlüsselt. Der Schlüssel wird dann mit PKC verschlüsselt und mit der Nachricht gesendet. Sie können den Zufallsschlüssel einfach mit mehreren öffentlichen Schlüsseln verschlüsseln und alle mit derselben Nachricht senden.

Wenn Sie nur zeigen möchten, dass Sie den privaten Schlüssel haben, können Sie Folgendes tun:

Bitten Sie die Person, der Sie dies beweisen möchten, einen zufälligen Wert (eine "Nonce") anzugeben. Fügen Sie einen eigenen zufälligen Wert hinzu, hashen Sie ihn und signieren Sie den Hash. Senden Sie Ihren Zufallswert und die Unterschrift zurück.

Ihr Gegenüber nimmt dann die von ihm gesendete Nonce sowie Ihren zufälligen Wert, hasht sie und vergleicht die Signatur mit Ihrem öffentlichen Schlüssel.

Das Einbeziehen eines zufälligen Werts vom Absender zeigt, dass Sie nicht nur einen Wert ausgewählt haben, der zuvor vom tatsächlichen Eigentümer signiert wurde.

Unter keinen Umständen etwas akzeptieren, das von jemand anderem gesendet wurde, und es ohne Änderungen unterschreiben. Sie können Ihnen den Fingerabdruck eines Dokuments senden, das sie geschrieben haben, und Sie werden dieses Dokument effektiv signieren.

4
AMADANON Inc.

Wenn Alice und Bob den Verdacht haben, dass sie denselben privaten Schlüssel verwenden, warum nicht:

  1. Alice generiert Nonce X.
  2. Alice verschlüsselt X für sich selbst - Y.
  3. Alice schickt X, Y an Bob.
  4. Wenn Alice und Bob wirklich denselben privaten Schlüssel haben, erhält Bob beim Entschlüsseln von Y X. Jetzt weiß Bob, dass Alice seinen privaten Schlüssel teilt.
  5. Bob macht dasselbe umgekehrt. Jetzt weiß Alice, dass Bob seinen privaten Schlüssel teilt.

Ich bin kein kryptografischer Experte. Vermisse ich etwas

Ich denke, die oben genannten werden ihre Frage befriedigen, ohne ihre Geheimnisse preiszugeben. Eva wird auch die Antwort auf die Frage nicht wissen.

2
emory