mthiim/dilithium-java - 자바를 이용한 양자 컴퓨팅 저항성 암호 알고리듬 구현

 (github.com/mthiim)
1P by GN⁺ | ★ favorite | 댓글 1개
  • Dilithium 3.1을 Java로 구현하고 원시 연산을 JCE provider로 감싼 구현체로, 표준화된 Java 암호 인터페이스를 통해 키 생성·서명·검증을 사용할 수 있음
  • RSA와 ECC가 Shor's algorithm을 사용하는 양자 컴퓨터 공격에 취약하다는 배경에서, NIST가 선정한 포스트 양자 디지털 서명 방식 중 하나인 Dilithium을 실험하고 학습하기 위한 구현물임
  • CRYSTALS 알고리듬 모음에 속하며 대수 격자에 기반한 Dilithium을 C 참조 구현과 문서를 바탕으로 구현했고, 내부에서 사용하는 SHAKE128/256은 Bouncy Castle 의존성으로 제공됨
  • 문서화된 보안 수준 2·3·5를 모두 지원하며, 세 수준 모두 deterministic signature scheme을 사용하고 공식 패키지의 KAT 테스트를 통과함
  • JCE 사용 흐름은 DilithiumProvider를 등록한 뒤 KeyPairGenerator.getInstance("Dilithium"), Signature.getInstance("Dilithium"), KeyFactory.getInstance("Dilithium")로 키 생성·서명·검증·키 복원을 수행하는 방식임
    • 보안 수준은 DilithiumParameterSpec.LEVEL2, LEVEL3, LEVEL5 또는 getSpecForSecurityLevel()로 지정함
    • 공개키와 개인키는 .getEncoded()로 바이트 표현을 얻고, 참조 구현과 호환되는 형식으로 직렬화·역직렬화함
    • 바이트 표현에는 parameter spec이 인코딩되지 않아 키 복원 시 DilithiumPublicKeySpec 또는 DilithiumPrivateKeySpec에 parameter spec을 명시해야 함
  • 공식 Dilithium 패키지의 known-answer test 요청 파일을 읽고 응답 파일을 생성하는 KAT.java 유틸리티를 제공하며, 실행 인자는 <input-request-file> <output-response-file> <level> 형식임
  • 현재 구현은 Dilithium 3.1을 반영하며, 표준화가 진행 중인 FIPS 204 또는 ML-DSA 버전과는 다름
  • “for fun”으로 며칠 동안 작성된 구현이며 production-grade code가 아니고, 제3자 취약점 검토가 없으며, 어떠한 보증이나 지원도 제공되지 않음
  • Apache 2.0 라이선스로 제공됨

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 제 프로젝트가 Hacker News에서 주목받는 걸 보니 기쁨. 이건 논문과 참조 구현에서 영감을 받은 순수 장난감 구현임
    제공된 테스트 케이스는 모두 통과하지만, 주로 재미로 만들었고 표준 JCE 인터페이스와 자연스럽게 맞물려 동작하는지 보려고 작성했음. 질문이나 피드백이 있으면 편하게 물어봐도 됨

    • 실제 서비스에 쓰려면 무엇이 필요할지 궁금함. 양자내성 암호를 위한 Java 라이브러리 중 운영 환경에서 쓸 만큼 준비된 것이 있는지도 알고 싶음

  • 이 Dilithium 장난감 구현의 핵심 부분은 대부분 여기에서 볼 수 있음: https://github.com/mthiim/dilithium-java/blob/main/src/main/...

  • RSA/ECDSA처럼 더 확립되고 널리 쓰이는 알고리즘 위에 양자내성 암호 알고리즘을 얹어 쓰는 게 좋은 생각인지 궁금함
    양자내성 암호는 아직 너무 최첨단이라 사용하기가 편하지 않음

    • 실제로 커뮤니티가 하고 있는 일이 바로 그 방식으로 보임
      Cloudflare는 최근 양자내성 암호를 활성화했고, X25519+Kyber를 사용함 [0]. Signal의 양자내성 암호도 같은 방식을 씀 [1].
      몇 년 전 어떤 양자내성 알고리즘이 고전 컴퓨터에서 깨졌던 일에서 이런 흐름이 나온 것 같음 [2].
      이제 공격자는 고전 알고리즘과 양자내성 알고리즘을 둘 다 깨야 함
      [0] https://blog.cloudflare.com/post-quantum-to-origins/
      [1] https://signal.org/blog/pqxdh/
      [2] https://www.quantamagazine.org/post-quantum-cryptography-sch...
    • 아는 한 Shor 알고리즘은 아직 현실성이 낮음. 합리적인 시간 안에 실행하려면 현재 가능한 것보다 훨씬 많은 큐비트가 필요하기 때문임
      수백만 큐비트가 필요할 텐데, 최첨단 장치도 현재는 많아야 수백 개 수준임. 앞으로 몇 년, 어쩌면 몇십 년 동안은 운영 코드에서 양자내성 알고리즘을 크게 걱정하지 않을 것 같음
    • 현재 대체로 받아들여지지만 모두가 동의하는 것은 아닌 표준은 하이브리드 암호화임. KEM/DEM에서 말하는 “하이브리드”와는 다르지만, 보통은 하이브리드 KEM/DEM 암호체계와 함께 쓰게 됨
      이 방식은 평문에 접근하려면 고전 알고리즘과 양자내성 알고리즘을 모두 깨야 하도록 보장함. 암호화를 단순히 감싸는지, Campagna와 Petcher의 예처럼 하이브리드 KEM 결합기를 쓰는지는 더 미묘한 문제라 내 수준보다 더 정교한 판단이 필요함
    • 우리 생애에 양자컴퓨터가 더 실용화된다면, 지금의 비밀이 나중에 그런 분석에 노출되면 안 됨. 양자컴퓨터를 확장하는 일은 진공관과 트랜지스터가 집적회로로 발전한 것처럼 단순하지 않지만, 전문가들의 난이도 추정은 “매우매우매우 어렵다”부터 “물리적으로 불가능한 상태로 남을 것”까지 갈림
      어느 쪽이든 현대 표준의 암호화 키를 무차별 대입으로 깨는 것보다는 가능성이 높으므로, 오늘 양자 이후 보안을 우선시할 근거는 있음.
      다만 조심해야 한다는 점도 맞음. PQ 알고리즘에 부채널이나 구현 취약점이 있으면 오히려 훨씬 나빠질 수 있음. 최악의 경우 PQ 구현에 원격 코드 실행 취약점이 있다고 상상해 보면 됨. 그래서 신중하게 접근하고 코드를 엄격히 검토하는 게 좋음
    • 양자내성 암호와 기존 암호를 함께 쓰되, 둘 중 하나가 깨져도 조합 전체가 무너지지 않도록 만든 방식에는 실질적인 위험이 없음
      키 교환에서는 꽤 쉬운 편이고, 방식에 따라 출력값을 XOR하거나 이어 붙이면 됨

  • README에는 Bouncy Castle 의존성이 언급되어 있는데, BC에는 이미 Java 기반 PQC 서명 방식이 여러 개 들어 있음. https://doc.primekey.com/bouncycastle/interoperability#Inter...와 https://github.com/bcgit/bc-java를 참고하면 됨

  • 며칠 전 Daniel Bernstein이 NSA가 결함 있는 양자 이후 암호 구현을 퍼뜨리려 한다고 경고했음. 링크는 못 찾겠음

  • 다른 양자 이후 서명 방식인 sphincs+ 의 단일 파일 Java 구현을 작성/이식해 둔 것이 여기 있음
    https://github.com/Peergos/sphincsplus

  • “RSA와 ECC 암호 알고리즘은 Shor 알고리즘을 쓰는 양자컴퓨터 공격에 취약하다는 사실이 오래전부터 알려져 있다.”
    이게 사실이고 그런 규모의 양자컴퓨터가 실제로 등장한다면 Bitcoin에는 어떤 영향을 주는지 궁금함

    • 문제가 되기 전에 이전될 것임. 설령 실제로 벌어져도, 최초로 알려진 공격 지점에서 양자내성 암호화를 넣어 포크하면 됨

  • “이것은 며칠 만에 재미로 작성한 구현입니다. 운영 등급 코드로 의도된 것이 아닙니다. 어떤 종류의 보증이나 지원도 제공되지 않습니다. 다만 양자 이후 알고리즘을 들여다보고 실험하는 데는 유용할 수 있습니다. 본인 책임하에 사용하세요. 이 조건이 마음에 들지 않는다면 이 소프트웨어를 사용해서는 안 됩니다”

답변달기
GeekNews BeeBS 게시판 오픈! 자유로운 이야기와 소소한 일상을 함께 나눠보세요.