mthiim/dilithium-java - การใช้งานอัลกอริทึมการเข้ารหัสที่ทนทานต่อควอนตัมคอมพิวติ้งด้วย Java
(github.com/mthiim)- เป็นการใช้งาน Dilithium 3.1 ด้วย Java และห่อหุ้ม primitive operations เป็น JCE provider ทำให้สามารถใช้งานการสร้างคีย์ การลงนาม และการตรวจสอบผ่านอินเทอร์เฟซการเข้ารหัสมาตรฐานของ Java ได้
- เป็นการใช้งานสำหรับทดลองและเรียนรู้ Dilithium ซึ่งเป็นหนึ่งในวิธีลายเซ็นดิจิทัลหลังยุคควอนตัมที่ NIST คัดเลือก โดยมีพื้นฐานจากบริบทที่ RSA และ ECC มีความเปราะบางต่อการโจมตีด้วยคอมพิวเตอร์ควอนตัมที่ใช้ Shor's algorithm
- อยู่ในชุดอัลกอริทึม CRYSTALS และได้ใช้งาน Dilithium ซึ่งอิงพีชคณิต lattice โดยอาศัย C reference implementation และเอกสาร ส่วน SHAKE128/256 ที่ใช้ภายในให้มาผ่าน dependency ของ Bouncy Castle
- รองรับระดับความปลอดภัย 2, 3 และ 5 ตามเอกสารทั้งหมด โดยทั้งสามระดับใช้ deterministic signature scheme และผ่าน KAT tests ของแพ็กเกจทางการ
- โฟลว์การใช้งาน JCE คือ ลงทะเบียน
DilithiumProviderแล้วใช้KeyPairGenerator.getInstance("Dilithium"),Signature.getInstance("Dilithium"),KeyFactory.getInstance("Dilithium")เพื่อสร้างคีย์ ลงนาม ตรวจสอบ และกู้คืนคีย์- ระบุระดับความปลอดภัยด้วย
DilithiumParameterSpec.LEVEL2,LEVEL3,LEVEL5หรือgetSpecForSecurityLevel() - public key และ private key รับรูปแบบไบต์ด้วย
.getEncoded()และทำ serialization/deserialization ในรูปแบบที่เข้ากันได้กับ reference implementation - รูปแบบไบต์ไม่ได้ encode parameter spec ไว้ ดังนั้นเมื่อกู้คืนคีย์ต้องระบุ parameter spec ใน
DilithiumPublicKeySpecหรือDilithiumPrivateKeySpec
- ระบุระดับความปลอดภัยด้วย
- มี utility
KAT.javaสำหรับอ่านไฟล์คำขอ known-answer test ของแพ็กเกจ Dilithium ทางการและสร้างไฟล์คำตอบ โดยอาร์กิวเมนต์ตอนรันอยู่ในรูปแบบ<input-request-file> <output-response-file> <level> - การใช้งานปัจจุบันสะท้อน Dilithium 3.1 และแตกต่างจาก FIPS 204 หรือ ML-DSA เวอร์ชันที่กำลังอยู่ระหว่างการทำมาตรฐาน
- เป็นการใช้งานที่เขียนขึ้นในไม่กี่วัน “for fun” ไม่ใช่ production-grade code ไม่มีการตรวจสอบช่องโหว่โดยบุคคลที่สาม และไม่มีการรับประกันหรือการสนับสนุนใด ๆ
- เผยแพร่ภายใต้ไลเซนส์ Apache 2.0
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
ดีใจที่เห็นโปรเจกต์ของผมได้รับความสนใจบน Hacker News นี่เป็น implementation แบบของเล่นล้วน ๆ ที่ได้แรงบันดาลใจจากงานวิจัยและ implementation อ้างอิง
แม้จะผ่าน test case ที่ให้มาทั้งหมด แต่ผมทำมันขึ้นมาเพื่อความสนุกเป็นหลัก และเพื่อดูว่ามันจะทำงานเข้ากับ อินเทอร์เฟซ JCE มาตรฐาน ได้อย่างเป็นธรรมชาติหรือไม่ ถ้ามีคำถามหรือข้อเสนอแนะก็ถามมาได้สบาย ๆ
ส่วนสำคัญหลัก ๆ ของ implementation Dilithium แบบของเล่นนี้ดูได้เกือบทั้งหมดที่นี่: https://github.com/mthiim/dilithium-java/blob/main/src/main/...
ผมสงสัยว่าการวาง อัลกอริทึมเข้ารหัสทนทานต่อควอนตัม ทับลงไปบนอัลกอริทึมที่มั่นคงและใช้แพร่หลายกว่าอย่าง RSA/ECDSA จะเป็นความคิดที่ดีหรือไม่
การเข้ารหัสทนทานต่อควอนตัมยังล้ำหน้าเกินไปจนยังใช้งานได้ไม่สะดวกนัก
Cloudflare เพิ่งเปิดใช้ การเข้ารหัสทนทานต่อควอนตัม และใช้ X25519+Kyber [0] ส่วนการเข้ารหัสทนทานต่อควอนตัมของ Signal ก็ใช้แนวทางเดียวกัน [1]
ดูเหมือนว่ากระแสนี้จะเกิดขึ้นหลังจากที่มีอัลกอริทึม post-quantum บางตัวถูกเจาะได้ด้วยคอมพิวเตอร์แบบดั้งเดิมเมื่อไม่กี่ปีก่อน [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...
น่าจะต้องใช้คิวบิตระดับหลายล้านตัว ขณะที่อุปกรณ์ล้ำสมัยที่สุดตอนนี้ก็ยังมีได้มากสุดเพียงระดับหลายร้อยตัวเท่านั้น ผมเลยคิดว่าในอีกหลายปีข้างหน้า หรืออาจหลายสิบปี เราคงยังไม่ต้องกังวลกับอัลกอริทึมทนทานต่อควอนตัมมากนักในโค้ด production
วิธีนี้รับประกันว่าหากต้องการเข้าถึง plaintext ก็ต้องเจาะทั้งอัลกอริทึมแบบดั้งเดิมและอัลกอริทึมทนทานต่อควอนตัมให้ได้พร้อมกัน ส่วนจะห่อชั้นการเข้ารหัสแบบเรียบง่าย หรือจะใช้ตัวประกอบ hybrid KEM แบบในตัวอย่างของ Campagna และ Petcher นั้นเป็นประเด็นที่ละเอียดอ่อนกว่าและต้องอาศัยวิจารณญาณที่ลึกกว่าระดับของผม
ไม่ว่ากรณีไหน ความเป็นไปได้ก็ยังสูงกว่าการ brute force คีย์เข้ารหัสของมาตรฐานสมัยใหม่ ดังนั้นจึงมีเหตุผลที่จะให้ความสำคัญกับ ความปลอดภัยยุคหลังควอนตัม ตั้งแต่วันนี้
แต่ก็จริงที่ต้องระวัง เพราะถ้าอัลกอริทึม PQ มีช่องโหว่ side-channel หรือช่องโหว่จากการ implementation สถานการณ์อาจเลวร้ายยิ่งกว่าเดิม ลองนึกถึงกรณีเลวร้ายที่สุดว่ามีช่องโหว่ remote code execution อยู่ใน implementation ของ PQ ก็ได้ เพราะอย่างนั้นควรค่อย ๆ เดินอย่างระมัดระวังและตรวจทานโค้ดอย่างเข้มงวด
สำหรับ การแลกเปลี่ยนกุญแจ ถือว่าทำได้ค่อนข้างง่าย และขึ้นอยู่กับวิธีที่ใช้ คุณอาจ XOR ผลลัพธ์เข้าด้วยกันหรือจะนำมาต่อกันก็ได้
ใน README มีการพูดถึง dependency ของ Bouncy Castle ซึ่งใน BC มีระบบลายเซ็น PQC บน Java อยู่หลายตัวแล้ว ดูได้ที่ https://doc.primekey.com/bouncycastle/interoperability#Inter... และ https://github.com/bcgit/bc-java
เมื่อไม่กี่วันก่อน Daniel Bernstein ออกมาเตือนว่า NSA กำลังพยายามเผยแพร่ implementation การเข้ารหัสยุคหลังควอนตัม ที่มีข้อบกพร่อง แต่ผมหาลิงก์ไม่เจอ
https://news.ycombinator.com/item?id=37756656
มี implementation Java แบบไฟล์เดียวของ sphincs+ ซึ่งเป็นระบบลายเซ็นยุคหลังควอนตัมอีกแบบหนึ่ง ที่ผมเคยเขียน/พอร์ตไว้ อยู่ที่นี่
https://github.com/Peergos/sphincsplus
“เป็นที่ทราบกันมานานแล้วว่าอัลกอริทึมเข้ารหัส RSA และ ECC มีความเปราะบางต่อการโจมตีด้วยคอมพิวเตอร์ควอนตัมที่ใช้อัลกอริทึมของ Shor”
ถ้านี่เป็นเรื่องจริง และคอมพิวเตอร์ควอนตัมระดับนั้นเกิดขึ้นจริง ผมก็สงสัยว่าจะส่งผลอย่างไรกับ Bitcoin
“นี่คือ implementation ที่เขียนขึ้นเล่น ๆ ภายในไม่กี่วัน ไม่ได้ตั้งใจให้เป็นโค้ดระดับ production ไม่มีการรับประกันหรือการสนับสนุนใด ๆ ทั้งสิ้น แต่ก็อาจมีประโยชน์สำหรับการลองศึกษาและทดลองกับ อัลกอริทึมยุคหลังควอนตัม ใช้งานโดยรับความเสี่ยงเอง หากคุณไม่ยอมรับเงื่อนไขนี้ คุณไม่ควรใช้ซอฟต์แวร์นี้”