Ecrecover: добавляет ли безопасность передача хэша и его проверка?

Я видел довольно много примеров, когда передаются как данные, так и хэш данных.

Подпись проверяется с помощью ecrecoverчего все в порядке.

Переданный хэш также сверяется с рассчитанным хэшем. Я не вижу, что добавляет эта вторая проверка с точки зрения целостности сообщения и проверки отправителя. Если вычисленный хэш используется для проверки подписи, и он неверен, проверка подписи должна завершиться ошибкой. Я что-то пропустил ?

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));

}

Ответы (2)

Если вам нужно доказать, что данные, которые вы пытаетесь проверить, соответствуют заявленным, вам нужно проверить, соответствуют ли они хэшу, который создает действительную подпись. В противном случае все, что вы проверяете, это то, что рассматриваемый ключ что-то подписал, но не то, что они подписали.

Часть, которую ваш пример мог бы опустить, - это передача хэша в функцию в качестве параметра. Вы могли бы просто снова вычислить хеш из данных, а затем проверить, что хеш был подписан с правильным ключом.

В некоторых рабочих процессах вы могли создать хэш ранее и сохранить его в качестве идентификатора для вашего контракта вместо данных. В этом случае вы можете пропустить передачу данных на этом этапе и просто работать с хешем.

Итак, мы согласны с тем, что, когда вы можете вычислить хэш, его передача ничего не добавляет. Верно ?
Верно, в этом примере сработала бы только строка данных. Затем сделайте хэш с этим и используйте ecrecover, чтобы проверить правильность подписи.
Почему подписанные данные всегда выдают одинаковую длину, т. е. 132 символа данных, которые можно разделить на r/s/v, если ввод может быть произвольной длины? Подписанное сообщение не является хешем, так почему же оно выводит фиксированный размер? Означает ли это, что eth_signхеширует сообщение перед подписанием.
Операции подписи ECC работают с 32 байтами данных, поэтому, если вы предлагаете функцию подписи, которая принимает открытый текст в качестве параметра, будет хешировать его перед подписью. (Кроме того, перед хешированием может быть добавлен дополнительный открытый текст, чтобы он не выглядел как обычная транзакция.) Я недостаточно знаю криптографию, чтобы сказать вам, как это связано с длиной данных подписи.

Я считаю, что криптографическим свойством, которое эта функция пытается проверить, является целостность :

Шифрование с открытым ключом в оболочке (EPKE) — это метод применения криптографии с открытым ключом, обеспечивающий конфиденциальность электронного сообщения и защиту содержимого сообщения от изменения (целостность связи).

источник википедия

Глядя на функцию изолированно (без какого-либо контекста бизнес-процесса), трудно быть уверенным в том, чего эта функция проверки надеется достичь, как она вызывается и т. д., но я думаю, что это делается для того, чтобы злоумышленник не смог подорвать проверка, выдавая себя за другую учетную запись

ecrecover вернет открытый ключ в паре с закрытым ключом учетной записи, использованной для подписи этого сообщения — проблема с наивным вызовом этой функции является своего рода «атакой воспроизведения» .

Допустим, как злонамеренный субъект, что мне выгодно олицетворять открытый ключ P.

Допустим также, что есть протокол связи, в котором мы отправляем клиентам сообщение и просим их подписать его, чтобы подтвердить свою личность для их аутентификации.

Допустим также, что ваша система просто наивно взяла содержимое сообщения, возвращенного клиентом, и не проверила совпадение его хеша с исходным сообщением.

Как злоумышленник, я мог бы выдать себя за P, просмотрев в блокчейне сообщения, которые M вернул вам, и внедрив одно из них в свой ответ. Ecrecover вернет открытый ключ P, и функция проверки будет нарушена.

Ecrecover: добавляет ли безопасность передача хэша и его проверка?
СпросиСетьПолитика конфиденциальности1y, 0v