Wenn Sie einen Teil des privaten Schlüssels bereitstellen, wird dieser zumindest geringfügig weniger sicher, da ein Angreifer einen kleineren potenziellen Schlüsselbereich zum Erkunden hat.

Ich scheitere um zu verstehen, 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 eine Challenge-Antwort mit einem HMAC ausführen.

Bearbeiten :

Wie in den Kommentaren vorgeschlagen und in der aufschlussreichen Antwort von DW erläutert, muss ich betonen, dass die Auswirkungen auf die Sicherheit Ihres privaten Schlüssels sehr viel davon abhängen, welchen Algorithmus Sie verwenden benutzen. Im schlimmsten Fall wird die Sicherheit dieses Schlüssels vollständig beeinträchtigt, wenn nur ein kleiner Teil des privaten Schlüssels angezeigt wird.

Das Aufdecken eines Teils des privaten Schlüssels kann für einige asymmetrische Kryptosysteme (öffentlicher 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, wird 1/4 des privaten Schlüssels (die niedrigen 1/4 Bits von d) angezeigt genug, um einen Angreifer den gesamten privaten Schlüssel rekonstruieren zu lassen. 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. In der Literatur gibt es ähnliche Ergebnisse (z. B. über die höchstwertigen Bits, eine zufällige Teilmenge von Bits usw.).

• Bei DSA, wenn einige Bits vorhanden sind Dies reicht aus, um den privaten Schlüssel wiederherzustellen, wenn er aus der in jeder Signatur verwendeten Nonce (für eine Vielzahl von Signaturen) ausgetreten ist. 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 aufdecken, aber genügend Schlüssel nicht offengelegt werden. Bei asymmetrischen Kryptosystemen sieht das anders aus. Andere Antworten scheinen davon auszugehen, dass Brute Force (ausführliches Ausprobieren aller möglichen privaten Schlüssel) der bestmögliche Angriff auf das Kryptosystem ist. Für viele asymmetrische Kryptosysteme ist diese Annahme nicht korrekt.

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

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

Bei symmetrischer Verschlüsselung, bei der der Schlüssel völlig 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 Begriffen darstellt von binären Daten. Im Allgemeinen reduzieren Sie durch das Aufdecken von n Bits die Anzahl möglicher Schlüssel effektiv um einen Faktor von mindestens 2 ^ n .

• Bei einer binären Textdarstellung mit 1 Zeichen = (0 oder 1) = 1 Bit : 8 Zeichen bedeutet einen Reduktionsfaktor von 2 ^ 8 = 256 .
• Bei einer hexadezimalen Darstellung mit 1 Zeichen = 4 Bit : 8 Zeichen bedeutet einen Reduktionsfaktor von 2 ^ 32 = 4294967296 .
• Bei einer base64-Darstellung mit 1 Zeichen = 6 Bit : 8 Zeichen bedeutet ein Reduktionsfaktor von 2 ^ 48 = 281474976710656

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

Beachten Sie auch, dass bei asymmetrischer 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 aufdecken kann viel nützlichere Informationen und können zu einem katastrophalen Sicherheitsverlust führen.

Aber die eigentliche Frage ist:

Warum sollte jemand das jemals tun müssen?

Nicht nur diese Methode bietet eine potenzielle Sicherheit Fehler, es scheint nicht Zuverlässigkeit 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 müssen Sie dazu eine sichere und weit verbreitete kryptografische Hash-Funktion wie SHA-256 verwenden, die einen Hash generiert, der viel sicherer ist (praktisch irreversibel und rechenintensiv) und viel kollisionssicherer als "die ersten 8 Zeichen".

Wenn Sie asymmetrische Verschlüsselung verwenden, sollten Sie diese niemals benötigen Teilen Sie auch einen Teil (sogar einen Hash) des privaten Schlüssels, verwenden Sie stattdessen den öffentlichen Schlüssel .

Ich würde sagen, es reicht von "nicht kritisch, aber irgendwie dumm" bis "katastrophal", je nachdem, was "8 Zeichen" bedeutet und welche Algorithmen verwendet werden.

Wenn man liest " 8 Zeichen ", wie 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 macht "privat" wenig Da alle Schlüssel privat sind und für RSA et al. 256 Bit viel zu klein sind, 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, ist dies eine sehr offensichtliche Methode, um sicherzustellen, dass es sich um denselben Schlüssel handelt wäre, 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 einen sicheren Hash (z. B. SHA-256, SHA3, was auch immer) des Bitmusters zurückzusenden.
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) oder sogar ein Hash dieses Schlüssels übertragen (was sehr, sehr unwahrscheinlich, aber möglicherweise umgekehrt sein könnte oder einen Hinweis auf einen Teil davon geben könnte), und seitdem Sind mehr zufällige Eingabebits als Ausgabebits, 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 kann nur sehen 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).

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, einander 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 er wirklich K besitzt

HINWEIS Im Folgenden wird eine lineare Beschleunigung angenommen (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 mit Hilfe von 8 einen Schlüssel zu knacken Binärzeichen, es würde nur 0,023 Sekunden dauern.

Dies ist: 13,8 Milliarden Jahre / 2 ^{(bits_per_symbol * number_of_symbols) sup>.}

Sie sagte, die Anzahl der Symbole sei "8 Zeichen", und ich gehe von binär aus, die 8 Bits pro Symbol hat. Also: 13,8 Milliarden Jahre / 2 ^{(8 * 8) sup>}

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

Diese Proportionen gelten nur für die Anzahl der Bits, die Sie enthüllt haben, 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 anderweitig 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 und senden Sie ihn ihr öffentlicher Schlüssel (sicher !!) verschlüsselt dann 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 anzugeben (ein "Nonce"). . Fügen Sie einen eigenen zufälligen Wert hinzu, hashen Sie ihn und signieren Sie den Hash. Senden Sie Ihren zufälligen Wert und die Signatur zurück.

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

Das Einschließen 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.

Akzeptieren Sie unter keinen Umständen etwas, das von einer anderen Person gesendet wurde, und Unterzeichnung ohne Änderungen. Sie können Ihnen den Fingerabdruck eines Dokuments senden, das sie geschrieben haben, und Sie werden dieses Dokument effektiv signieren.

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 sendet X, Y an Bob.
4. Wenn Alice und Bob wirklich denselben privaten Schlüssel haben, erhält er X, wenn Bob Y entschlüsselt. Jetzt weiß Bob, dass Alice seinen teilt privater Schlüssel.
5. Bob macht dasselbe in umgekehrter Reihenfolge. Jetzt weiß Alice, dass Bob seinen privaten Schlüssel teilt.
ol>

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 kennen.