mthiim/dilithium-java - implementação em Java de um algoritmo criptográfico resistente à computação quântica

 (github.com/mthiim)
1 pontos por GN⁺ 2023-10-24 | 1 comentários | Compartilhar no WhatsApp
  • Implementação do Dilithium 3.1 em Java, com as operações primitivas encapsuladas em um provedor JCE, permitindo usar geração de chaves, assinatura e verificação por meio das interfaces criptográficas padronizadas do Java
  • Diante do fato de que RSA e ECC são vulneráveis a ataques de computadores quânticos usando o algoritmo de Shor, este é um projeto de implementação para experimentar e aprender sobre Dilithium, um dos esquemas de assinatura digital pós-quântica selecionados pelo NIST
  • Faz parte da família de algoritmos CRYSTALS e implementa o Dilithium, baseado em reticulados algébricos, com base na implementação de referência em C e na documentação; o SHAKE128/256 usado internamente é fornecido pela dependência Bouncy Castle
  • Suporta todos os níveis de segurança documentados 2, 3 e 5, usa deterministic signature scheme nos três níveis e passa nos testes KAT do pacote oficial
  • O fluxo de uso com JCE consiste em registrar DilithiumProvider e depois usar KeyPairGenerator.getInstance("Dilithium"), Signature.getInstance("Dilithium") e KeyFactory.getInstance("Dilithium") para geração de chaves, assinatura, verificação e restauração de chaves
    • O nível de segurança é definido com DilithiumParameterSpec.LEVEL2, LEVEL3, LEVEL5 ou getSpecForSecurityLevel()
    • A chave pública e a chave privada obtêm sua representação em bytes com .getEncoded() e são serializadas/desserializadas em um formato compatível com a implementação de referência
    • A representação em bytes não codifica o parameter spec, portanto, ao restaurar a chave é necessário especificar o parameter spec em DilithiumPublicKeySpec ou DilithiumPrivateKeySpec
  • Fornece o utilitário KAT.java, que lê o arquivo de requisição de known-answer test do pacote oficial do Dilithium e gera o arquivo de resposta; os argumentos de execução seguem o formato <input-request-file> <output-response-file> <level>
  • A implementação atual reflete o Dilithium 3.1 e difere das versões FIPS 204 ou ML-DSA, que ainda estão em processo de padronização
  • É uma implementação feita “for fun” ao longo de alguns dias, não é código de nível production-grade, não passou por revisão de vulnerabilidades por terceiros e não oferece qualquer garantia ou suporte
  • Disponível sob a licença Apache 2.0

Leituras relacionadas

1 comentários

 
GN⁺ 2023-10-24
Comentários do Hacker News

  • Fico feliz em ver meu projeto recebendo atenção no Hacker News. Esta é uma implementação puramente de brinquedo, inspirada no artigo e na implementação de referência.
    Ela passa em todos os casos de teste fornecidos, mas foi feita principalmente por diversão e para ver se funcionava de forma natural com a interface padrão JCE. Se tiverem perguntas ou feedback, fiquem à vontade para perguntar.

    • Fico curioso sobre o que seria necessário para usá-la em um serviço real. Também gostaria de saber se há alguma biblioteca Java para criptografia pós-quântica pronta o suficiente para uso em produção.

  • A maior parte das partes centrais desta implementação de brinquedo do Dilithium pode ser vista aqui: https://github.com/mthiim/dilithium-java/blob/main/src/main/...

  • Fico pensando se é uma boa ideia usar algoritmos de criptografia pós-quântica sobre algoritmos mais estabelecidos e amplamente usados, como RSA/ECDSA.
    A criptografia pós-quântica ainda é avançada demais para ser confortável de usar.

    • Na prática, parece ser exatamente isso que a comunidade está fazendo.
      A Cloudflare ativou recentemente criptografia pós-quântica e usa X25519+Kyber [0]. A criptografia pós-quântica do Signal também usa a mesma abordagem [1].
      Parece que essa tendência surgiu depois de um algoritmo pós-quântico ter sido quebrado em computadores clássicos alguns anos atrás [2].
      Agora o atacante precisa quebrar tanto o algoritmo clássico quanto o algoritmo pós-quântico.
      [0] https://blog.cloudflare.com/post-quantum-to-origins/
      [1] https://signal.org/blog/pqxdh/
      [2] https://www.quantamagazine.org/post-quantum-cryptography-sch...
    • Até onde sei, o algoritmo de Shor ainda é pouco realista. Para executá-lo em um tempo razoável, seriam necessários muito mais qubits do que os disponíveis atualmente.
      Seriam necessários milhões de qubits, enquanto os dispositivos de ponta hoje chegam, no máximo, a algumas centenas. Acho que, nos próximos anos, talvez nas próximas décadas, não vamos nos preocupar muito com algoritmos pós-quânticos em código de produção.
    • O padrão hoje amplamente aceito, embora não unanimemente, é a criptografia híbrida. É diferente do “híbrido” em KEM/DEM, mas normalmente acaba sendo usado junto com um criptossistema KEM/DEM híbrido.
      Essa abordagem garante que, para acessar o texto claro, seja necessário quebrar tanto o algoritmo clássico quanto o pós-quântico. Se a criptografia é simplesmente encapsulada ou se se usa um combinador KEM híbrido, como no exemplo de Campagna e Petcher, é uma questão mais sutil e exige um julgamento mais refinado do que o meu nível permite.
    • Se computadores quânticos se tornarem mais práticos durante nossa vida, os segredos de hoje não devem ficar expostos a esse tipo de análise no futuro. Escalar computadores quânticos não é tão simples quanto a evolução de válvulas e transistores para circuitos integrados, mas as estimativas dos especialistas sobre a dificuldade variam de “muito, muito, muito difícil” a “continuará sendo fisicamente impossível”.
      De qualquer forma, é mais provável do que quebrar chaves criptográficas dos padrões modernos por força bruta, então há motivo para priorizar hoje a segurança pós-quântica.
      Ainda assim, também é verdade que é preciso ter cuidado. Se algoritmos PQ tiverem canais laterais ou vulnerabilidades de implementação, isso pode acabar sendo muito pior. No pior caso, imagine uma implementação PQ com uma vulnerabilidade de execução remota de código. Por isso, é melhor avançar com cautela e revisar o código rigorosamente.
    • Não há risco prático em usar criptografia pós-quântica junto com criptografia existente, desde que a combinação seja feita de modo que a quebra de uma delas não derrube o conjunto inteiro.
      Em troca de chaves, isso é relativamente fácil; dependendo do método, basta aplicar XOR nas saídas ou concatená-las.

  • O README menciona uma dependência do Bouncy Castle, mas o BC já inclui várias assinaturas PQC baseadas em Java. Vale conferir https://doc.primekey.com/bouncycastle/interoperability#Inter... e https://github.com/bcgit/bc-java.

  • Há alguns dias, Daniel Bernstein alertou que a NSA estaria tentando disseminar implementações defeituosas de criptografia pós-quântica. Não consegui encontrar o link.

  • Aqui há uma implementação/port em Java em arquivo único de sphincs+, outro esquema de assinatura pós-quântica.
    https://github.com/Peergos/sphincsplus

  • “Há muito tempo se sabe que os algoritmos criptográficos RSA e ECC são vulneráveis a ataques de computadores quânticos usando o algoritmo de Shor.”
    Se isso for verdade e um computador quântico nessa escala realmente surgir, fico curioso sobre qual seria o impacto no Bitcoin.

    • Ele será migrado antes de virar um problema. Mesmo que aconteça de fato, bastaria fazer um fork adicionando criptografia pós-quântica no primeiro ponto de ataque conhecido.

  • “Esta é uma implementação escrita por diversão em alguns dias. Não se destina a ser código de nível de produção. Nenhum tipo de garantia ou suporte é oferecido. Ainda assim, pode ser útil para explorar e experimentar algoritmos pós-quânticos. Use por sua conta e risco. Se você não concorda com essas condições, não deve usar este software.”