Ecrecover: Bringt das Übergeben des Hashs und das Überprüfen zusätzliche Sicherheit?

Ich habe einige Beispiele gesehen, bei denen sowohl die Daten als auch der Hash der Daten übergeben wurden.

Die Signatur wird überprüft, ecrecoverwas in Ordnung ist.

Der übergebene Hash wird auch gegen den berechneten Hash verifiziert. Ich sehe nicht, was diese zweite Überprüfung in Bezug auf die Nachrichtenintegrität und die Überprüfung des Absenders hinzufügt. Wenn der berechnete Hash zur Überprüfung der Signatur verwendet wird und falsch ist, sollte die Signaturüberprüfung fehlschlagen. Übersehe ich etwas?

function Check(string data, bytes32 hash, bytes32 r, bytes32 s, uint8 v) public returns (bool) {

    var calculatedHash = keccak256(this, data);

    // do we need this ?
    assert(hash == calculatedHash);

    // should not this one be sufficient ?
    assert(msg.sender == ecrecover(calculatedHash, v, r, s));

}

Antworten (2)

Wenn Sie nachweisen müssen, dass die Daten, die Sie zu validieren versuchen, den Angaben entsprechen, müssen Sie überprüfen, ob sie mit dem Hash übereinstimmen, der eine gültige Signatur erzeugt. Andernfalls überprüfen Sie nur, ob der betreffende Schlüssel etwas signiert hat, aber nicht das, was er signiert hat.

Der Teil, den Ihr Beispiel hätte weglassen können, besteht darin, den Hash als Parameter an die Funktion zu übergeben. Sie hätten den Hash einfach erneut aus den Daten berechnen und dann überprüfen können, ob der Hash mit dem richtigen Schlüssel signiert wurde.

In einigen Workflows haben Sie den Hash möglicherweise früher erstellt und anstelle der Daten als Kennung für Ihren Vertrag gespeichert. In diesem Fall können Sie die Übergabe der Daten an dieser Stelle überspringen und einfach mit dem Hash arbeiten.

Wir sind uns also einig, dass, wenn Sie den Hash berechnen können, das Übergeben nichts hinzufügt. Rechts ?
Richtig, in diesem Beispiel hätte nur der Datenstring funktioniert. Machen Sie dann den Hash damit und überprüfen Sie mit ecrecover, ob die Signatur richtig ist.
Warum erzeugen die vorzeichenbehafteten Daten immer die gleiche Ausgabelänge, dh 132 Datenzeichen, die in r/s/v aufgeteilt werden können, wenn die Eingabe beliebig lang sein kann? Eine signierte Nachricht ist kein Hash, warum erzeugt sie also eine Ausgabe mit fester Größe? Bedeutet dies, dass eth_signdie Nachricht vor dem Signieren gehasht wird?
ECC-Signaturoperationen arbeiten mit 32 Datenbytes. Wenn Sie also eine Signierfunktion vorschlagen, die Klartext als Parameter verwendet, wird dieser vor dem Signieren gehasht. (Es kann auch einen zusätzlichen Klartext vor dem Hashing voranstellen, um zu vermeiden, dass es wie eine normale Transaktion aussieht.) Ich kenne nicht genug Krypto, um Ihnen zu sagen, wie sich das auf die Länge der Signaturdaten bezieht.

Ich glaube, die kryptografische Eigenschaft, die diese Funktion zu überprüfen versucht, ist die Integrität :

Enveloped Public Key Encryption (EPKE) ist die Methode zur Anwendung der Public-Key-Kryptographie und stellt sicher, dass eine elektronische Kommunikation vertraulich übertragen wird und der Inhalt der Kommunikation vor Änderungen geschützt ist (Kommunikationsintegrität).

Quelle Wikipedia

Betrachtet man die Funktion isoliert (ohne Geschäftsprozesskontext), ist es schwierig, sich sicher zu sein, was diese Prüffunktion zu erreichen hofft, wie sie aufgerufen wird usw. Ich vermute jedoch, dass sie verhindern soll, dass ein böswilliger Akteur sie unterwandern kann den Scheck, indem Sie sich für ein anderes Konto ausgeben

ecrecover gibt den öffentlichen Schlüssel zusammen mit dem privaten Schlüssel des Kontos zurück, das zum Signieren dieser Nachricht verwendet wurde - das Problem beim naiven Aufrufen dieser Funktion ist eine Art " Wiedergabeangriff" .

Nehmen wir als böswilliger Akteur an, dass es für mich von Vorteil ist, den öffentlichen Schlüssel P imitieren zu können.

Nehmen wir auch an, dass es ein Kommunikationsprotokoll gibt, bei dem wir Kunden eine Nachricht geben und sie bitten, sie zu unterschreiben, um ihre Identität zu überprüfen und sie zu authentifizieren.

Nehmen wir auch an, dass Ihr System einfach naiv den Inhalt einer vom Client zurückgegebenen Nachricht genommen und nicht überprüft hat, ob der Hash mit der ursprünglichen Nachricht übereinstimmt.

Als böswilliger Akteur könnte ich mich als P ausgeben, indem ich in der Blockchain nach den Nachrichten suche, die M an Sie zurückgesendet hat, und eine davon in meine Antwort einfügen würde. Ecrecover würde den öffentlichen Schlüssel P zurückgeben und die Prüffunktion würde unterlaufen.

Ecrecover: Bringt das Übergeben des Hashs und das Überprüfen zusätzliche Sicherheit?
AntwortenHierDatenschutz-Bestimmungen1y, 0v