Transformação de Fiat–Shamir

O que é a transformação de Fiat–Shamir?

A transformação de Fiat–Shamir é uma técnica criptográfica que converte determinados protocolos interativos de prova em provas não interativas ou assinaturas digitais.

Ela elimina a necessidade de o verificador enviar diretamente ao provador um novo desafio aleatório.

Em vez disso, o provador calcula o desafio aplicando uma função hash ao transcript do protocolo, à declaração pública, ao compromisso, à mensagem e a outros dados de contexto necessários.

A prova resultante pode ser criada uma vez e verificada posteriormente por qualquer pessoa que tenha as mesmas informações públicas.

A técnica também é chamada de heurística de Fiat–Shamir porque sua segurança normalmente depende da modelagem da função hash criptográfica como um oráculo aleatório.

Amos Fiat e Adi Shamir apresentaram a abordagem em seu trabalho de 1986, How to Prove Yourself: Practical Solutions to Identification and Signature Problems.

A transformação é importante para as criptomoedas porque os sistemas blockchain nem sempre conseguem permitir comunicações privadas repetidas entre cada provador e verificador.

Provas não interativas podem ser incluídas em transações, blocos, chamadas de contratos inteligentes, provas de rollups, assinaturas e mensagens cross-chain.

Que problema a transformação de Fiat–Shamir resolve?

Muitos protocolos de prova de conhecimento foram originalmente desenvolvidos como conversas entre um provador e um verificador.

Primeiro, o provador se compromete com uma aleatoriedade oculta ou com informações relacionadas ao segredo.

Em seguida, o verificador envia um desafio aleatório que o provador não poderia prever antes de assumir o compromisso.

O provador responde usando o testemunho secreto e o desafio.

O verificador confere se o compromisso, o desafio, a resposta e a declaração pública satisfazem as equações do protocolo.

Essa interação pode ser inconveniente em uma rede descentralizada, pois o provador e o verificador precisam estar on-line ao mesmo tempo e trocar várias mensagens.

Uma transação blockchain pode ser verificada posteriormente, de forma independente, por milhares de nós que não estavam presentes quando a prova foi criada.

A transformação de Fiat–Shamir substitui o desafio aleatório enviado ao vivo pelo verificador por um desafio determinístico derivado de uma função hash que todos os verificadores podem recalcular.

Isso cria um transcript de prova portátil que pode ser armazenado, transmitido e verificado sem contatar o provador original.

Como funciona uma prova interativa?

Um protocolo interativo comum de três mensagens inclui um compromisso, um desafio e uma resposta.

O provador conhece um valor secreto chamado testemunho.

A declaração pública descreve o que o provador afirma conhecer ou qual cálculo afirma ter concluído corretamente.

Na primeira etapa, o provador gera uma aleatoriedade privada e produz um compromisso.

Na segunda etapa, o verificador gera um desafio aleatório imprevisível.

Na terceira etapa, o provador combina o testemunho, a aleatoriedade privada e o desafio para calcular uma resposta.

O verificador aceita somente quando a resposta é compatível com o compromisso, o desafio e a declaração pública.

O desafio precisa ser imprevisível no momento em que o compromisso é criado.

Caso contrário, um provador desonesto poderia criar um compromisso que funcionasse apenas para um desafio escolhido antecipadamente.

Como funciona a transformação de Fiat–Shamir?

A transformação remove a segunda mensagem do verificador e a substitui por um cálculo de hash criptográfico.

Primeiro, o provador cria o mesmo compromisso que teria usado no protocolo interativo.

Em seguida, aplica uma função hash à declaração pública, ao compromisso, à mensagem, ao identificador do protocolo e a outros dados necessários do transcript.

A saída da função hash é convertida em um desafio pertencente ao conjunto de desafios válidos do protocolo.

O provador calcula a resposta usando esse desafio e o testemunho secreto.

A prova não interativa final normalmente contém o compromisso e a resposta, enquanto o desafio pode ser recalculado pelo verificador.

O verificador reconstrói o transcript, calcula o mesmo desafio de hash e executa a equação de verificação original.

A transformação simplificada pode ser representada assim:

As entradas exatas e as regras de codificação são fundamentais para a segurança.

Exemplo do protocolo de Schnorr

O protocolo de identificação de Schnorr oferece um exemplo claro da transformação de Fiat–Shamir.

Suponha que um grupo cíclico tenha um gerador

e uma ordem .

O provador possui uma chave privada

e uma chave pública .

O provador quer demonstrar que conhece

sem revelá-lo.

No protocolo interativo, o provador escolhe um valor aleatório

e envia o compromisso .

O verificador responde com um desafio aleatório

.

O provador calcula

.

O verificador confere se

.

Uma resposta válida mostra que o provador consegue satisfazer a equação para o desafio imprevisível.

Aplicação de Fiat–Shamir ao protocolo de Schnorr

A versão não interativa substitui o desafio gerado pelo verificador por um hash.

O provador calcula um desafio como

.

Em seguida, calcula

.

A prova ou assinatura contém o compromisso

e a resposta .

O verificador calcula novamente o desafio usando a mesma chave pública, o compromisso, o contexto e a mensagem.

O verificador aceita quando a equação de verificação de Schnorr é satisfeita.

A RFC 8235 especifica uma prova não interativa de conhecimento zero de Schnorr, criada a partir do esquema de identificação de Schnorr de três etapas por meio da transformação de Fiat–Shamir.

Como a transformação cria uma assinatura digital

Uma prova de identificação mostra que o provador conhece um segredo associado a uma identidade pública.

Para criar uma assinatura digital, o desafio também vincula a prova a uma mensagem específica.

Se a mensagem mudar, a saída da função hash também muda e, portanto, o desafio muda.

Normalmente, uma prova criada para uma transação não pode ser reutilizada como assinatura válida de outra transação.

A resposta do signatário demonstra que ele conhece a chave privada e vincula esse conhecimento à mensagem assinada.

Esse padrão de conversão de identificação em assinatura é um dos usos mais importantes da transformação de Fiat–Shamir.

Fiat–Shamir e assinaturas Schnorr do Bitcoin

A BIP 340 do Bitcoin especifica assinaturas Schnorr para a curva elíptica secp256k1.

O desafio da assinatura é derivado de um hash do compromisso do nonce, da chave pública e da mensagem.

Isso segue o padrão de assinatura Schnorr não interativa associado à transformação de Fiat–Shamir.

A BIP 340 também usa hashes marcados para separar seus cálculos de hash de outros usos do protocolo.

O hashing marcado prefixa a entrada com um valor derivado de um rótulo específico do protocolo.

Isso reduz o risco de a mesma função hash e o mesmo formato de entrada serem interpretados como duas operações criptográficas diferentes.

As assinaturas BIP 340 são usadas nas regras de transação Taproot do Bitcoin.

A transformação em si é mais ampla do que o Bitcoin e pode ser usada com muitos sistemas de prova, grupos algébricos e pressupostos criptográficos.

Fiat–Shamir em sistemas de prova de conhecimento zero

Os sistemas modernos de prova de conhecimento zero geralmente começam com um protocolo que é mais fácil de descrever como uma interação entre um provador e um verificador.

O provador envia compromissos polinomiais, raízes de Merkle, elementos de grupo ou outras mensagens.

O verificador responde com elementos aleatórios de um campo ou posições de consulta.

Fiat–Shamir deriva esses desafios do transcript, em vez de exigir um verificador ao vivo.

Isso permite gerar uma prova off-chain e verificá-la posteriormente por um nó blockchain ou contrato inteligente.

A transformação é usada em sistemas que dão suporte a transações privadas, provas de validade, rollups escaláveis, computação verificável e interoperabilidade entre blockchains.

Fiat–Shamir no Halo2

O Halo2 descreve seu protocolo de prova de forma interativa para fins de análise, mas o implementa de forma não interativa por meio da transformação de Fiat–Shamir.

O transcript contém compromissos e outras mensagens do provador.

As saídas de hashes criptográficos são convertidas em desafios do verificador usados para avaliações polinomiais e verificações da prova.

A documentação do protocolo Halo2 explica que um argumento interativo de moeda pública se torna não interativo ao substituir o verificador por uma função hash criptograficamente forte.

O Halo2 também analisa propriedades de segurança que levam em conta a capacidade do provador de construir e revisitar estados do transcript.

Isso mostra que aplicar Fiat–Shamir com segurança exige mais do que substituir um gerador de números aleatórios por uma chamada de hash.

Fiat–Shamir em provas STARK

Os sistemas de prova STARK usam várias rodadas de compromissos e desafios do verificador.

Os desafios podem determinar coeficientes aleatórios, pontos de avaliação de polinômios e consultas de testes de baixo grau.

Um canal Fiat–Shamir deriva essa aleatoriedade não interativa do transcript de prova em evolução.

O provador incorpora os compromissos ao canal antes de solicitar o próximo desafio.

O verificador repete as mesmas operações no transcript e obtém os mesmos desafios.

A documentação do provador STARK descreve um canal Fiat–Shamir usado para gerar aleatoriedade não interativa durante a construção da prova.

Se os compromissos ou as entradas públicas mudarem, os desafios posteriores também devem mudar.

O que é o modelo de oráculo aleatório?

O modelo de oráculo aleatório é um modelo de segurança que trata uma função hash como uma função aleatória pública ideal.

Cada entrada exclusiva recebe uma saída aleatória independente.

O uso repetido da mesma entrada sempre retorna a mesma saída.

Qualquer pessoa pode consultar o oráculo, mas ninguém consegue prever uma nova saída sem fazer a consulta correspondente.

As funções hash reais são algoritmos determinísticos, e não oráculos aleatórios ideais.

Uma prova de segurança de Fiat–Shamir no modelo de oráculo aleatório demonstra segurança sob esse pressuposto idealizado.

Em seguida, os implementadores instanciam o oráculo com uma função hash criptográfica real, considerada suficientemente semelhante ao modelo para o protocolo.

O modelo de oráculo aleatório é útil, mas uma prova nesse modelo não é uma prova incondicional sobre qualquer implementação de hash possível.

Por que o hash precisa incluir o transcript completo?

Cada desafio deve estar vinculado a todas as informações anteriores do protocolo que afetam seu significado.

Isso pode incluir parâmetros públicos, chaves públicas, declarações, compromissos, mensagens, desafios anteriores, identificadores de cadeia e versões do protocolo.

Omitir um valor importante pode permitir que uma prova seja transferida para outro contexto.

Uma prova pode ser válida para duas chaves públicas, dois aplicativos, duas redes blockchain ou duas etapas de protocolo quando deveria ser válida para apenas um deles.

Em uma prova com várias rodadas, cada desafio deve depender do transcript acumulado antes dele.

O provador precisa assumir um compromisso com os dados anteriores antes de conhecer o desafio derivado.

Aplicar hash apenas à mensagem final pode destruir as garantias de ordenação necessárias ao protocolo interativo.

O que é separação de domínio?

A separação de domínio garante que uma operação de hash não seja confundida com outra operação que use a mesma função subjacente.

Um protocolo pode acrescentar um rótulo exclusivo, como seu nome, versão, rede, etapa da prova ou tipo de operação.

O rótulo altera a entrada do hash mesmo quando os demais dados são idênticos.

Sem separação de domínio, um valor criado como desafio em um protocolo pode ser interpretado como nonce, compromisso ou desafio em outro protocolo.

A separação de domínio é especialmente importante em softwares de criptomoedas, nos quais uma mesma função hash pode ser reutilizada para identificadores de transações, assinaturas, árvores de Merkle, derivação de chaves e transcripts de provas.

O hashing marcado específico do protocolo na BIP 340 é um exemplo prático dessa proteção.

Por que a codificação canônica é importante?

O provador e o verificador precisam aplicar hash exatamente à mesma sequência de bytes.

Às vezes, um valor matemático pode ter várias representações válidas em bytes.

Os inteiros podem ser codificados com comprimentos diferentes, ordens de bytes distintas ou zeros à esquerda.

Os pontos de uma curva elíptica podem ter codificações comprimidas, não comprimidas ou alternativas inválidas.

As listas podem se tornar ambíguas quando os comprimentos e limites dos elementos não são codificados com clareza.

A serialização canônica define uma única representação aceita para cada valor válido do transcript.

Prefixos de comprimento, rótulos de tipo, campos de largura fixa e regras estritas de decodificação podem evitar ambiguidades.

Uma implementação deve rejeitar valores não canônicos, em vez de normalizá-los de maneira diferente de outro verificador.

Comprimento do desafio e solidez

O espaço de desafios afeta a probabilidade de um provador desonesto conseguir ter sucesso sem conhecer um testemunho válido.

Um desafio de um bit dá ao provador desonesto uma probabilidade relativamente alta de acertar em uma única rodada.

Repetir o protocolo ou usar um desafio maior reduz esse erro de solidez.

A saída do hash precisa ser convertida em um desafio de tamanho suficiente para o nível de segurança exigido.

Truncar o desafio de forma excessiva pode enfraquecer a prova.

O mapeamento das saídas do hash para um campo ou uma ordem de grupo também precisa evitar viés estatístico inaceitável.

Os protocolos podem usar amostragem por rejeição, redução com largura ampliada ou outro método documentado para derivar os desafios corretamente.

O que é grinding em Fiat–Shamir?

Grinding ocorre quando o provador altera repetidamente a aleatoriedade permitida do compromisso e aplica hash a cada transcript resultante até obter um desafio favorável.

O provador pode fazer essa busca porque o desafio é gerado localmente, e não por um verificador independente ao vivo.

A análise de segurança precisa considerar o número de consultas de hash e o tamanho do espaço de desafios.

Um espaço de desafios suficientemente grande torna o grinding útil computacionalmente inviável sob os pressupostos do protocolo.

Os aplicativos não devem acrescentar valores desnecessários controlados pelo provador ao transcript quando esses valores tornam o grinding mais barato ou criam viés.

Os sistemas de prova que usam Fiat–Shamir precisam analisar esse comportamento, em vez de presumir que o provador fará apenas uma consulta de hash honesta.

Riscos de repetição e vinculação ao contexto

Uma prova não interativa pode ser copiada, pois é um objeto de dados público.

A cópia é inofensiva quando a prova apenas demonstra uma declaração pública atemporal.

Ela se torna perigosa quando o aplicativo trata incorretamente a posse da prova como evidência de uma nova ação ou autorização recente.

O transcript pode incluir um identificador de transação, destinatário, rede, valor de sessão, endereço de contrato, prazo de validade ou nonce específico do aplicativo.

Isso vincula a prova ao contexto pretendido.

A inclusão de um valor de contexto não ajuda se o verificador não conferir esse valor em relação à solicitação atual.

Os requisitos de validade temporal pertencem ao protocolo completo do aplicativo, e não apenas à equação da prova.

Fiat–Shamir garante automaticamente conhecimento zero?

Não. A transformação não torna automaticamente qualquer protocolo uma prova de conhecimento zero.

O protocolo interativo original precisa ter propriedades adequadas de conhecimento zero ou de conhecimento zero para verificador honesto.

O protocolo transformado também precisa ser analisado no modelo de segurança escolhido.

Os compromissos podem exigir aleatoriedade de ocultação para impedir a revelação do testemunho.

Os desafios do transcript podem exigir restrições para evitar valores especiais que revelem informações privadas.

Uma prova pode ser não interativa sem ser de conhecimento zero.

Não interativa significa apenas que o provador consegue produzir a prova sem receber uma mensagem de um verificador ao vivo.

Fiat–Shamir garante automaticamente solidez?

Não. Transformar um protocolo com segurança não prova que todo protocolo semelhante seja seguro.

O protocolo interativo original precisa ter as propriedades necessárias de solidez, solidez especial ou prova de conhecimento.

As entradas do hash e o mapeamento dos desafios precisam preservar a ordem pretendida de compromisso antes do desafio.

Alguns protocolos exigem pressupostos mais fortes ou provas especializadas após a transformação.

Uma construção pode ser segura no modelo clássico de oráculo aleatório e, ainda assim, não ter uma prova adequada contra adversários quânticos.

Os desenvolvedores devem usar uma construção revisada e respaldada por uma prova de segurança, em vez de aplicar Fiat–Shamir informalmente a um protocolo novo.

Fiat–Shamir e criptografia pós-quântica

O padrão de projeto Fiat–Shamir também aparece em pesquisas sobre assinaturas pós-quânticas.

Esquemas de identificação baseados em reticulados, códigos e computação multipartidária podem usar desafios derivados de hash para criar assinaturas.

Algumas assinaturas baseadas em reticulados usam uma variação conhecida como Fiat–Shamir com abortos.

O signatário pode reiniciar parte do processo de assinatura quando uma resposta intermediária puder revelar informações ou ficar fora de uma distribuição aceita.

A NIST FIPS 204 padroniza a ML-DSA, um algoritmo de assinatura digital baseado em reticulados modulares, derivado do projeto Dilithium.

A existência de padrões de assinatura pós-quântica não significa que toda prova clássica de Fiat–Shamir continue segura contra um computador quântico.

Fiat–Shamir no modelo de oráculo aleatório quântico

Um adversário quântico pode consultar um oráculo aleatório modelado usando uma superposição de várias entradas.

Isso é diferente de um adversário clássico, que envia uma consulta convencional por vez.

As provas no modelo clássico de oráculo aleatório não continuam automaticamente válidas no modelo de oráculo aleatório quântico, normalmente abreviado como QROM.

Pesquisadores em criptografia desenvolveram técnicas de prova adicionais e condições de protocolo para analisar construções Fiat–Shamir contra atacantes quânticos.

Portanto, uma alegação de segurança pós-quântica deve ser respaldada por uma análise que abranja o QROM ou outro modelo de segurança quântica apropriado.

Substituir um grupo clássico por um problema de reticulados não é suficiente por si só.

Fiat–Shamir e assinaturas threshold

As assinaturas threshold dividem a autoridade de assinatura entre vários participantes.

Um número mínimo de participantes coopera para criar uma única assinatura válida, sem reconstruir a chave privada completa em um só lugar.

Os protocolos threshold de Schnorr precisam coordenar com cuidado os compromissos de nonce e os cálculos dos desafios.

O desafio precisa vincular a chave pública combinada, o compromisso combinado de nonce, a mensagem, o contexto dos participantes e as regras do protocolo.

Uma construção incorreta do transcript pode permitir manipulação de nonce, comportamento de chave maliciosa ou ataques entre sessões.

A RFC 9591 especifica o protocolo de assinatura threshold Schnorr FROST e suas operações de conjunto de cifras baseadas em hash.

Vantagens da transformação de Fiat–Shamir

A transformação elimina a interação com um verificador ao vivo nos sistemas de prova compatíveis.

Uma prova pode ser criada uma vez e verificada de forma independente por vários nós blockchain.

Ela reduz as rodadas de comunicação e simplifica a verificação assíncrona.

As provas podem ser incluídas em transações, blocos, contratos inteligentes e armazenamento distribuído.

A mesma prova pode ser verificada sem fornecer ao verificador aleatoriedade privada nem manter uma sessão interativa.

A transformação também oferece um caminho prático para converter protocolos de identificação em esquemas de assinatura digital.

Essas propriedades são valiosas para redes descentralizadas nas quais os participantes talvez nunca se comuniquem diretamente.

Limitações da transformação de Fiat–Shamir

Normalmente, a transformação depende do modelo de oráculo aleatório.

Ela não transforma com segurança qualquer prova interativa possível.

Omissões no transcript e inconsistências de codificação podem criar vulnerabilidades graves.

Como o provador pode avaliar o hash repetidamente, o comportamento de grinding precisa ser incluído na análise de segurança.

As provas não interativas podem ser repetidas, a menos que o aplicativo as vincule ao contexto apropriado.

A segurança quântica exige uma análise separada.

A transformação não protege uma implementação contra vazamento por canal lateral, aleatoriedade fraca, corrupção de memória ou roubo de chaves privadas.

A geração de provas também pode continuar exigindo muitos recursos computacionais mesmo depois da eliminação da interação.

Transformação de Fiat–Shamir vs. prova interativa

Uma prova interativa exige a troca de mensagens entre um provador e um verificador.

Durante a interação, o verificador fornece novos desafios aleatórios.

Uma prova Fiat–Shamir deriva esses desafios de um hash do transcript.

A prova não interativa é mais fácil de distribuir e verificar de forma assíncrona.

O protocolo interativo pode se apoiar em aleatoriedade genuína do verificador, enquanto o protocolo transformado depende do comportamento da função hash semelhante ao de um oráculo aleatório.

Transformação de Fiat–Shamir vs. prova não interativa de conhecimento zero

A transformação de Fiat–Shamir é um dos métodos para construir uma prova não interativa.

Uma prova não interativa de conhecimento zero, ou NIZK, é uma categoria mais ampla de provas que não exige interação com um verificador ao vivo e não revela informações protegidas do testemunho.

Algumas provas NIZK usam Fiat–Shamir, enquanto outras usam uma string de referência comum, uma configuração confiável, uma configuração transparente ou técnicas criptográficas diferentes.

Chamar uma prova de não interativa não identifica o método usado para criá-la.

Transformação de Fiat–Shamir vs. assinatura digital

Uma assinatura digital autentica uma mensagem usando uma chave privada e uma chave pública de verificação.

A transformação de Fiat–Shamir é uma técnica de construção que pode converter certos protocolos de identificação em esquemas de assinatura.

Nem toda assinatura digital é criada por meio de Fiat–Shamir.

Nem toda prova Fiat–Shamir se destina a funcionar como assinatura digital.

Uma prova pode demonstrar o conhecimento de um testemunho ou a correção de um cálculo sem autenticar uma pessoa ou carteira.

Transformação de Fiat–Shamir vs. hash-to-curve

Hash-to-curve converte dados de entrada arbitrários em um ponto válido de uma curva elíptica.

Fiat–Shamir converte dados do transcript em desafios para o verificador.

Um sistema de prova pode usar as duas operações.

O desafio pode ser um escalar, enquanto outro componente do protocolo pode exigir um ponto da curva derivado de hash.

Os dois processos precisam de regras próprias de separação de domínio e codificação.

Transformação de Fiat–Shamir vs. commit-reveal

Um protocolo commit-reveal exige que um participante publique um compromisso e revele o valor oculto posteriormente.

Ele pode ser usado para reduzir o conhecimento antecipado ou a manipulação da aleatoriedade compartilhada.

Fiat–Shamir não aguarda uma revelação pública de aleatoriedade posterior.

Ele cria um desafio determinístico a partir do transcript existente.

Commit-reveal e Fiat–Shamir resolvem problemas de coordenação diferentes, embora ambos usem compromissos criptográficos e hashes.

Boas práticas de implementação

Os desenvolvedores devem usar um sistema de prova com uma análise de segurança de Fiat–Shamir publicada e revisada.

O transcript deve incluir todos os valores públicos que definem a declaração e o contexto.

Cada protocolo e etapa da prova deve ter uma separação de domínio exclusiva.

Todos os valores devem usar serialização canônica com limites explícitos de tipo e comprimento.

Os compromissos precisam ser incorporados antes da geração dos desafios que dependem deles.

As saídas dos desafios devem ser mapeadas para campos ou grupos usando o método sem viés documentado.

Pontos inválidos, escalares não canônicos, valores de campo proibidos e transcripts malformados devem ser rejeitados.

A aleatoriedade do provador e os nonces de assinatura precisam ser gerados com segurança ou derivados por um método determinístico aprovado.

As implementações devem verificar se a alteração de qualquer declaração, compromisso, mensagem, identificador de rede ou versão do protocolo modifica o desafio derivado.

Os vetores de teste devem abranger a ordem do transcript, a codificação, as tags de domínio, valores vazios, valores-limite e provas malformadas.

Erros comuns de implementação de Fiat–Shamir

Um erro é aplicar hash ao compromisso sem incluir a declaração pública.

Outro erro é omitir a mensagem quando a prova se destina a funcionar como assinatura.

Uma concatenação ambígua pode permitir que dois transcripts diferentes produzam a mesma sequência de bytes.

Usar o mesmo rótulo de domínio em protocolos não relacionados pode causar confusão entre protocolos.

Gerar um desafio posterior antes de incorporar todas as mensagens anteriores do provador quebra a ordem do transcript.

Reduzir diretamente um hash curto para um campo grande pode gerar entropia fraca no desafio.

Aceitar pontos de curva ou escalares não canônicos pode fazer com que diferentes implementações apliquem hash a representações distintas.

Reutilizar a aleatoriedade do provador pode revelar um testemunho secreto em protocolos semelhantes ao de Schnorr.

Presumir que uma prova clássica oferece automaticamente segurança pós-quântica é outro erro grave.

Por que a transformação de Fiat–Shamir é importante para as criptomoedas

As redes de criptomoedas precisam de provas que possam ser verificadas de forma independente por participantes do mundo todo.

Uma transação blockchain não pode depender de uma conversa privada com cada nó futuro que poderá verificá-la.

Fiat–Shamir permite transformar raciocínios criptográficos interativos em um objeto de prova estático.

Isso dá suporte a assinaturas compactas, sistemas de privacidade, rollups de conhecimento zero, execução verificável de contratos inteligentes, carteiras threshold e outros aplicativos blockchain.

A transformação também ilustra um princípio importante do projeto de criptomoedas.

Uma função hash pode fazer mais do que criar identificadores de transações: ela pode gerar desafios aparentemente imprevisíveis que vinculam todo o transcript de um protocolo.

Esse recurso depende de uma construção cuidadosa, serialização precisa, separação de domínio robusta e uma prova de segurança apropriada.

Perguntas frequentes

O que faz a transformação de Fiat–Shamir?

Ela substitui os desafios aleatórios do verificador em determinados protocolos interativos por desafios derivados de um hash criptográfico do transcript.

Por que Fiat–Shamir é útil para as criptomoedas?

Ela permite que provas e assinaturas sejam verificadas posteriormente por nós blockchain sem exigir uma conversa ao vivo com o provador.

Quem criou a transformação de Fiat–Shamir?

Amos Fiat e Adi Shamir apresentaram a técnica em um trabalho publicado em 1986.

A transformação de Fiat–Shamir é igual a uma função hash?

Não. É uma transformação de protocolo que usa uma função hash para gerar desafios do verificador.

O que é uma prova interativa?

É um protocolo em que um provador e um verificador trocam compromissos, desafios e respostas.

O que é um protocolo de moeda pública?

É um protocolo interativo em que as mensagens do verificador consistem em desafios aleatórios visíveis publicamente.

O que é um transcript Fiat–Shamir?

É a coleção ordenada de parâmetros públicos, declarações, compromissos, desafios, respostas, mensagens e contexto usada pela prova.

O que é o modelo de oráculo aleatório?

É um modelo de segurança idealizado que trata uma função hash como uma função aleatória pública com saídas consistentes.

Uma função hash real é um oráculo aleatório?

Não. Uma função hash real é determinística, embora os protocolos possam analisá-la como se se comportasse como um oráculo aleatório ideal.

Fiat–Shamir cria conhecimento zero automaticamente?

Não. O protocolo original e a construção transformada precisam satisfazer as condições exigidas de conhecimento zero.

Fiat–Shamir cria uma assinatura digital?

Ela pode converter determinados protocolos de identificação em assinaturas quando a mensagem é incluída no hash do desafio.

O Bitcoin usa o padrão Fiat–Shamir?

As assinaturas Schnorr da BIP 340 do Bitcoin usam um desafio derivado de hash que vincula o compromisso do nonce, a chave pública e a mensagem.

Fiat–Shamir é usada em rollups de conhecimento zero?

Muitos sistemas de prova de rollup usam desafios de transcript no estilo Fiat–Shamir para tornar não interativos protocolos de prova interativos.

Fiat–Shamir é usada em STARKs?

Sim. Provadores e verificadores STARK podem usar um canal Fiat–Shamir para derivar desafios não interativos dos compromissos.

Fiat–Shamir é usada no Halo2?

Sim. O Halo2 implementa sua descrição de prova interativa como um argumento não interativo por meio de Fiat–Shamir.

O que é separação de domínio?

A separação de domínio acrescenta rótulos específicos do protocolo às entradas do hash para evitar que saídas de diferentes operações criptográficas sejam confundidas.

Por que a chave pública precisa ser incluída no hash?

Incluir a chave pública no hash vincula a prova ou assinatura à identidade pretendida e pode evitar ataques de substituição de chave ou entre chaves.

Por que a mensagem precisa ser incluída no hash?

A inclusão da mensagem garante que uma assinatura criada para uma mensagem não possa ser reutilizada em outra.

O que é challenge grinding?

Challenge grinding é a geração repetida de compromissos até que o hash do transcript produza um desafio favorável ao provador.

As provas Fiat–Shamir podem ser repetidas?

Uma prova pública pode ser copiada; portanto, os protocolos que exigem validade temporal precisam incluir e verificar um contexto adequado de sessão ou transação.

O que é serialização canônica?

Serialização canônica é a atribuição de uma única representação em bytes aceita para cada valor do transcript.

Por que a ordem do transcript é importante?

Cada desafio precisa depender de todas as mensagens anteriores para impedir que o provador altere um compromisso depois de conhecer o desafio.

Fiat–Shamir pode ser usada com curvas elípticas?

Sim. Provas e assinaturas Schnorr costumam aplicá-la em grupos de curvas elípticas.

Fiat–Shamir pode ser usada em criptografia pós-quântica?

Sim. Construções relacionadas aparecem em assinaturas pós-quânticas, mas sua segurança exige uma análise quântica apropriada.

O que é o modelo de oráculo aleatório quântico?

É um modelo em que um adversário quântico pode consultar o oráculo aleatório usando uma superposição quântica.

Uma prova clássica de segurança continua válida contra atacantes quânticos?

Não automaticamente, pois a prova pode não levar em conta consultas quânticas ao oráculo ou os limites de extração quântica.

O que é Fiat–Shamir com abortos?

É uma variação em que o signatário pode reiniciar o processo quando uma resposta não atende às condições exigidas de distribuição ou tamanho.

Fiat–Shamir exige uma configuração confiável?

Não. A transformação em si não exige uma configuração confiável, embora o sistema de prova subjacente possa ter requisitos de configuração próprios.

Contratos inteligentes podem verificar provas Fiat–Shamir?

Sim, desde que o contrato consiga reproduzir o hash do transcript e verificar as equações da prova com eficiência.

Qual é o maior risco de implementação?

Entre os principais riscos estão a vinculação incompleta ao transcript, codificação ambígua, separação de domínio deficiente, geração fraca de nonce e pressupostos de segurança sem respaldo.

Conclusão

A transformação de Fiat–Shamir converte protocolos interativos de moeda pública compatíveis em provas não interativas ou assinaturas digitais.

Ela substitui o desafio imprevisível enviado por um verificador ao vivo por um desafio derivado de um hash criptográfico do transcript da prova.

Isso permite criar uma prova uma única vez e verificá-la de forma independente por nós blockchain, carteiras, contratos inteligentes e outros aplicativos cripto.

A transformação dá suporte a assinaturas Schnorr, sistemas de prova de conhecimento zero, STARKs, protocolos no estilo Halo2, assinaturas threshold e pesquisas sobre assinaturas pós-quânticas.

Sua segurança depende das propriedades do protocolo interativo original e dos pressupostos usados para modelar a função hash.

As implementações corretas precisam vincular a declaração completa, o compromisso, a mensagem, os parâmetros públicos, o contexto e a versão do protocolo em um transcript canônico.

Também precisam usar separação de domínio robusta, desafios de tamanho adequado, geração segura de nonce e regras de mapeamento de desafios cuidadosamente revisadas.

A transformação de Fiat–Shamir não é uma atualização automática de segurança para qualquer protocolo de prova.

É uma construção poderosa cuja segurança depende de um projeto rigoroso do protocolo, disciplina de implementação e análise de segurança para atacantes clássicos e quânticos.