Ecrecover: ¿pasar el hash y verificarlo agrega algo de seguridad?

He visto bastantes ejemplos en los que se pasan tanto los datos como el hash de los datos.

La firma se verifica usando ecrecoverlo cual está bien.

El hash pasado también se verifica contra el hash calculado. No veo qué agrega esa segunda verificación en términos de integridad del mensaje y verificación del autor. Si el hash calculado se usa para verificar la firma y es incorrecto, la verificación de la firma debería fallar. Me estoy perdiendo de algo ?

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

}

Respuestas (2)

Si necesita probar que los datos que está tratando de validar son los indicados, debe verificar que coincidan con el hash que produce una firma válida. De lo contrario, todo lo que está verificando es que la clave en cuestión firmó algo, pero no lo que firmaron.

La parte que su ejemplo podría haber omitido es pasar el hash a la función como parámetro. Simplemente podría haber calculado el hash nuevamente a partir de los datos y luego verificar que el hash se firmó con la clave correcta.

En algunos flujos de trabajo, es posible que haya creado el hash antes y lo haya almacenado como el identificador de su contrato en lugar de los datos. En ese caso, puede omitir el paso de los datos en esta etapa y simplemente trabajar con el hash.

Entonces estamos de acuerdo en que, cuando puedes calcular el hash, pasarlo no agrega nada. Bien ?
Correcto, solo la cadena de datos habría funcionado en este ejemplo. Luego haga el hash con eso y use ecrecover para verificar que la firma sea correcta.
¿Por qué los datos firmados siempre producen la misma longitud de salida, es decir, 132 caracteres de datos que se pueden dividir en r/s/v, si la entrada puede tener una longitud arbitraria? Un mensaje firmado no es un hash, entonces, ¿por qué produce una salida de tamaño fijo? ¿Esto implica que eth_signhash el mensaje antes de firmar?
Las operaciones de firma ECC funcionan en 32 bytes de datos, por lo que, si sugiere una función de firma que tome texto sin formato como parámetro, lo codificará antes de firmar. (También puede anteponer un poco de texto sin formato adicional antes del hash para evitar que parezca una transacción normal). No sé suficiente criptografía para decirle cómo se relaciona eso con la longitud de los datos de la firma.

Creo que la propiedad criptográfica que esta función intenta verificar es la integridad :

El cifrado de clave pública envolvente (EPKE) es el método de aplicar criptografía de clave pública y garantizar que una comunicación electrónica se transmita de forma confidencial, tiene el contenido de la comunicación protegido contra modificaciones (integridad de la comunicación)

fuente wikipedia

Mirar la función de forma aislada (sin ningún contexto de proceso comercial) hace que sea difícil estar seguro de lo que esta función de verificación espera lograr, cómo se llama, etc. el cheque haciéndose pasar por otra cuenta

ecrecover devolverá la clave pública, junto con la clave privada, de la cuenta utilizada para firmar este mensaje; el problema de llamar a esta función de manera ingenua es una especie de " ataque de repetición" .

Como actor malintencionado, digamos que me beneficia poder suplantar la clave pública P.

Digamos también que hay un protocolo de comunicación en el que le damos un mensaje a los clientes y les pedimos que lo firmen para verificar su identidad para autenticarlos.

Digamos también que su sistema tomó ingenuamente el contenido de un mensaje devuelto por el cliente y no verificó que el hash coincidiera con el mensaje original.

Como actor malintencionado, podría suplantar a P buscando en la cadena de bloques los mensajes que M le ha devuelto e inyectar uno de esos en mi respuesta. Ecrecover devolvería la clave pública P y la función de verificación se subvertiría.

Ecrecover: ¿pasar el hash y verificarlo agrega algo de seguridad?
RespuestasAquíPolítica de privacidad1y, 0v