mthiim/dilithium-java - Implementación en Java de un algoritmo criptográfico resistente a la computación cuántica

 (github.com/mthiim)
1 puntos por GN⁺ 2023-10-24 | 1 comentarios | Compartir por WhatsApp
  • Implementación de Dilithium 3.1 en Java que envuelve las operaciones primitivas como un proveedor JCE, lo que permite usar generación de claves, firma y verificación mediante las interfaces criptográficas estandarizadas de Java
  • En el contexto de que RSA y ECC son vulnerables a ataques de computadoras cuánticas que usan el algoritmo de Shor, esta implementación sirve para experimentar y aprender con Dilithium, uno de los esquemas de firma digital poscuántica seleccionados por NIST
  • Pertenece al conjunto de algoritmos CRYSTALS; implementa Dilithium, basado en retículos algebraicos, a partir de la implementación de referencia en C y la documentación, y SHAKE128/256 usado internamente se proporciona mediante la dependencia Bouncy Castle
  • Soporta los tres niveles de seguridad documentados 2, 3 y 5; los tres niveles usan un esquema de firma determinista y pasan las pruebas KAT del paquete oficial
  • El flujo de uso con JCE consiste en registrar DilithiumProvider y luego usar KeyPairGenerator.getInstance("Dilithium"), Signature.getInstance("Dilithium") y KeyFactory.getInstance("Dilithium") para generación de claves, firma, verificación y reconstrucción de claves
    • El nivel de seguridad se especifica con DilithiumParameterSpec.LEVEL2, LEVEL3, LEVEL5 o getSpecForSecurityLevel()
    • Las claves públicas y privadas obtienen su representación en bytes con .getEncoded(), y se serializan y deserializan en un formato compatible con la implementación de referencia
    • La representación en bytes no codifica el parameter spec, por lo que al reconstruir una clave se debe indicar el parameter spec en DilithiumPublicKeySpec o DilithiumPrivateKeySpec
  • Proporciona la utilidad KAT.java, que lee archivos de solicitud de known-answer test del paquete oficial de Dilithium y genera archivos de respuesta; los argumentos de ejecución tienen el formato <input-request-file> <output-response-file> <level>
  • La implementación actual refleja Dilithium 3.1 y es distinta de FIPS 204 o de la versión ML-DSA, que están en proceso de estandarización
  • Es una implementación escrita en unos días “for fun”; no es production-grade code, no cuenta con revisión de vulnerabilidades por terceros y no se ofrece ningún tipo de garantía ni soporte
  • Se ofrece bajo la licencia Apache 2.0

Lecturas relacionadas

1 comentarios

 
GN⁺ 2023-10-24
Comentarios de Hacker News

  • Me alegra ver que mi proyecto recibe atención en Hacker News. Es una implementación puramente de juguete inspirada en el paper y la implementación de referencia.
    Pasa todos los casos de prueba provistos, pero la hice principalmente por diversión y para ver si funcionaba de forma natural con la interfaz estándar JCE. Si tienen preguntas o feedback, pregunten con confianza.

    • Me da curiosidad saber qué haría falta para usarlo en servicios reales. También quisiera saber si existe alguna biblioteca Java para criptografía poscuántica que esté lo bastante lista para entornos de producción.

  • La mayor parte de la parte central de esta implementación de juguete de Dilithium puede verse aquí: https://github.com/mthiim/dilithium-java/blob/main/src/main/...

  • Me pregunto si es buena idea usar algoritmos criptográficos poscuánticos encima de algoritmos más establecidos y ampliamente usados, como RSA/ECDSA.
    La criptografía poscuántica todavía está demasiado en la frontera como para que sea cómoda de usar.

    • De hecho, eso parece ser justamente lo que está haciendo la comunidad.
      Cloudflare activó recientemente la criptografía poscuántica y usa X25519+Kyber [0]. La criptografía poscuántica de Signal usa el mismo enfoque [1].
      Parece que esta tendencia surgió a partir de un caso de hace unos años en el que cierto algoritmo poscuántico fue roto en computadoras clásicas [2].
      Ahora el atacante tiene que romper tanto el algoritmo clásico como el poscuá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...
    • Hasta donde sé, el algoritmo de Shor todavía es poco realista. Para ejecutarlo en un tiempo razonable se necesitarían muchísimos más qubits de los que hoy son posibles.
      Harían falta millones de qubits, mientras que los dispositivos de punta hoy tienen, como mucho, unos cientos. Durante los próximos años, quizá incluso décadas, no creo que nos preocupemos demasiado por algoritmos poscuánticos en código de producción.
    • El estándar actualmente aceptado en general, aunque no por todos, es el cifrado híbrido. Es distinto de “híbrido” en el sentido de KEM/DEM, pero normalmente se usa junto con un criptosistema KEM/DEM híbrido.
      Este enfoque garantiza que, para acceder al texto plano, haya que romper tanto el algoritmo clásico como el poscuántico. Si basta con simplemente envolver el cifrado o si hay que usar un combinador KEM híbrido, como en el ejemplo de Campagna y Petcher, es una cuestión más sutil y requiere un juicio más refinado que el mío.
    • Si las computadoras cuánticas se vuelven más prácticas durante nuestra vida, los secretos actuales no deberían quedar expuestos a ese análisis en el futuro. Escalar computadoras cuánticas no es tan simple como el paso de los tubos de vacío y transistores a los circuitos integrados, y las estimaciones de dificultad de los expertos van desde “muy, muy, muy difícil” hasta “seguirá siendo físicamente imposible”.
      En cualquier caso, es más probable que romper por fuerza bruta una clave de cifrado con estándares modernos, así que hay motivos para priorizar hoy la seguridad poscuántica.
      Dicho eso, también es cierto que hay que tener cuidado. Si los algoritmos PQ tienen canales laterales o vulnerabilidades de implementación, las cosas podrían empeorar mucho. En el peor caso, imaginen que una implementación PQ tuviera una vulnerabilidad de ejecución remota de código. Por eso conviene avanzar con prudencia y revisar el código con rigor.
    • No hay un riesgo práctico en usar criptografía poscuántica junto con criptografía existente, siempre que la combinación esté diseñada para que, si una de las dos se rompe, no colapse todo el conjunto.
      En el intercambio de claves es bastante sencillo; según el método, se pueden hacer XOR de las salidas o concatenarlas.

  • El README menciona una dependencia de Bouncy Castle, y BC ya incluye varios esquemas de firma PQC basados en Java. Pueden consultar https://doc.primekey.com/bouncycastle/interoperability#Inter... y https://github.com/bcgit/bc-java.

  • Hace unos días Daniel Bernstein advirtió que la NSA está intentando difundir implementaciones defectuosas de criptografía poscuántica. No encuentro el enlace.

  • Aquí hay una implementación/port en Java de un solo archivo de otro esquema de firma poscuántico, sphincs+.
    https://github.com/Peergos/sphincsplus

  • “Hace tiempo que se sabe que los algoritmos criptográficos RSA y ECC son vulnerables a ataques de computadoras cuánticas que usan el algoritmo de Shor”.
    Me pregunto qué impacto tendría esto en Bitcoin si fuera cierto y realmente apareciera una computadora cuántica de esa escala.

    • Se migrará antes de que se vuelva un problema. Incluso si ocurriera de verdad, bastaría con hacer un fork incorporando criptografía poscuántica en el primer punto de ataque conocido.

  • “Esta es una implementación escrita por diversión en unos pocos días. No está pensada como código de nivel producción. No se ofrece ningún tipo de garantía ni soporte. Sin embargo, puede ser útil para explorar y experimentar con algoritmos poscuánticos. Úsela bajo su propia responsabilidad. Si estas condiciones no le parecen aceptables, no debería usar este software”