Transformación Fiat–Shamir: ¿Qué es la transformación Fiat–Shamir?La transformación Fiat–Shamir es una técnica criptográfica que convierte determinados protocolos interactivos de prueba en pruebas no interactivas o firmas digitaTransformación Fiat–Shamir: ¿Qué es la transformación Fiat–Shamir?La transformación Fiat–Shamir es una técnica criptográfica que convierte determinados protocolos interactivos de prueba en pruebas no interactivas o firmas digita
¿Qué es la transformación Fiat–Shamir?
La transformación Fiat–Shamir es una técnica criptográfica que convierte determinados protocolos interactivos de prueba en pruebas no interactivas o firmas digitales.Elimina la necesidad de que el verificador envíe directamente al probador un nuevo desafío aleatorio.En su lugar, el probador calcula el desafío aplicando un hash al transcript del protocolo, el enunciado público, el compromiso, el mensaje y otros datos de contexto necesarios.La prueba resultante se puede crear una sola vez y cualquier persona que disponga de la misma información pública puede verificarla más adelante.La técnica también se denomina heurística Fiat–Shamir porque su seguridad suele depender de modelar la función hash criptográfica como un oráculo aleatorio.Amos Fiat y Adi Shamir presentaron este enfoque en su trabajo de 1986, How to Prove Yourself: Practical Solutions to Identification and Signature Problems.
La transformación es importante en las criptomonedas porque los sistemas blockchain no siempre pueden permitir comunicaciones privadas repetidas entre cada probador y cada verificador.Las pruebas no interactivas pueden incluirse en transacciones, bloques, llamadas a contratos inteligentes, pruebas de rollups, firmas y mensajes cross-chain.¿Qué problema resuelve la transformación Fiat–Shamir?
Muchos protocolos de prueba de conocimiento se diseñaron originalmente como conversaciones entre un probador y un verificador.En primer lugar, el probador se compromete con una aleatoriedad oculta o con información relacionada con un secreto.A continuación, el verificador envía un desafío aleatorio que el probador no podría haber previsto antes de realizar el compromiso.El probador responde utilizando el testigo secreto y el desafío.El verificador comprueba que el compromiso, el desafío, la respuesta y el enunciado público satisfagan las ecuaciones del protocolo.Esta interacción puede resultar poco práctica en una red descentralizada, ya que el probador y el verificador deben estar conectados al mismo tiempo e intercambiar varios mensajes.Una transacción blockchain puede ser verificada más adelante de forma independiente por miles de nodos que no estaban presentes cuando se creó la prueba.La transformación Fiat–Shamir sustituye el desafío aleatorio en tiempo real del verificador por un desafío hash determinista que todos los verificadores pueden volver a calcular.Así se crea un transcript de prueba portátil que se puede almacenar, transmitir y verificar sin contactar con el probador original.¿Cómo funciona una prueba interactiva?
Un protocolo interactivo habitual de tres mensajes consta de un compromiso, un desafío y una respuesta.El probador conoce un valor secreto denominado testigo.El enunciado público describe lo que el probador afirma conocer o el cálculo que afirma haber completado correctamente.En el primer paso, el probador genera aleatoriedad privada y produce un compromiso.En el segundo paso, el verificador genera un desafío aleatorio impredecible.En el tercer paso, el probador combina el testigo, la aleatoriedad privada y el desafío para calcular una respuesta.El verificador solo acepta si la respuesta es coherente con el compromiso, el desafío y el enunciado público.El desafío debe ser impredecible cuando se crea el compromiso.De lo contrario, un probador deshonesto podría construir un compromiso que funcionara únicamente para un desafío seleccionado de antemano.¿Cómo funciona la transformación Fiat–Shamir?
La transformación elimina el segundo mensaje del verificador y lo sustituye por un cálculo de hash criptográfico.En primer lugar, el probador crea el mismo compromiso que habría utilizado en el protocolo interactivo.A continuación, aplica un hash al enunciado público, el compromiso, el mensaje, el identificador del protocolo y otros datos necesarios del transcript.La salida del hash se convierte en un desafío perteneciente al espacio de desafíos válidos del protocolo.El probador calcula la respuesta utilizando ese desafío y el testigo secreto.La prueba no interactiva final suele contener el compromiso y la respuesta, mientras que el verificador puede volver a calcular el desafío.El verificador reconstruye el transcript, calcula el mismo desafío hash y ejecuta la ecuación de verificación original.La transformación simplificada se puede representar así:challenge = Hash(protocol_context || public_statement || commitment || message)
Las entradas exactas y las reglas de codificación son fundamentales para la seguridad.Ejemplo del protocolo Schnorr
El protocolo de identificación Schnorr es un ejemplo claro de la transformación Fiat–Shamir.Supongamos que un grupo cíclico tiene un generador
g
y orden q
.El probador tiene una clave privada
x
y una clave pública Y = g^x
.El probador quiere demostrar que conoce
x
sin revelarlo.En el protocolo interactivo, el probador elige un valor aleatorio
r
y envía el compromiso R = g^r
.El verificador responde con un desafío aleatorio
c
.El probador calcula
s = r + c × x mod q
.El verificador comprueba si
g^s = R × Y^c
.Una respuesta válida demuestra que el probador puede satisfacer la ecuación para el desafío impredecible.Aplicación de Fiat–Shamir al protocolo Schnorr
La versión no interactiva sustituye el desafío generado por el verificador por un hash.El probador calcula un desafío como
c = Hash(context || Y || R || message)
.A continuación, calcula
s = r + c × x mod q
.La prueba o firma contiene el compromiso
R
y la respuesta s
.El verificador vuelve a calcular el desafío a partir de la misma clave pública, el compromiso, el contexto y el mensaje.El verificador acepta la prueba si se cumple la ecuación de verificación de Schnorr.La RFC 8235 especifica una prueba de conocimiento cero no interactiva Schnorr creada a partir del esquema de identificación Schnorr de tres pasos mediante la transformación Fiat–Shamir.
Cómo crea una firma digital la transformación
Una prueba de identificación demuestra que un probador conoce un secreto asociado a una identidad pública.Para crear una firma digital, el desafío también vincula la prueba a un mensaje concreto.Si se cambia el mensaje, cambia la salida del hash y, por tanto, también el desafío.Normalmente, una prueba creada para una transacción no se puede reutilizar como firma válida para otra transacción.La respuesta del firmante demuestra que conoce la clave privada y vincula ese conocimiento al mensaje firmado.Este patrón que convierte una identificación en una firma es uno de los usos más importantes de la transformación Fiat–Shamir.Fiat–Shamir y las firmas Schnorr de Bitcoin
La BIP 340 de Bitcoin especifica firmas Schnorr para la curva elíptica secp256k1.El desafío de la firma se obtiene aplicando un hash al compromiso del nonce, la clave pública y el mensaje.Esto sigue el patrón de firma Schnorr no interactiva asociado a la transformación Fiat–Shamir.La BIP 340 también utiliza hashes etiquetados para separar sus cálculos de hash de otros usos del protocolo.
El hashing etiquetado añade a la entrada un valor derivado de una etiqueta específica del protocolo.Esto reduce el riesgo de que la misma función hash y el mismo formato de entrada se interpreten como dos operaciones criptográficas distintas.Las firmas BIP 340 se utilizan en las reglas de transacción Taproot de Bitcoin.La transformación es más amplia que Bitcoin y puede utilizarse con muchos sistemas de prueba, grupos algebraicos y supuestos criptográficos.Fiat–Shamir en los sistemas de prueba de conocimiento cero
Los sistemas modernos de prueba de conocimiento cero suelen partir de un protocolo que resulta más fácil de describir como una interacción entre un probador y un verificador.El probador envía compromisos polinómicos, raíces de Merkle, elementos de grupo u otros mensajes.El verificador responde con elementos aleatorios del campo o posiciones de consulta.Fiat–Shamir obtiene esos desafíos del transcript, en vez de exigir que haya un verificador conectado.Esto permite generar una prueba off-chain y verificarla más adelante en un nodo blockchain o un contrato inteligente.La transformación se utiliza en sistemas que permiten realizar transacciones privadas, pruebas de validez, rollups escalables, cálculos verificables e interoperabilidad entre blockchains.Fiat–Shamir en Halo2
Halo2 describe su protocolo de prueba de forma interactiva para analizarlo, pero lo implementa de forma no interactiva mediante la transformación Fiat–Shamir.El transcript contiene compromisos y otros mensajes del probador.Las salidas de hashes criptográficos se convierten en desafíos del verificador utilizados para evaluaciones polinómicas y comprobaciones de pruebas.La documentación del protocolo Halo2 explica que un argumento interactivo de moneda pública pasa a ser no interactivo al sustituir al verificador por una función hash criptográficamente robusta.
Halo2 también analiza propiedades de seguridad que tienen en cuenta la capacidad del probador para construir y revisar estados del transcript.Esto demuestra que aplicar Fiat–Shamir de forma segura requiere algo más que sustituir un generador de números aleatorios por una llamada a una función hash.Fiat–Shamir en las pruebas STARK
Los sistemas de pruebas STARK utilizan varias rondas de compromisos y desafíos del verificador.Los desafíos pueden determinar coeficientes aleatorios, puntos de evaluación polinómica y consultas para las pruebas de bajo grado.Un canal Fiat–Shamir obtiene esta aleatoriedad no interactiva del transcript de prueba, que se va actualizando.El probador incorpora los compromisos al canal antes de solicitar el siguiente desafío.El verificador repite las mismas operaciones del transcript y obtiene los mismos desafíos.La documentación del probador STARK describe un canal Fiat–Shamir que se utiliza para generar aleatoriedad no interactiva durante la construcción de la prueba.
Si cambian los compromisos o las entradas públicas, también deberían cambiar los desafíos posteriores.¿Qué es el modelo de oráculo aleatorio?
El modelo de oráculo aleatorio es un modelo de seguridad que trata una función hash como una función aleatoria pública ideal.Cada entrada única recibe una salida aleatoria e independiente.Si se repite una entrada, siempre se obtiene la misma salida.Cualquiera puede consultar el oráculo, pero nadie puede predecir una nueva salida sin realizar la consulta correspondiente.Las funciones hash reales son algoritmos deterministas, no oráculos aleatorios ideales.Una prueba de seguridad Fiat–Shamir en el modelo de oráculo aleatorio demuestra la seguridad bajo este supuesto idealizado.A continuación, los implementadores utilizan una función hash criptográfica real, que se considera suficientemente parecida al modelo para el protocolo.El modelo de oráculo aleatorio es útil, pero una prueba en ese modelo no constituye una prueba incondicional sobre cualquier implementación posible de una función hash.¿Por qué el hash debe incluir el transcript completo?
Cada desafío debe quedar vinculado a toda la información anterior del protocolo que influya en su significado.Esto puede incluir parámetros públicos, claves públicas, enunciados, compromisos, mensajes, desafíos anteriores, identificadores de cadena y versiones del protocolo.Omitir un valor importante puede permitir trasladar una prueba a otro contexto.Una prueba podría ser válida para dos claves públicas, dos aplicaciones, dos redes blockchain o dos etapas de protocolo cuando debería serlo solo para una.En una prueba de varias rondas, cada desafío debe depender del transcript acumulado antes de generarlo.El probador debe comprometerse con los datos anteriores antes de conocer el desafío derivado.Aplicar un hash solo al mensaje final puede destruir las garantías de orden necesarias para el protocolo interactivo.¿Qué es la separación de dominios?
La separación de dominios garantiza que una operación hash no se confunda con otra que utilice la misma función subyacente.Un protocolo puede anteponer una etiqueta única, como su nombre, versión, red, etapa de prueba o tipo de operación.La etiqueta cambia la entrada del hash aunque el resto de los datos sea idéntico.Sin separación de dominios, un valor creado como desafío en un protocolo podría interpretarse como nonce, compromiso o desafío en otro.La separación de dominios es especialmente importante en el software de criptomonedas, donde una misma función hash puede reutilizarse para identificadores de transacción, firmas, árboles de Merkle, derivación de claves y transcripts de prueba.El hashing etiquetado específico del protocolo en la BIP 340 es un ejemplo práctico de esta protección.
¿Por qué es importante la codificación canónica?
El probador y el verificador deben aplicar un hash exactamente a la misma secuencia de bytes.En ocasiones, un valor matemático puede tener varias representaciones válidas en bytes.Los enteros se pueden codificar con distintas longitudes, órdenes de bytes o ceros iniciales.Los puntos de curva elíptica pueden tener codificaciones comprimidas, no comprimidas u otras alternativas no válidas.Las listas pueden resultar ambiguas si las longitudes y los límites de sus elementos no se codifican claramente.La serialización canónica define una única representación aceptada para cada valor válido del transcript.Los prefijos de longitud, las etiquetas de tipo, los campos de longitud fija y las reglas estrictas de descodificación pueden evitar ambigüedades.Una implementación debe rechazar los valores no canónicos, en lugar de normalizarlos de forma distinta a otro verificador.Longitud del desafío y solidez
El espacio de desafíos influye en la probabilidad de que un probador deshonesto pueda tener éxito sin conocer un testigo válido.Un desafío de un solo bit ofrece a un probador fraudulento una probabilidad relativamente alta de acertar en una ronda.Repetir el protocolo o utilizar un desafío más amplio reduce este error de solidez.La salida del hash debe convertirse en un desafío de tamaño suficiente para el nivel de seguridad requerido.Truncar el desafío de forma demasiado agresiva puede debilitar la prueba.La conversión de las salidas hash a un campo o al orden de un grupo tampoco debe introducir un sesgo estadístico inaceptable.Los protocolos pueden utilizar muestreo por rechazo, reducción ampliada u otro método documentado para derivar los desafíos correctamente.¿Qué es el grinding en Fiat–Shamir?
El grinding se produce cuando un probador modifica repetidamente una aleatoriedad de compromiso permitida y aplica un hash a cada transcript resultante hasta obtener un desafío favorable.El probador puede realizar esta búsqueda porque el desafío se genera localmente y no lo proporciona un verificador independiente conectado en tiempo real.El análisis de seguridad debe tener en cuenta el número de consultas al hash y el tamaño del espacio de desafíos.Un espacio de desafíos suficientemente amplio hace que el grinding útil sea computacionalmente inviable bajo los supuestos del protocolo.Las aplicaciones no deben añadir al transcript valores innecesarios controlados por el probador si estos abaratan el grinding o generan sesgo.Los sistemas de prueba que utilizan Fiat–Shamir deben analizar este comportamiento, en vez de suponer que el probador realiza una única consulta honesta al hash.Riesgos de repetición y vinculación al contexto
Una prueba no interactiva se puede copiar porque es un objeto de datos público.La copia no es problemática cuando la prueba solo demuestra un enunciado público atemporal.Se vuelve peligrosa si la aplicación interpreta erróneamente la posesión de la prueba como evidencia de una nueva acción o una autorización reciente.El transcript puede incluir un identificador de transacción, destinatario, red, valor de sesión, dirección del contrato, fecha de vencimiento o nonce específico de la aplicación.Esto vincula la prueba al contexto previsto.Añadir un valor de contexto no sirve de nada si el verificador no comprueba que ese valor coincide con la solicitud actual.Los requisitos de actualidad corresponden al protocolo completo de la aplicación, no solo a la ecuación de la prueba.¿Fiat–Shamir proporciona automáticamente conocimiento cero?
No, la transformación no convierte automáticamente cualquier protocolo en una prueba de conocimiento cero.El protocolo interactivo original debe tener las propiedades adecuadas de conocimiento cero o de conocimiento cero frente a un verificador honesto.El protocolo transformado también debe analizarse conforme al modelo de seguridad elegido.Los compromisos pueden requerir aleatoriedad de ocultación para evitar revelar el testigo.Es posible que los desafíos del transcript deban limitarse para evitar valores especiales que revelen información privada.Una prueba puede ser no interactiva sin ser de conocimiento cero.No interactiva solo significa que el probador puede generar la prueba sin recibir un mensaje de un verificador conectado en tiempo real.¿Fiat–Shamir garantiza automáticamente la solidez?
No, transformar un protocolo de forma segura no demuestra que cualquier protocolo parecido sea seguro.El protocolo interactivo original debe tener las propiedades de solidez, solidez especial o prueba de conocimiento necesarias.Las entradas del hash y la conversión de desafíos deben preservar el orden previsto: primero el compromiso y después el desafío.Algunos protocolos requieren supuestos más sólidos o pruebas especializadas después de la transformación.Una construcción puede ser segura en el modelo clásico de oráculo aleatorio y carecer de una prueba adecuada frente a adversarios cuánticos.Los desarrolladores deben utilizar una construcción revisada que cuente con una prueba de seguridad, en lugar de aplicar Fiat–Shamir informalmente a un protocolo nuevo.Fiat–Shamir y la criptografía poscuántica
El patrón de diseño Fiat–Shamir también aparece en la investigación sobre firmas poscuánticas.Los esquemas de identificación basados en retículas, códigos y computación multipartita pueden utilizar desafíos derivados de hashes para crear firmas.Algunas firmas basadas en retículas utilizan una variante conocida como Fiat–Shamir con abortos.El firmante puede reiniciar parte del proceso de firma si una respuesta intermedia pudiera revelar información o quedar fuera de la distribución aceptada.La NIST FIPS 204 estandariza ML-DSA, un algoritmo de firma digital basado en retículas modulares y derivado del diseño Dilithium.
La existencia de estándares de firmas poscuánticas no significa que todas las pruebas Fiat–Shamir clásicas sigan siendo seguras frente a un ordenador cuántico.Fiat–Shamir en el modelo cuántico de oráculo aleatorio
Un adversario cuántico puede consultar un oráculo aleatorio modelado mediante una superposición de muchas entradas.Esto es distinto de un adversario clásico que envía una consulta ordinaria cada vez.Las pruebas clásicas en el modelo de oráculo aleatorio no siguen siendo válidas automáticamente en el modelo cuántico de oráculo aleatorio, abreviado comúnmente como QROM.Los investigadores en criptografía han desarrollado técnicas de prueba y condiciones de protocolo adicionales para analizar las construcciones Fiat–Shamir frente a atacantes cuánticos.Por tanto, una afirmación de seguridad poscuántica debe respaldarse con un análisis que cubra el QROM u otro modelo de seguridad cuántica adecuado.Sustituir un grupo clásico por un problema de retículas no es suficiente por sí solo.Fiat–Shamir y las firmas de umbral
Las firmas de umbral reparten la autoridad de firma entre varios participantes.El número requerido de participantes coopera para crear una única firma válida sin reconstruir la clave privada completa en un solo lugar.Los protocolos Schnorr de umbral deben coordinar cuidadosamente los compromisos de nonce y los cálculos de desafíos.El desafío debe vincular la clave pública combinada, el compromiso de nonce combinado, el mensaje, el contexto de los participantes y las reglas del protocolo.La construcción incorrecta del transcript puede permitir la manipulación de nonces, el comportamiento de claves fraudulentas o ataques entre sesiones.La RFC 9591 especifica el protocolo de firma Schnorr de umbral FROST y sus operaciones de suites criptográficas basadas en hashes.
Ventajas de la transformación Fiat–Shamir
La transformación elimina la interacción en tiempo real con el verificador en los sistemas de prueba compatibles.Una prueba se puede crear una sola vez y verificar de forma independiente en muchos nodos blockchain.Reduce las rondas de comunicación y simplifica la verificación asíncrona.Las pruebas se pueden incluir en transacciones, bloques, contratos inteligentes y almacenamiento distribuido.La misma prueba puede verificarse sin proporcionar al verificador aleatoriedad privada ni mantener una sesión interactiva.La transformación también ofrece una vía práctica para convertir protocolos de identificación en esquemas de firma digital.Estas propiedades la hacen valiosa para las redes descentralizadas, cuyos participantes quizá nunca se comuniquen directamente.Limitaciones de la transformación Fiat–Shamir
La transformación suele depender del modelo de oráculo aleatorio.No convierte de forma segura cualquier prueba interactiva posible.Las omisiones en el transcript y las incoherencias de codificación pueden generar vulnerabilidades graves.El probador puede evaluar el hash repetidamente, por lo que el análisis de seguridad debe tener en cuenta el grinding.Las pruebas no interactivas se pueden repetir, salvo que la aplicación las vincule a un contexto adecuado.La seguridad cuántica requiere un análisis independiente.La transformación no protege una implementación frente a filtraciones por canales laterales, aleatoriedad débil, corrupción de memoria o robo de claves privadas.Incluso una vez eliminada la interacción, generar pruebas puede seguir siendo costoso desde el punto de vista computacional.Transformación Fiat–Shamir frente a prueba interactiva
Una prueba interactiva requiere el intercambio de mensajes entre el probador y el verificador.Durante la interacción, el verificador aporta desafíos aleatorios nuevos.Una prueba Fiat–Shamir deriva esos desafíos de un hash del transcript.La prueba no interactiva es más fácil de distribuir y verificar de forma asíncrona.El protocolo interactivo puede basarse en una aleatoriedad auténtica del verificador, mientras que el protocolo transformado depende del comportamiento similar al de un oráculo aleatorio de una función hash.Transformación Fiat–Shamir frente a prueba no interactiva de conocimiento cero
La transformación Fiat–Shamir es un método para construir una prueba no interactiva.Una prueba no interactiva de conocimiento cero, o NIZK, es una categoría más amplia de pruebas que no requiere interacción en tiempo real con el verificador y no revela información protegida sobre el testigo.Algunas NIZK utilizan Fiat–Shamir, mientras que otras emplean una cadena de referencia común, una configuración de confianza, una configuración transparente u otras técnicas criptográficas.Decir que una prueba es no interactiva no indica el método utilizado para crearla.Transformación Fiat–Shamir frente a firma digital
Una firma digital autentica un mensaje mediante una clave privada y una clave pública de verificación.La transformación Fiat–Shamir es una técnica de construcción que puede convertir determinados protocolos de identificación en esquemas de firma.No todas las firmas digitales se crean mediante Fiat–Shamir.No todas las pruebas Fiat–Shamir están pensadas para funcionar como firmas digitales.Una prueba puede demostrar que se conoce un testigo o que un cálculo es correcto, sin autenticar a una persona o wallet.Transformación Fiat–Shamir frente a hash-to-curve
Hash-to-curve convierte datos de entrada arbitrarios en un punto válido de una curva elíptica.Fiat–Shamir convierte datos del transcript en desafíos del verificador.Un sistema de prueba puede utilizar ambas operaciones.El desafío puede ser un escalar, mientras que otro componente del protocolo puede requerir un punto de curva derivado de un hash.Ambos procesos necesitan reglas independientes de separación de dominios y codificación.Transformación Fiat–Shamir frente a commit-reveal
Un protocolo commit-reveal requiere que un participante publique un compromiso y revele posteriormente el valor oculto.Se puede utilizar para reducir el conocimiento anticipado o la manipulación de una aleatoriedad compartida.Fiat–Shamir no espera a que se revele públicamente una aleatoriedad más adelante.Genera un desafío determinista a partir del transcript existente.Commit-reveal y Fiat–Shamir resuelven problemas de coordinación distintos, aunque ambos utilizan compromisos criptográficos y hashes.Buenas prácticas de implementación
Los desarrolladores deben utilizar un sistema de prueba con un análisis de seguridad Fiat–Shamir publicado y revisado.El transcript debe incluir todos los valores públicos que definan el enunciado y su contexto.Cada protocolo y cada etapa de prueba deben tener una separación de dominios única.Todos los valores deben utilizar una serialización canónica con límites explícitos de tipo y longitud.Los compromisos deben incorporarse antes de generar los desafíos que dependen de ellos.Las salidas de los desafíos deben convertirse a campos o grupos mediante el método sin sesgo documentado.Se deben rechazar los puntos no válidos, los escalares no canónicos, los valores de campo prohibidos y los transcripts mal formados.La aleatoriedad del probador y los nonces de firma deben generarse de forma segura o derivarse mediante un método determinista aprobado.Las implementaciones deben comprobar que cualquier cambio en el enunciado, el compromiso, el mensaje, el identificador de red o la versión del protocolo modifica el desafío derivado.Los vectores de prueba deben cubrir el orden del transcript, la codificación, las etiquetas de dominio, los valores vacíos, los valores límite y las pruebas mal formadas.Errores habituales al implementar Fiat–Shamir
Un error consiste en aplicar un hash al compromiso sin incluir el enunciado público.Otro es omitir el mensaje cuando la prueba debe servir como firma.La concatenación ambigua puede hacer que dos transcripts distintos generen la misma secuencia de bytes.Utilizar la misma etiqueta de dominio en protocolos no relacionados puede provocar confusión entre protocolos.Generar un desafío posterior antes de incorporar todos los mensajes previos del probador rompe el orden del transcript.Reducir directamente un hash corto a un campo grande puede producir una entropía de desafío débil.Aceptar puntos de curva o escalares no canónicos puede hacer que distintas implementaciones apliquen hashes a representaciones diferentes.Reutilizar la aleatoriedad del probador puede revelar un testigo secreto en protocolos similares a Schnorr.Suponer que una prueba clásica proporciona automáticamente seguridad poscuántica es otro error grave.Por qué es importante la transformación Fiat–Shamir para las criptomonedas
Las redes de criptomonedas necesitan pruebas que los participantes de todo el mundo puedan verificar de forma independiente.Una transacción blockchain no puede depender de una conversación privada con cada nodo futuro que pueda verificarla.Fiat–Shamir permite empaquetar razonamientos criptográficos interactivos en un objeto de prueba estático.Esto permite utilizar firmas compactas, sistemas de privacidad, rollups de conocimiento cero, ejecución verificable de contratos inteligentes, wallets de umbral y otras aplicaciones blockchain.La transformación también ilustra un principio de diseño cripto importante.Una función hash puede hacer algo más que crear identificadores de transacción: también puede generar desafíos aparentemente impredecibles que vinculan entre sí todo el transcript de un protocolo.Esta capacidad depende de una construcción cuidadosa, una serialización precisa, una separación de dominios sólida y una prueba de seguridad adecuada.Preguntas frecuentes
¿Qué hace la transformación Fiat–Shamir?
Sustituye los desafíos aleatorios del verificador en determinados protocolos interactivos por desafíos derivados de un hash criptográfico del transcript.¿Por qué es útil Fiat–Shamir en las criptomonedas?
Permite que los nodos blockchain verifiquen pruebas y firmas más adelante, sin tener que mantener una conversación en tiempo real con el probador.¿Quién creó la transformación Fiat–Shamir?
Amos Fiat y Adi Shamir presentaron la técnica en un trabajo de 1986.¿La transformación Fiat–Shamir es lo mismo que una función hash?
No, es una transformación de protocolo que utiliza una función hash para generar desafíos del verificador.¿Qué es una prueba interactiva?
Es un protocolo en el que un probador y un verificador intercambian compromisos, desafíos y respuestas.¿Qué es un protocolo de moneda pública?
Es un protocolo interactivo en el que los mensajes del verificador consisten en desafíos aleatorios visibles públicamente.¿Qué es un transcript Fiat–Shamir?
Es la colección ordenada de parámetros públicos, enunciados, compromisos, desafíos, respuestas, mensajes y contexto utilizados por la prueba.¿Qué es el modelo de oráculo aleatorio?
Es un modelo de seguridad idealizado que trata una función hash como una función aleatoria pública con salidas coherentes.¿Una función hash real es un oráculo aleatorio?
No, una función hash real es determinista, aunque los protocolos pueden analizarla como si se comportara igual que un oráculo aleatorio ideal.¿Fiat–Shamir crea automáticamente conocimiento cero?
No, el protocolo original y la construcción transformada deben cumplir las condiciones de conocimiento cero requeridas.¿Fiat–Shamir crea una firma digital?
Puede convertir determinados protocolos de identificación en firmas si el hash del desafío incluye el mensaje.¿Bitcoin utiliza el patrón Fiat–Shamir?
Las firmas Schnorr de la BIP 340 de Bitcoin utilizan un desafío derivado de un hash que vincula el compromiso del nonce, la clave pública y el mensaje.¿Fiat–Shamir se utiliza en los rollups de conocimiento cero?
Muchos sistemas de prueba de rollups utilizan desafíos del transcript al estilo Fiat–Shamir para convertir protocolos interactivos en pruebas no interactivas.¿Fiat–Shamir se utiliza en los STARK?
Sí, los probadores y verificadores STARK pueden utilizar un canal Fiat–Shamir para derivar desafíos no interactivos a partir de compromisos.¿Fiat–Shamir se utiliza en Halo2?
Sí, Halo2 convierte su descripción interactiva de una prueba en un argumento no interactivo mediante Fiat–Shamir.¿Qué es la separación de dominios?
La separación de dominios añade etiquetas específicas del protocolo a las entradas hash para evitar que se confundan las salidas de distintas operaciones criptográficas.¿Por qué hay que aplicar un hash a la clave pública?
Aplicar un hash a la clave pública vincula la prueba o firma a la identidad prevista y puede evitar ataques de sustitución de claves o ataques entre claves.¿Por qué hay que aplicar un hash al mensaje?
Incluir el mensaje garantiza que una firma creada para un mensaje no se pueda reutilizar para otro.¿Qué es el grinding de desafíos?
El grinding de desafíos consiste en generar compromisos repetidamente hasta que el hash del transcript produce un desafío favorable al probador.¿Se pueden repetir las pruebas Fiat–Shamir?
Una prueba pública se puede copiar, por lo que los protocolos que exijan actualidad deben incluir y verificar un contexto de sesión o transacción adecuado.¿Qué es la serialización canónica?
La serialización canónica asigna una única representación en bytes aceptada a cada valor del transcript.¿Por qué es importante el orden del transcript?
Cada desafío debe depender de todos los mensajes anteriores para que el probador no pueda cambiar un compromiso después de conocerlo.¿Se puede utilizar Fiat–Shamir con curvas elípticas?
Sí, las pruebas y firmas Schnorr suelen aplicarla en grupos de curvas elípticas.¿Se puede utilizar Fiat–Shamir en criptografía poscuántica?
Sí, existen construcciones relacionadas en firmas poscuánticas, pero su seguridad requiere un análisis cuántico adecuado.¿Qué es el modelo cuántico de oráculo aleatorio?
Es un modelo en el que un adversario cuántico puede consultar el oráculo aleatorio mediante una superposición cuántica.¿Una prueba de seguridad clásica sigue siendo válida frente a atacantes cuánticos?
No automáticamente, ya que es posible que la prueba no tenga en cuenta las consultas cuánticas al oráculo ni las limitaciones cuánticas de extracción.¿Qué es Fiat–Shamir con abortos?
Es una variante en la que el firmante puede volver a empezar cuando una respuesta no cumple las condiciones de distribución o tamaño requeridas.¿Fiat–Shamir requiere una configuración de confianza?
No, la transformación en sí no requiere una configuración de confianza, aunque el sistema de prueba subyacente puede tener requisitos de configuración propios.¿Los contratos inteligentes pueden verificar pruebas Fiat–Shamir?
Sí, siempre que el contrato pueda reproducir el hash del transcript y comprobar las ecuaciones de la prueba de forma eficiente.¿Cuál es el mayor riesgo de implementación?
Entre los principales riesgos se encuentran la vinculación incompleta del transcript, la codificación ambigua, una separación de dominios deficiente, la generación débil de nonces y los supuestos de seguridad no respaldados.Conclusión
La transformación Fiat–Shamir convierte protocolos interactivos de moneda pública compatibles en pruebas no interactivas o firmas digitales.Sustituye el desafío impredecible de un verificador en tiempo real por un desafío derivado de un hash criptográfico del transcript de prueba.Esto permite que una prueba se cree una sola vez y sea verificada de forma independiente por nodos blockchain, wallets, contratos inteligentes y otras aplicaciones cripto.La transformación es compatible con firmas Schnorr, sistemas de prueba de conocimiento cero, STARK, protocolos de tipo Halo2, firmas de umbral e investigación sobre firmas poscuánticas.Su seguridad depende de las propiedades del protocolo interactivo original y de los supuestos utilizados para modelar la función hash.Las implementaciones correctas deben vincular el enunciado completo, el compromiso, el mensaje, los parámetros públicos, el contexto y la versión del protocolo en un transcript canónico.También deben utilizar una separación de dominios sólida, desafíos de tamaño suficiente, generación segura de nonces y reglas de conversión de desafíos revisadas cuidadosamente.La transformación Fiat–Shamir no mejora automáticamente la seguridad de todos los protocolos de prueba.Es una construcción potente cuya seguridad depende de un diseño riguroso del protocolo, una implementación disciplinada y un análisis de seguridad frente a atacantes clásicos y cuánticos.También te puede interesar
WhatsMiner M30S++
¿Qué es WhatsMiner M30S++? WhatsMiner M30S++ es un minero ASIC de Bitcoin de MicroBT diseñado para la minería Proof of Work con SHA-256. Forma parte de la serie WhatsMiner M30 y se utiliza principalme
2026/10/15 11:08
Dominios Web3
¿Qué son los dominios Web3? Los dominios Web3 son nombres basados en blockchain que pueden sustituir direcciones largas de carteras, dirigir a contenido descentralizado, representar una identidad on-c
2026/10/15 11:08
Proyectos Web3
¿Qué son los proyectos Web3? Los proyectos Web3 son aplicaciones, protocolos, herramientas, redes y comunidades basados en blockchain que utilizan tecnología descentralizada para dar a los usuarios ma
2026/10/15 11:06
POPULAR
Criptomonedas de moda que están acaparando la atención del mercado
Volumen TOP
Las criptomonedas con mayor volumen de trading
Recién Añadidos
Criptomonedas recientemente listadas y disponibles para operar