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.
Fontesethresear
