mthiim/dilithium-java - Triển khai thuật toán mật mã kháng điện toán lượng tử bằng Java
(github.com/mthiim)- Triển khai Dilithium 3.1 bằng Java và bọc các phép toán nguyên thủy dưới dạng JCE provider, cho phép sử dụng tạo khóa, ký và xác minh thông qua giao diện mật mã Java tiêu chuẩn
- Trong bối cảnh RSA và ECC dễ bị tấn công bởi máy tính lượng tử sử dụng Shor's algorithm, đây là một triển khai nhằm thử nghiệm và học tập về Dilithium, một trong các phương thức chữ ký số hậu lượng tử do NIST lựa chọn
- Thuộc họ thuật toán CRYSTALS và dựa trên lưới đại số, Dilithium được triển khai dựa trên mã tham chiếu C và tài liệu liên quan; SHAKE128/256 được sử dụng nội bộ được cung cấp thông qua phụ thuộc Bouncy Castle
- Hỗ trợ đầy đủ các mức bảo mật 2, 3 và 5 theo tài liệu, cả ba mức đều sử dụng deterministic signature scheme và vượt qua các bài kiểm thử KAT của gói chính thức
- Quy trình sử dụng JCE là đăng ký
DilithiumProvider, sau đó dùngKeyPairGenerator.getInstance("Dilithium"),Signature.getInstance("Dilithium"),KeyFactory.getInstance("Dilithium")để thực hiện tạo khóa, ký, xác minh và khôi phục khóa- Mức bảo mật được chỉ định bằng
DilithiumParameterSpec.LEVEL2,LEVEL3,LEVEL5hoặcgetSpecForSecurityLevel() - Khóa công khai và khóa riêng có thể lấy biểu diễn byte bằng
.getEncoded()và được tuần tự hóa/giải tuần tự hóa theo định dạng tương thích với triển khai tham chiếu - Biểu diễn byte không mã hóa parameter spec, nên khi khôi phục khóa cần chỉ rõ parameter spec trong
DilithiumPublicKeySpechoặcDilithiumPrivateKeySpec
- Mức bảo mật được chỉ định bằng
- Cung cấp tiện ích
KAT.javađể đọc tệp yêu cầu known-answer test của gói Dilithium chính thức và tạo tệp phản hồi, với tham số chạy theo dạng<input-request-file> <output-response-file> <level> - Triển khai hiện tại phản ánh Dilithium 3.1 và khác với phiên bản FIPS 204 hoặc ML-DSA đang trong quá trình tiêu chuẩn hóa
- Đây là một triển khai được viết trong vài ngày “for fun”, không phải production-grade code, chưa được bên thứ ba rà soát lỗ hổng và không đi kèm bất kỳ bảo đảm hay hỗ trợ nào
- Được phát hành theo giấy phép Apache 2.0
1 bình luận
Ý kiến trên Hacker News
Thật vui khi thấy dự án của tôi được chú ý trên Hacker News. Đây là một bản triển khai đồ chơi thuần túy, lấy cảm hứng từ bài báo và bản triển khai tham chiếu
Nó vượt qua tất cả các test case được cung cấp, nhưng chủ yếu được làm cho vui, và tôi viết để xem liệu nó có thể hoạt động ăn khớp tự nhiên với giao diện JCE tiêu chuẩn hay không. Nếu có câu hỏi hoặc phản hồi thì cứ thoải mái hỏi
Phần cốt lõi của bản triển khai đồ chơi Dilithium này phần lớn có thể xem ở đây: https://github.com/mthiim/dilithium-java/blob/main/src/main/...
Tôi tự hỏi liệu có phải là ý hay khi đặt thuật toán mật mã hậu lượng tử lên trên các thuật toán đã được thiết lập và dùng rộng rãi hơn như RSA/ECDSA hay không
Mật mã hậu lượng tử vẫn còn quá tiên tiến nên chưa dễ dùng
Cloudflare gần đây đã bật mật mã hậu lượng tử và dùng X25519+Kyber [0]. Mật mã hậu lượng tử của Signal cũng dùng cùng cách này [1].
Có vẻ xu hướng này xuất phát từ việc vài năm trước một thuật toán hậu lượng tử nào đó đã bị phá bằng máy tính cổ điển [2].
Giờ kẻ tấn công phải phá cả thuật toán cổ điển lẫn thuật toán hậu lượng tử
[0] https://blog.cloudflare.com/post-quantum-to-origins/
[1] https://signal.org/blog/pqxdh/
[2] https://www.quantamagazine.org/post-quantum-cryptography-sch...
Có lẽ sẽ cần hàng triệu qubit, trong khi các thiết bị tối tân hiện cũng chỉ ở mức nhiều nhất là vài trăm. Trong vài năm tới, thậm chí vài thập kỷ tới, tôi nghĩ chúng ta sẽ chưa phải quá lo về thuật toán hậu lượng tử trong mã vận hành
Cách này bảo đảm rằng để truy cập bản rõ, phải phá cả thuật toán cổ điển lẫn thuật toán hậu lượng tử. Việc chỉ đơn giản bọc lớp mã hóa hay dùng bộ kết hợp KEM lai như ví dụ của Campagna và Petcher là vấn đề tinh tế hơn, cần phán đoán chuyên sâu hơn mức của tôi
Dù thế nào thì khả năng đó vẫn cao hơn việc phá khóa mã hóa theo chuẩn hiện đại bằng vét cạn, nên có cơ sở để ưu tiên bảo mật hậu lượng tử ngay hôm nay.
Tuy nhiên đúng là cũng phải thận trọng. Nếu thuật toán PQ có kênh kề hoặc lỗ hổng triển khai thì tình hình có thể còn tệ hơn nhiều. Trường hợp xấu nhất, hãy tưởng tượng bản triển khai PQ có lỗ hổng thực thi mã từ xa. Vì vậy nên tiếp cận cẩn trọng và rà soát mã thật nghiêm ngặt
Với trao đổi khóa thì khá dễ, tùy cách làm có thể XOR các giá trị đầu ra hoặc nối chúng lại
README có nhắc đến phụ thuộc Bouncy Castle, mà BC vốn đã có nhiều cơ chế chữ ký PQC dựa trên Java. Có thể tham khảo https://doc.primekey.com/bouncycastle/interoperability#Inter... và https://github.com/bcgit/bc-java
Vài ngày trước Daniel Bernstein đã cảnh báo rằng NSA đang cố phát tán các bản triển khai mật mã hậu lượng tử có lỗi. Tôi không tìm được link
https://news.ycombinator.com/item?id=37756656
Tôi đã viết/port một bản triển khai Java một file cho sphincs+, một cơ chế chữ ký hậu lượng tử khác, ở đây
https://github.com/Peergos/sphincsplus
“Từ lâu người ta đã biết rằng các thuật toán mật mã RSA và ECC dễ bị tấn công bởi máy tính lượng tử dùng thuật toán Shor.”
Nếu điều này là thật và máy tính lượng tử ở quy mô đó thực sự xuất hiện, tôi tò mò nó sẽ ảnh hưởng thế nào đến Bitcoin
“Đây là bản triển khai được viết cho vui trong vài ngày. Nó không nhằm làm mã cấp production. Không có bất kỳ bảo đảm hay hỗ trợ nào được cung cấp. Tuy nhiên, nó có thể hữu ích để xem xét và thử nghiệm các thuật toán hậu lượng tử. Hãy tự chịu trách nhiệm khi sử dụng. Nếu bạn không thích điều kiện này thì không nên dùng phần mềm này”