mthiim/dilithium-java - Java में quantum-computing-resistant cryptography algorithm का implementation

• Dilithium 3.1 का Java implementation, जिसमें primitive operations को JCE provider के रूप में wrap किया गया है, ताकि standard Java cryptography interface के जरिए key generation, signing और verification का उपयोग किया जा सके
• इस पृष्ठभूमि में कि RSA और ECC, Shor's algorithm का उपयोग करने वाले quantum computer attacks के प्रति कमजोर हैं, यह NIST द्वारा चुनी गई post-quantum digital signature schemes में से एक Dilithium को प्रयोग और सीखने के लिए बनाया गया implementation है
• यह CRYSTALS algorithm suite का हिस्सा है और algebraic lattice पर आधारित Dilithium को C reference implementation और documentation के आधार पर implement किया गया है; अंदर उपयोग होने वाला SHAKE128/256, Bouncy Castle dependency के जरिए प्रदान किया जाता है
• documented security levels 2, 3, 5 सभी समर्थित हैं, और तीनों स्तर deterministic signature scheme का उपयोग करते हैं तथा official package के KAT tests पास करते हैं
• JCE usage flow में पहले DilithiumProvider register किया जाता है, फिर KeyPairGenerator.getInstance("Dilithium"), Signature.getInstance("Dilithium"), KeyFactory.getInstance("Dilithium") के जरिए key generation, signing, verification और key restoration किया जाता है
  • security level को DilithiumParameterSpec.LEVEL2, LEVEL3, LEVEL5 या getSpecForSecurityLevel() से specify किया जाता है
  • public key और private key के byte representation .getEncoded() से प्राप्त किए जाते हैं, और reference implementation के compatible format में serialize/deserialize किए जाते हैं
  • byte representation में parameter spec encode नहीं होता, इसलिए key restore करते समय DilithiumPublicKeySpec या DilithiumPrivateKeySpec में parameter spec को explicitly देना पड़ता है
• official Dilithium package की known-answer test request file पढ़कर response file बनाने के लिए KAT.java utility दी गई है, और execution arguments का format <input-request-file> <output-response-file> <level> है
• मौजूदा implementation Dilithium 3.1 को दर्शाता है, और standardization के तहत चल रहे FIPS 204 या ML-DSA versions से अलग है
• यह कुछ दिनों में “for fun” के तौर पर लिखा गया implementation है; यह production-grade code नहीं है, किसी third-party vulnerability review से नहीं गुज़रा है, और किसी भी प्रकार की warranty या support प्रदान नहीं करता
• Apache 2.0 license के तहत उपलब्ध है

[GN⁺]

Hacker News टिप्पणियाँ

• अपने प्रोजेक्ट को Hacker News पर ध्यान मिलते देख खुशी हो रही है। यह पेपर और reference implementation से प्रेरित पूरी तरह खिलौना implementation है
  दिए गए सभी test cases पास हो जाते हैं, लेकिन इसे मुख्यतः मज़े के लिए बनाया गया था और यह देखने के लिए लिखा गया था कि यह standard JCE interface के साथ स्वाभाविक रूप से काम करता है या नहीं। कोई सवाल या feedback हो तो बेझिझक पूछें

  • जिज्ञासा है कि इसे असली service में इस्तेमाल करने के लिए क्या चाहिए होगा। यह भी जानना चाहूँगा कि post-quantum cryptography के लिए Java libraries में कोई ऐसी है जो production environment के लिए तैयार हो

• इस Dilithium खिलौना implementation का मुख्य हिस्सा ज्यादातर यहाँ देखा जा सकता है: https://github.com/mthiim/dilithium-java/blob/main/src/main/...

  • Dilithium specification भी यहाँ है: https://pq-crystals.org/dilithium/data/dilithium-specificati...

• सोच रहा हूँ कि RSA/ECDSA जैसे ज्यादा स्थापित और व्यापक रूप से इस्तेमाल होने वाले algorithms के ऊपर post-quantum cryptography algorithms लगाकर इस्तेमाल करना अच्छा विचार है या नहीं
  post-quantum cryptography अभी बहुत cutting-edge है, इसलिए इस्तेमाल में सहज नहीं लगती

  • असल में community जो कर रही है, वह ठीक यही तरीका लगता है
    Cloudflare ने हाल ही में post-quantum cryptography enable की है और X25519+Kyber का इस्तेमाल किया है [0]। Signal की post-quantum cryptography भी यही तरीका अपनाती है [1]।
    कुछ साल पहले एक post-quantum algorithm के classical computer पर टूट जाने की घटना से शायद यह रुझान निकला है [2]।
    अब attacker को classical algorithm और post-quantum algorithm, दोनों को तोड़ना होगा
    [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 algorithm अभी व्यावहारिक नहीं है। उसे उचित समय में चलाने के लिए आज संभव से कहीं अधिक qubits चाहिए
    शायद लाखों qubits की जरूरत होगी, जबकि state-of-the-art devices भी फिलहाल ज्यादा से ज्यादा सैकड़ों के स्तर पर हैं। अगले कुछ सालों, शायद कुछ दशकों तक, production code में post-quantum algorithms को लेकर बहुत चिंता नहीं होगी
  • अभी व्यापक रूप से स्वीकार किया गया, लेकिन सर्वसम्मत नहीं, standard hybrid encryption है। यह KEM/DEM में कहे जाने वाले “hybrid” से अलग है, लेकिन आम तौर पर hybrid KEM/DEM cryptosystem के साथ ही इस्तेमाल होगा
    यह तरीका सुनिश्चित करता है कि plaintext तक पहुँचने के लिए classical algorithm और post-quantum algorithm, दोनों को तोड़ना पड़े। encryption को बस wrap किया जाए या Campagna और Petcher के उदाहरण की तरह hybrid KEM combiner इस्तेमाल किया जाए—यह ज्यादा सूक्ष्म मुद्दा है और मेरे स्तर से अधिक परिष्कृत निर्णय मांगता है
  • अगर हमारे जीवनकाल में quantum computers अधिक व्यावहारिक हो जाते हैं, तो आज के secrets बाद में ऐसे analysis के सामने उजागर नहीं होने चाहिए। quantum computers को scale करना vacuum tubes और transistors के integrated circuits में विकसित होने जितना सीधा नहीं है, लेकिन experts के कठिनाई के अनुमान “बहुत-बहुत-बहुत कठिन” से लेकर “भौतिक रूप से असंभव ही रहेगा” तक बंटे हुए हैं
    किसी भी स्थिति में, modern standards की encryption keys को brute force से तोड़ने की तुलना में इसकी संभावना ज्यादा है, इसलिए आज post-quantum security को प्राथमिकता देने का आधार है।
    हालांकि सावधानी जरूरी है, यह भी सही है। अगर PQ algorithms में side-channel या implementation vulnerabilities हों, तो स्थिति उलटे काफी खराब हो सकती है। सबसे खराब स्थिति में सोचिए कि PQ implementation में remote code execution vulnerability हो। इसलिए संभलकर आगे बढ़ना और code की सख्त review करना बेहतर है
  • post-quantum cryptography और मौजूदा cryptography को साथ इस्तेमाल करने, लेकिन ऐसा बनाने कि दोनों में से किसी एक के टूटने पर भी पूरा संयोजन न गिरे, में कोई वास्तविक जोखिम नहीं है
    key exchange में यह काफी आसान है, और तरीके के अनुसार outputs को XOR किया जा सकता है या concatenate किया जा सकता है

• README में Bouncy Castle dependency का उल्लेख है, जबकि BC में पहले से Java-based PQC signature schemes कई मौजूद हैं। https://doc.primekey.com/bouncycastle/interoperability#Inter... और https://github.com/bcgit/bc-java देखें

• कुछ दिन पहले Daniel Bernstein ने चेतावनी दी थी कि NSA दोषपूर्ण post-quantum cryptography implementations फैलाने की कोशिश कर रहा है। link नहीं मिल रहा

  • जिस लेख की बात है, वह यहाँ है। हालांकि यह Dilithium नहीं, Kyber पर है
    https://news.ycombinator.com/item?id=37756656

• एक अन्य post-quantum signature scheme sphincs+ का single-file Java implementation लिखा/port किया हुआ यहाँ है
  https://github.com/Peergos/sphincsplus

• “यह लंबे समय से ज्ञात है कि RSA और ECC cryptographic algorithms, Shor algorithm का इस्तेमाल करने वाले quantum computer attacks के प्रति vulnerable हैं।”
  अगर यह सच है और उस scale का quantum computer सच में आ जाता है, तो Bitcoin पर इसका क्या असर होगा, यह जानना चाहूँगा

  • समस्या बनने से पहले migration हो जाएगा। भले ही यह सच में हो, पहले ज्ञात attack point पर post-quantum encryption जोड़कर fork किया जा सकता है

• “यह implementation कुछ दिनों में मज़े के लिए लिखा गया है। इसे production-grade code के रूप में intended नहीं किया गया है। किसी भी प्रकार की warranty या support प्रदान नहीं किया जाता। हालांकि post-quantum algorithms को देखने और experiment करने में यह उपयोगी हो सकता है। अपने जोखिम पर इस्तेमाल करें। अगर ये शर्तें आपको स्वीकार नहीं हैं, तो आपको इस software का इस्तेमाल नहीं करना चाहिए”