¿Keccak-256 es lo mismo que SHA3-256?

No. Keccak-256 es lo que Keccak presentó al NIST; SHA3-256 añadió dos bits de padding antes de finalizar. Mismo input, salida diferente. Ethereum y la EVM usan Keccak-256 original.

¿Dónde aparece en Ethereum?

En selectores de función, derivación de storage slots, checksums EIP-55, direcciones deterministas CREATE2 y la mayoría de esquemas de firma que requieren digest de 256 bits.

¿La salida es determinista?

Sí. Keccak-256 es función pura. La misma secuencia UTF-8 produce el mismo digest de 32 bytes, sin importar el navegador o la ejecución.

¿Toova registra mi entrada?

No. El hash se calcula localmente en esta pestaña. La cadena y el digest no viajan a ningún servidor.

¿Sirve para ABI encoding?

Aplica Keccak-256 sobre la firma canónica de la función, p. ej. transfer(address,uint256), y toma los 4 primeros bytes — es exactamente el prefijo que esperan los selectores.

Hash Keccak-256 — el que usa Ethereum (EIP-55)

Hash Keccak-256

Privacidad por diseño — se ejecuta completamente en tu navegador

Pon cualquier cadena UTF-8 en el cuadro y obtén el digest Keccak-256 de 32 bytes. Es el algoritmo que Ethereum usa por todas partes: direcciones checksum del EIP-55, selectores de función, derivación de storage slot y direcciones de contratos por CREATE2.

Keccak-256 contra SHA3-256

Keccak-256 fue la propuesta de Keccak al NIST antes de convertirse en SHA3. El estándar final SHA3 cambió la regla de padding (multi-rate padding ganó dos bits extra), así que SHA3-256 y Keccak-256 del mismo input difieren. Ethereum se quedó con el Keccak original para que los hashes on-chain casen con wallets, indexers y exploradores que también usan Keccak-256.

Dónde lo usa Ethereum

Los selectores de función son los primeros 4 bytes de keccak256("transfer(address,uint256)") y firmas canónicas similares. Los storage slots de mappings derivan de keccak256(abi.encode(key, slot)). EIP-55 alterna mayúsculas/minúsculas en base al keccak256 de la dirección en minúsculas. Las direcciones de contrato vía CREATE2 son keccak256 sobre deployer, salt y bytecode.

Cómo corre la implementación

La página lleva una permutación Keccak-f[1600] compacta en JavaScript. Web Crypto no la expone. Puedes verificarla comparando con el digest conocido del string vacío c5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470. Inputs y outputs no salen de la pestaña.

Preguntas frecuentes

¿Keccak-256 es lo mismo que SHA3-256?: No. Keccak-256 es lo que Keccak presentó al NIST; SHA3-256 añadió dos bits de padding antes de finalizar. Mismo input, salida diferente. Ethereum y la EVM usan Keccak-256 original.
¿Dónde aparece en Ethereum?: En selectores de función, derivación de storage slots, checksums EIP-55, direcciones deterministas CREATE2 y la mayoría de esquemas de firma que requieren digest de 256 bits.
¿Cómo validar la implementación?: Haz el hash del string vacío y compara con c5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470. Cualquier diferencia delata padding o algoritmo erróneo.
¿La salida es determinista?: Sí. Keccak-256 es función pura. La misma secuencia UTF-8 produce el mismo digest de 32 bytes, sin importar el navegador o la ejecución.
¿Toova registra mi entrada?: No. El hash se calcula localmente en esta pestaña. La cadena y el digest no viajan a ningún servidor.
¿Sirve para ABI encoding?: Aplica Keccak-256 sobre la firma canónica de la función, p. ej. transfer(address,uint256), y toma los 4 primeros bytes — es exactamente el prefijo que esperan los selectores.