Parabéns @paulangusbark! Por favor, vocês dois, compartilhem esses contratos! Seria bom padronizar, no longo prazo, esses contratos de verificação da mesma forma que a comunidade usa trechos de contrato OpenZeppelin um tanto padronizados para muitas tarefas padrão. Presumivelmente, a verificação da assinatura PQ será tão padrão quanto uma interface ERC20.



1 Curtir

Parabéns,

É ótimo ter outras implementações (visando um nível de segurança diferente).

Estamos muito interessados ​​nos contratos também (principalmente no que diz respeito às otimizações das principais operações da NTT).

Pode ter passado despercebido, falcon512 e Dilithium estão disponíveis aqui há alguns meses.
A verificação FALCON toma como entrada uma representação NTT pré-computada da chave pública conforme mencionado acima. As chaves FALCON são compactadas em uint256, as chaves de dilithium são armazenadas em um contrato externo.

Os NIST KATS foram aprovados com sucesso, proporcionando confiança na parte central do algoritmo.

Tanto para a versão baseada em keccak256 quanto para versões totalmente compatíveis com nist são fornecidas, juntamente com assinantes (e também um aplicativo de assinante de hardware para Dilithium44). O nível de segurança de 128 bits é escolhido, pois é o alvo comum para Ethereum.

O custo do gás para FALCON512 usando keccak256 é de 2M, 6,6M para Dilithium.

Isso pode ser usado para experimentos a partir de hoje, até que as pré-compilações sejam adotadas.

O EIP-8052 (DRAFT) diverge da proposta anterior por

  • dividindo os cálculos do FALCON em duas partes, permitindo que uma parte mais amigável do zk seja adotada para a parte hash2Point da assinatura, tendo em mente o final do jogo ZK.
  • tome como entrada a representação NTT do PK

Esta separação não é possível para DILITHIUM, então o EIP-8051 segue o padrão.

Criei um canal discord com instruções em discord.gg/PUFcQezy

A assinatura é o salt seguido pela assinatura codificada como bytes mod q (não usei o codificador/decodificador da implementação do falcon, exceto para carregar a chave pública); então 2.068 bytes (sem cabeçalho).

Um domínio é definido na criação da carteira e é imutável; o valor é usado na função de hash da mensagem. É certo que pedi ao ChatGPT que me escrevesse uma função usando apenas a entrada de 32 bytes e nunca consegui fazer nada melhor; Suspeito que o que tenho é vagamente baseado no seu código, exceto que adicionei um valor de domínio. Também calculo os valores dos pontos à medida que itero pela última transformação iNTT para reduzir o número de loops.

Para economizar combustível, calculo metade da norma com a assinatura enviada, depois converto essa cota de memória para a outra metade da assinatura e calculo a segunda metade da norma. Também usei o recurso desmarcado durante as conversões NTT.

Vou publicá-lo em breve. Meu repositório tem outros contratos que não estou pronto para compartilhar, mas vou apenas eliminar as partes relevantes em um repositório diferente e torná-lo público.

Se você estiver em Londres, estarei amanhã no evento Ethereum London no Encode Club.

Obrigado pela análise detalhada e por configurar o canal Discord.

O layout da assinatura (salt || coeffs mod q, 2068 bytes) é uma abordagem limpa – evitar a compactação do cabeçalho Falcon torna o caminho de verificação muito mais simples para uso na cadeia. A computação mesclada de iNTT + norma parcial é exatamente o tipo de otimização que importa em escala.

Estou trabalhando em uma infraestrutura de verificação semelhante, mas do lado ML-DSA-65 (FIPS 204). Meu foco tem sido na prova de controle pós-quântica para recuperação de validadores e aleatoriedade verificável para sequenciadores L2. A construção da mensagem separada por domínio que você descreveu se alinha estreitamente com o que tenho usado (índice do validador + credenciais + hash da chave PQ + domínio), então estou muito interessado em comparar como nossos padrões de hashing e proteção de reprodução combinam.

Depois de publicar o repositório extraído, ficarei feliz em:

contribuir com vetores de teste ML-DSA-65 em um formato compatível

executar comparações de gás lado a lado (Falcon-1024 vs ML-DSA-65)

ajudar a verificar a integridade dos padrões de separação de domínio para reutilização entre contratos

Não estou em Londres para o evento Encode, mas estou muito interessado em colaborar remotamente. Avise-me quando o repositório for público e começarei a experimentar.

Fontesethresear

By victor

Deixe um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *