NIST की Kyber-512 सुरक्षा स्तर गणना का खंडन
(blog.cr.yp.to)- मुख्य आलोचना यह है कि NIST ने Kyber-512 को post-quantum cryptography standard के रूप में आगे बढ़ाते समय attack cost की गणना गलत की और उसके security level को बढ़ा-चढ़ाकर दिखाया
- विवाद यह है कि हर iteration में लगने वाली computation cost और memory access cost को जोड़ा जाना चाहिए था, लेकिन NIST ने उन्हें मानो गुणा किया हो ऐसे बरता, जिससे Matzov के 2^137 अनुमान पर “40-bit extra security” जोड़ दी गई
- Kyber-512 को Core-SVP के आधार पर 2^118 स्तर का बताया गया था, और NIST ने इसे AES-128 benchmark यानी लगभग 2^143 bit operations से मिलाने की कोशिश की, लेकिन आलोचना है कि जोड़े गए आंकड़ों की units और meaning मेल नहीं खाते
- Kyber, Kyber-512, Kyber-768, Kyber-1024 जैसी सीमित parameter choices ही देता है, जबकि तुलना में कहा गया है कि NTRU और NTRU Prime size और security level के अधिक सूक्ष्म विकल्प देते हैं
- Kyber-512 standardization में attack analysis की uncertainty, memory cost model की quantification न होना, और public review की कमी शामिल है; लेखक Kyber-512 को हटाने और NIST की calculation error को सार्वजनिक करने की मांग करता है
calculation error का मूल मुद्दा
- शुरुआत इस सरल उदाहरण से होती है कि “2^40 + 2^40, 2^80 नहीं बल्कि 2^41 है”
- जिन संख्याओं को गुणा करना है और जिन्हें जोड़ना है, उन्हें गड़बड़ा देने से security level बहुत बढ़ा-चढ़ाकर दिख सकता है
- Kyber-512 security level विवाद में समस्या वाली संरचना यह है
- attack कई iterations से मिलकर बना होता है
- हर iteration में computation cost और memory access cost होती है
- total cost को
number of iterations × cost per iterationसे calculate करना चाहिए - cost per iteration के अंदर computation cost और memory access cost को जोड़ना चाहिए
- मुख्य आलोचना यह है कि NIST ने computation cost और memory access cost को जोड़ने के बजाय गुणा करने जैसा effect पैदा किया
- उदाहरण के लिए 2^25 bit operations/iteration और 2^35 bit operations/iteration को जोड़ा जाना चाहिए
- इन्हें गुणा करने पर unit
bitops^2/iter^2हो जाती है, जो attack cost की unit नहीं है - ऐसा multiplication attack cost को लाखों गुना या उससे भी ज्यादा बढ़ा सकता है
NISTPQC और Kyber-512 की पृष्ठभूमि
- NIST ने 2022 में Kyber-512 standardization plan घोषित किया और 2023 में Kyber-512 draft standard जारी किया
- आलोचना का focus इस बात पर है कि NIST ने Kyber-512 के security level को justify करने की प्रक्रिया में गंभीर calculation mistake की
- मार्च 2022 में NSA, NIST, and post-quantum cryptography FOIA request दायर की गई, और बाद में lawsuit के जरिए NIST के कुछ internal documents सार्वजनिक हुए
- public और non-public documents की तुलना से माना गया कि NISTPQC process में NSA की involvement, NIST की public explanation से ज्यादा थी
- बताया गया कि 2016 की
pqc@nist.govteam list में NIST personnel से ज्यादा NSA personnel थे - NIST ने 2020 की public materials में कहा था कि NSA feedback ने decisions को प्रभावित नहीं किया, और NIST ही public information के आधार पर decisions लेता है
- जनवरी 2023 में Kyber-512 security level claims से जुड़ी नई FOIA request दायर हुई, और कहा गया कि NIST ने फिर response delay किया, जिससे नया lawsuit हुआ
Kyber के सीमित parameter choices
- कहा गया है कि Kyber में RSA, ECC, McEliece, NTRU की तरह मनचाहे size में security level को थोड़ा-थोड़ा बढ़ाना मुश्किल है
- Kyber-576 नहीं है, और Kyber-512 से stronger choice Kyber-768 है, जिसके लिए dimension में 50% increase चाहिए
- Kyber-768 से stronger choice Kyber-1024 है
- Kyber-1024 से stronger choice दी नहीं गई है
- Kyber official document ने “dimension-256 NTT” से सभी parameter sets handle कर पाने को advantage बताया, लेकिन इस structure में 256 के multiple नहीं होने वाले dimensions के लिए core design change चाहिए
- 1KB limit वाली applications में Kyber-768 का उपयोग करना मुश्किल है और Kyber-512 highest-security Kyber choice बन जाता है
- Kyber-768 1184-byte public key और 1088-byte ciphertext का उपयोग करता है
- Kyber-512 800-byte key और 768-byte ciphertext का उपयोग करता है
- उसी 1KB limit में NTRU family ज्यादा Core-SVP estimates देती है, ऐसा comparison किया गया है
sntrup653: 994-byte key, 897-byte ciphertext, Core-SVP 2^129- NTRU-677 (
ntruhps2048677): 931-byte key, 931-byte ciphertext, Core-SVP 2^145 - Kyber-512 round-3 version को Core-SVP 2^118 के रूप में पेश किया गया
- Core-SVP वह mechanism है जिसे Kyber team ने round-1 और round-2 submissions में security level estimate करने के लिए इस्तेमाल किया, और NIST की 2020 round-2 report ने भी comparison में Core-SVP इस्तेमाल किया
NIST evaluation criteria और NTRU comparison
- NIST के 2016 official submission request ने flexibility को evaluation criteria में शामिल किया
- “good overall security and performance” को premise मानते हुए, अधिक flexibility वाली scheme को ज्यादा user requirements पूरा करने वाला माना गया
- यह भी स्पष्ट किया गया कि एक ही category के अंदर भी performance या security margin adjust करने के लिए कई parameter sets पेश किए जा सकते हैं
- NIST ने 2020 में NewHope को बाहर करते समय Kyber द्वारा category 3 parameter set को स्वाभाविक रूप से support करना एक कारण बताया
- अगर Kyber-512 minimum security level पूरा नहीं करता, तो Kyber में सिर्फ Kyber-768 और Kyber-1024 बचते हैं, और NTRU की तुलना में flexibility कम होने की समस्या बढ़ जाती है
- NIST की 2022 selection report ने कहा कि Kyber और NTRU दोनों की security में confidence है, और KEMs की overall performance भी general-purpose applications के लिए acceptable है
- इस condition में logic यह है कि Kyber-512 हटने पर NTRU, Kyber से ज्यादा favorable है क्योंकि वह smaller options, higher security options, और size-security tradeoff के ज्यादा fine-grained विकल्प देता है
NIST ने competition को skew किया — चार आलोचनाएं
-
1. NTRU की extra flexibility को ignore करना
- कहा गया है कि NTRU literature बहुत पहले से दिखाता रहा है कि कई security levels और size choices दिए जा सकते हैं
- NIST ने 2020 में announce किया कि “too many parameter sets evaluation and analysis को difficult बनाते हैं”
- official criteria में flexibility को positive बताया गया था, लेकिन बीच में “too many” वाली criticism सामने आई और NIST ने उस criterion को स्पष्ट रूप से answer नहीं किया, ऐसा आरोप है
-
2. key generation cost को बढ़ा-चढ़ाकर बताना
- Golden Cove benchmarks में Kyber-512 के लिए encapsulation 25829 cycles और decapsulation 20847 cycles हैं
- NTRU-509 के लिए encapsulation 15759 cycles और decapsulation 25134 cycles हैं, यानी ciphertext processing total Kyber-512 से 13% छोटा बताया गया
- वहीं NTRU-509 key generation 112866 cycles है, जो Kyber-512 के 17777 cycles से बड़ा है
- लेकिन दावा है कि KEM key को कई ciphertexts में reuse कर सकता है, byte send/receive cost cycles से कहीं ज्यादा important है, और Montgomery trick से NTRU key generation तेज किया जा सकता है
-
3. NTRU के higher security levels को छिपाना
- NIST ने 2020 round-2 report में category 5 parameter set को strongly recommend करना शुरू किया
- NTRU ने NTRU-1229 और NTRU-HRSS-1373 पेश किए, जिनके Core-SVP क्रमशः 2^301 और 2^310 हैं, जो Kyber-1024 के 2^254 से अधिक हैं
- NTRU Prime ने भी
sntrup1277,ntrulpr1277जैसे Core-SVP 2^270, 2^271 options पेश किए - NIST graphs की आलोचना हुई कि उन्होंने ऐसे high-security NTRU options को पर्याप्त रूप से उजागर नहीं किया
-
4. best-performance option NTRU-509 को बाहर करना
- आरोप है कि NIST ने NTRU-509 को बड़े graph और बाद की selection report के figures और tables से बाहर रखा
- NTRU-509 Kyber-512 से छोटी key और ciphertext देता है, जो NIST के इस description से मेल नहीं खाता कि “NTRU की public key और ciphertext Kyber से somewhat larger” हैं
- NTRU-509 को बाहर करना हो तो कहना होगा कि वह AES-128 minimum security level से कम है, लेकिन उसी criterion पर Kyber-512 को बनाए रखना बेहद कमजोर distinction है, ऐसी आलोचना है
Core-SVP के बाद की uncertainty
- Kyber-512 का Core-SVP 2^118 है, और AES-128 attack cost को 2^140 bit operations से थोड़ा अधिक माना गया है
- 2017 और 2019 Kyber submissions ने दावा किया कि यह Core-SVP से कम से कम 30 bits ज्यादा secure है, लेकिन आलोचना है कि उसके कुछ आधार गलत या अपर्याप्त हैं
- कहा गया कि rounding noise key attacks पर लागू नहीं होता, इसलिए वह security increase का आधार नहीं है
- sieving में subexponential cost increase का दावा unsupported है, और actual asymptotics Core-SVP से तेज हो सकती है
- SVP oracle calls और gate count कुछ हद तक valid हो सकते हैं, लेकिन Kyber-512 को बचाने के लिए पर्याप्त नहीं दिखते
- memory access cost actual attack cost में important हो सकती है, लेकिन NIST official criteria ने 2^143 “classical gates” मांगे थे, इसलिए इसे Kyber-512 को बचाने की logic के रूप में सीधे इस्तेमाल करना मुश्किल है
- round-3 Kyber submission ने Kyber-512 को बदला और Core-SVP definition भी बदलकर 2^112 नहीं बल्कि 2^118 हासिल किया, ऐसा कहा गया
- इस submission ने Kyber-512 security को 151 bits ±16 के रूप में पेश किया, और दावा किया कि 135 तक गिरने पर भी memory requirement के कारण यह “catastrophic” नहीं होगा
- इसके बाद Matzov सहित कई lattice attack analyses सामने आए, जिससे Kyber-512 security estimate और जटिल व अस्थिर हो गया
NIST की Kyber-512 rescue logic
- NIST की official call में कहा गया है कि हर security category AES-128 जैसे benchmark primitive को “potentially relevant” विभिन्न metrics में lower bound मानती है
- यानी किसी भी attack को उन सभी metrics में benchmark से अधिक resources चाहिए जिन्हें NIST practical security के लिए potentially relevant मानता है
- NIST “classical gates” को clearly define करने की requests से लंबे समय तक बचता रहा, और 2022 selection report में समझाया कि one-bit memory read/write को cost-1 gate माना जा सकता है
- NIST पर आरोप है कि NTRU-509 को exclude करते समय उसने “non-local cost model”, यानी memory access cost को लगभग free मानने वाला criterion इस्तेमाल किया
- उलटे Kyber-512 को category 1 में रखते समय उसने माना कि “realistic memory access costs” consider करने पर यह category 1 satisfy करता है
- नतीजतन, आरोप है कि NTRU-509 पर free-memory metric और Kyber-512 पर memory-expensive metric लागू किया गया
NISTBS: 7 दिसंबर 2022 की explanation का rebuttal
- 7 दिसंबर 2022 को NIST ने समझाया कि वह क्यों मानता है कि Kyber-512 NIST category I satisfy करता है, और यह लेख इसे “NISTBS” कहता है
- NISTBS की शुरुआत इस बात से होती है कि Matzov report ने Kyber-512 attack cost को 2^137 bit operations estimate किया
- AES-128 classical attack cost लगभग 2^143 bit operations मानी गई
- इसलिए 6 bits की कमी है
- NISTBS बताता है कि lattice sieving attacks को बड़ी memory पर unstructured access की जरूरत होती है, और RAM model इस cost को ignore करता है
- फिर NTRU और NTRU Prime submission documents के estimates को quote करके calculate किया गया कि category 1 sieving attack में memory access cost consider करने पर RAM model से “20~40 bits” ज्यादा हो सकता है
- समस्या यह है कि लगता है NIST ने Matzov के 2^137 में NTRU Prime के 40 bits जोड़कर इसे 2^177 level की तरह interpret किया
- NTRU Prime के 40 bits शायद
sntrup653में “real” 2^169 और “free” 2^129 के difference से estimate किए गए लगते हैं - आलोचना है कि 2^129 Core-SVP है, यानी rough number of iterations, न कि NIST के कहे RAM model का gate count
- memory access cost को cost per iteration में जोड़ना चाहिए; इसे पहले से bit operations में aggregated total computation cost से गुणा या exponent में add नहीं किया जा सकता
- NTRU Prime के 40 bits शायद
actual numbers का meaning
- NTRU Prime document
sntrup653के लिए Core-SVP 2^129 report करता है- यह rough number of iterations का estimate है
- वही document total memory access cost को 2^169 bit operations equivalent estimate करता है
- Kyber-512 को Core-SVP 2^118 के रूप में पेश किया गया
- कहा गया कि उसी तरीके से memory access cost का rough estimate 2^154 bit operations equivalent है
- Kyber document का 2^151 “gates” estimate memory access cost estimate नहीं है
- यह attack computation के अंदर bit operations की संख्या का estimate है
- “known unknowns” consider करने पर इसे 2^135~2^167 range में पेश किया गया
- इसलिए 2^151 computation cost estimate और memory access cost estimate आपस में multiply होने वाले terms नहीं, बल्कि cost per iteration dimension में meaning align करके जोड़े जाने वाले terms हैं
error पकड़ना आसान क्यों माना गया
- सरल sanity check यह है
- Kyber document Kyber-512 attack computation cost को 2^135~2^167 bit operations estimate करता है
- NTRU Prime, Kyber-512 से ज्यादा कठिन दिखने वाले
sntrup653की memory access cost को 2^169 bit operations equivalent estimate करता है - attack 2^14 तक improve हो गया, फिर भी NIST द्वारा Kyber-512 attack cost को 2^177 calculate करना अजीब है, ऐसा कहा गया
- NISTBS ने लिखा कि NTRU Prime document ने “RAM model से 40 bits additional security” estimate की, लेकिन कहा गया कि उस document के Section 6.11 में “40” या “RAM model” जैसी direct expression नहीं है
- clear review के लिए NIST को explain करना चाहिए था कि 40 exactly कहां से आया और किस metric की किस value को दर्शाता है, ऐसी आलोचना है
- दिसंबर 2022 के बाद specific scenario X के बारे में confirmation question उठाया गया कि क्या “137+40=177” calculation ही सही है, लेकिन कहा गया कि NIST ने जवाब नहीं दिया
- बाद में NIST ने कहा कि वह email “speaks for itself”, और calculation की specific interpretation को confirm नहीं किया या alternative interpretation नहीं दी, इस पर आलोचना हुई
सही calculation के लिए जरूरी research
- सही calculation में दो effects को अलग करना होगा
- Core-SVP से security estimate बढ़ने का कुछ हिस्सा iteration के अंदर computation के bit operations cost से आता है
- कुछ हिस्सा external loop से आता है, जहां number of iterations खुद बढ़ता है
- number of iterations बढ़ने वाला effect memory access cost से multiply किया जा सकता है
- इसके विपरीत iteration के अंदर computation cost और iteration के अंदर memory access cost को जोड़ना चाहिए, और इन्हें multiply करना ही core error है
- exact calculation के लिए state-of-the-art lattice attacks से जुड़े सैकड़ों pages के papers follow करते हुए, memory access cost शामिल करने पर पूरे attack stack को re-optimize करना होगा
- उदाहरण के लिए BKZ के अंदर low-memory enumeration और high-memory sieving में कौन सा बेहतर है, यह भी memory access cost डालने पर फिर से calculate करना होगा
draft standard और responsibility का मुद्दा
- अगस्त 2023 में NIST ने Kyber draft standard, ML-KEM, जारी किया
- ML-KEM-512 security category 1 है
- ML-KEM-768 category 3 है
- ML-KEM-1024 को category 5 के रूप में “claimed” लिखा गया
- समस्या यह है कि “claimed” किसकी ओर से है, यह स्पष्ट नहीं है
- NIST दावा कर रहा है, designers दावा कर रहे हैं, या कोई और — यह clear नहीं, ऐसा कहा गया
- draft Appendix A फिर से criterion पेश करता है कि category AES-128, AES-192, AES-256 को सभी potentially relevant metrics में exceed करती है
- Kyber document का latest analysis बताता है कि Kyber-512 attack cost 2^135 “classical gates” तक कम हो सकती है, जो NIST के AES-128 2^143 gates estimate से कम है
- इसलिए public analysis जरूरी है कि NIST Kyber-512 के सभी relevant metrics में AES-128 से कम से कम equal या higher होने के claim को कैसे justify करता है
निष्कर्ष और सुझाव
- निष्कर्ष यह है कि lattice attack surface अस्थिर है और पर्याप्त रूप से समझी नहीं गई है, इसलिए Kyber-512 standardization reckless है
- संभावना है कि Kyber-512 पहले से public attacks और memory access cost को consider करने पर भी AES-128 से काफी आसान हो; उलटी संभावना भी है, इसलिए actual state पता करने के लिए कठिन research चाहिए
- AES-128 itself भी multi-target attacks में 1 trillion keys में से एक को break करने के लिए 2^88 computations level तक हो सकता है, इसलिए 10~30-bit loss को ignore करना मुश्किल है
- अगर Kyber-512 standard option के रूप में बचा रहा, तो Kyber-1024 या NTRU-1229 afford कर सकने वाली applications भी fast option चुन सकती हैं, ऐसा माना गया
- final recommendation है कि Kyber-512 को हटाया जाए, और NIST सार्वजनिक रूप से Kyber-512 security level calculation error और NTRU comparison process में opaque data selection को स्वीकार करे
1 टिप्पणियां
Hacker News की राय
इस लेख को पढ़ने से पहले यह बात ज़रूर जान लें कि NIST और NSA ने यह algorithm नहीं बनाया था, बल्कि उन्होंने competition को judge किया था
ज़्यादातर analysis competitors और academia ने किया था, और Kyber team में Roberto Avanzi, Joppe Bos, Léo Ducas, Eike Kiltz, Tancrède Lepoint, Vadim Lyubashevsky, John M. Schanck, Gregor Seiler, Damien Stehlé, और Bernstein के collaborator Peter Schwabe भी शामिल थे
इतिहास में अक्सर सिर्फ़ winner ही अपनाया जाता है। AES competition को देखें तो सोचिए कि Serpent का ज़िक्र कितनी बार होता है, जबकि इसे Rijndael से ज़्यादा security margin वाला माना जाता है
ऐसा नहीं लगता कि NIST किसी गुप्त analysis के आधार पर recommendation दे रहा है
अफसोसजनक सच यह है कि Bernstein सही हो सकते हैं, लेकिन यह अलग कर पाना मुश्किल है कि NIST की तरफ़ से जवाब या चुप्पी को धोखा माना जाए, या फिर वे बस किसी ऐसे व्यक्ति से उलझना नहीं चाहते थे जो बेहद आक्रामक रुख़ लेकर आ रहा था
NIST में भी सामान्य लोग ही काम करते हैं, और बहुत संभव है कि उन्होंने तीखे स्पष्टीकरण-आग्रहों को वैसे ही लिया हो जैसे हममें से ज़्यादातर लोग आक्रामक bug reports को लेते हैं
“2024 में patent license सक्रिय होने के समय से Kyber इस्तेमाल करने को कहकर 3 साल का user data हमलावरों के सामने खोल दिया, और 2021 से NTRU इस्तेमाल करने को नहीं कहा” जैसी बढ़ा-चढ़ाकर की गई आलोचनाएँ मददगार नहीं हैं। standalone post-quantum cryptography को तुरंत deploy करने वाली जगहें भी शायद कुछ समय तक नहीं होंगी, और 2021 में NIST जिन विकल्पों का सुझाव दे सकता था, वे भी कई थे। SIKE पिछले साल टूटने से पहले काफ़ी ठीक दिखता था
NIST की इस क्षेत्र में बेदाग़ प्रतिष्ठा नहीं है, लेकिन algorithms और प्रक्रिया की आलोचना करनी हो तो बेहतर होगा कि कारणों का संक्षिप्त सार और एक-दो निर्णायक सबूत हों। ढेरों emails का analysis, सिर्फ़ एक submission से तुलना, और यह आरोप कि सभी data खींचने के लिए समय खींच रहे हैं—ये सब बात को गंभीरता से लेना कठिन बना देते हैं। अगर Kyber-512 वाकई इतना जोखिमभरा है, तो इसे और स्पष्ट रूप से बताया जाना चाहिए
यह भी बड़ी बात है कि पेज 17,000 शब्दों का है। Harry Potter के हिसाब से भी औसत पाठक को इसे पढ़ने में 70 मिनट लगेंगे, जबकि यह कोई उपन्यास नहीं बल्कि संख्याओं, विचारणीय बिंदुओं और NIST citations जैसी ऐसी पंक्तियों से भरा है जिनमें शब्द-चयन पर ध्यान देना पड़ता है। वैसे भी, post-quantum cryptography समझने जितना background हो तब भी इसे सामान्य किताब की तरह तेज़ी से पढ़ना मुश्किल है
शुरुआत में मैंने “That lawsuit has been gradually secret NIST documents, shedding some light on what was actually going on behind the scenes” पर क्लिक किया और दूसरे लेख में खिंच गया, लेकिन वह linked page भी 54,000 शब्दों का निकला। मोबाइल पर scrollbar नहीं था, इसलिए लंबाई का अंदाज़ा लगाए बिना linear तरीके से स्कैन करता रहा, और एक समय ऐसा लगा जैसे किसी PhD research project में enroll हो गया हूँ; फिर tab बंद करके मूल लेख पर लौट आया
HN के पाठक होशियार और technical होते हैं, लेकिन उनके क्षेत्र अलग-अलग हैं, इसलिए “NIST=बुरा” को support करने वाले jargon-heavy evidence का तार्किक मूल्यांकन करना कठिन है। मैं adjacent field में हूँ, इसलिए खुद को औसत पाठक से ज़्यादा समझने वाला मानता हूँ, लेकिन ठीक से पढ़े बिना फैसला करने का हक़दार महसूस नहीं करता। लेख context और acronyms समझाता है, पर मात्रा इतनी ज़्यादा है कि जो पहले से जानकार नहीं है, वह इसे पढ़ना चाहेगा भी या नहीं, पता नहीं। हर submission का सभी के लिए समझ में आना ज़रूरी नहीं, लेकिन इसमें आरोप हैं, इसलिए मुझे संदेह है कि यह HN के लिए उपयुक्त लेख है या नहीं
इसलिए नीचे कही बातों में से कुछ मैं वापस ले सकता हूँ, या कम से कम djb का NIST recommendations के साथ रहा इतिहास देखते हुए आक्रामक tone को ज़्यादा समझ सकता हूँ। संबंधित जानकारी https://en.wikipedia.org/wiki/Daniel_J._Bernstein#Cryptograp... पर है
मुझे रूप से ज़्यादा सामग्री को अत्यधिक महत्व देने की आदत पसंद नहीं है, लेकिन इस मामले में blog post का format इतना खराब था कि सामग्री मूल्यवान है या नहीं, इसका आकलन करना कठिन था। मैं cryptography field का व्यक्ति नहीं हूँ, इसलिए merits पर राय नहीं दे सकता, लेकिन अनावश्यक sarcasm और belittling ने message को बहुत संदिग्ध बना दिया। भले ही वह अच्छे बिंदु उठाता लगे, पूरी tone “WhaT ThE ElITe DoN'T WanT YoU TO KnoW!!” किस्म के YouTube video जैसी थी, और बात सही हो तब भी लेखक काफ़ी अप्रिय सुनाई देता है
यह भी जानना चाहूँगा कि क्या किसी ने इसे सचमुच अंत तक पढ़ा है। यह बात सही हो सकती है कि internet ने attention span मार दिया है, लेकिन उल्टा यह भी है कि अब information इतनी ज़्यादा है कि हम समय कहाँ लगाएँ, इसे लेकर बहुत सख़्त चुनाव करने पड़ते हैं। blog post हो तो relevant details और summary पहले कुछ paragraphs में होने चाहिए, और लंबी भटकती diary बाद में। अगर महत्वपूर्ण टुकड़े verbose diary में Where's Waldo की तरह छिपे हों, तो पूरा पढ़े जाने की उम्मीद करना मुश्किल है
उनका बार-बार पूछा गया मुख्य सवाल यह है कि evaluation criteria को बाद में लगातार क्यों बदला गया, results को misleading तरीके से क्यों पेश किया गया, और basic calculation errors क्यों हुए। ये लोग experts हैं, और ये सब चीज़ें एक algorithm के पक्ष में गईं
मेरी नज़र में यह संकेत है कि वे उस algorithm को standard बनाना चाहते थे। इसमें यह जोड़ दें कि NSA की involvement जितनी बताई गई थी उससे कहीं ज़्यादा थी और इसे छिपाने की कोशिश हुई, तो यह standard मुझे बेहद संदिग्ध लगता है
समस्या यह है कि ये algorithms जल्द ही hardware में built-in होने वाले हैं
जैसे ही standardize होने वाला implementation तय हो गया है, hardware vendors FIPS 203 standard को अधिक efficiently compute करने वाले blocks design करना शुरू कर सकते हैं। हो सकता है कुछ ने पहले ही design कर लिए हों
standard के 2024 में प्रकाशित होने की उम्मीद और FIPS modules की NIST CMVP review में 1–2 साल लगने को देखते हुए, 2026 के मध्य तक ML-KEM (Kyber आदि) वाले FIPS 140-3 hardware modules आ जाएँ तो हैरानी नहीं होगी
मुख्य बात [1] की यह पंक्ति लगती है: “लेकिन NIST ने स्पष्ट रूप से निर्दिष्ट (N,X) के लिए यह साफ़ end-to-end statement नहीं दिया कि Kyber-512 scenario X में N bits का security margin रखता है”
djb ने [2] में अपने कहे “scenario X” को संक्षेप में बताया है, और कहते हैं कि बस yes/no जवाब चाहिए। वे असल में उन लोगों से पूछ रहे हैं जिन्हें यह मुद्दा जानना चाहिए और जिनके पास इस पर चर्चा करने का technical background है। जवाब न मिलने के कारण उन्होंने [1] पोस्ट किया है
[3] में NIST का जवाब, सुरक्षा पर कोई चर्चा किए बिना [1] को खारिज कर देता है। खास तौर पर दूसरा पैराग्राफ परेशान करने वाला था। “जिस email का हवाला दिया गया है (https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/4MBu...) वह खुद अपनी बात कहता है। NIST अब भी इस पर लोगों की राय में रुचि रखता है कि Kyber512 को standardize करने की मौजूदा योजना अच्छी है या नहीं। समीक्षक, मज़े के लिए, NIST द्वारा सुरक्षा मार्जिन के बारे में किए जाते दिख रहे दावों का खंडन करने की कोशिश करने के लिए स्वतंत्र हैं, लेकिन उसके नतीजे standardization process के लिए खास तौर पर उपयोगी नहीं होंगे। NIST के पिछले दावे और उनकी व्याख्या इस बात से संबंधित नहीं हैं कि लोग Kyber512 को standardize करना अच्छा विचार मानते हैं या नहीं”
अगर NIST समीक्षकों के सुरक्षा-संबंधी दावों को “standardization process के लिए खास तौर पर उपयोगी नहीं” मानता है, तो यह देखते हुए कि वे समीक्षक cryptographers हैं, जनता को उस standard पर भरोसा क्यों करना चाहिए?
निर्णायक प्रमाण होना संभव ही नहीं है। क्योंकि अभी मुद्दा ही स्पष्ट explanation की कमी है। अगर यह समझाया जा सके कि Kyber-512 की सुरक्षा ताकत की गणना कैसे की गई, तो बात अलग होती।
फिलहाल third-party estimates के अनुसार Kyber-512 की security strength नाम की कुछ हद तक अस्पष्ट value मूल requirements से कम निकलती है, इसलिए स्पष्टीकरण या justification ज़रूरी लगता है।
[1]: https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/4MBu...
[2]: https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/4MBu...
[3]: https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/4MBu...
अगर यह किसी अनजान व्यक्ति की पोस्ट होती तो शायद मैं सहमत होता, लेकिन लेखक DJB या Tanja Lange हैं, और दोनों ही अनजान नहीं हैं।
ऐसी चीज़ें कुछ हद तक adversarial होना ही पड़ता है। Cryptanalysis के लिए कभी-कभी ऐसा रवैया ज़रूरी भी होता है, और इसलिए भी कि अतीत में कई संदिग्ध घटनाएं हुई हैं। यह field और politics का हिस्सा है, इसलिए इससे बचना मुश्किल है।
यह लेख से ज़्यादा डायरी जैसा है। इसमें technical jargon बहुत है, व्यवस्थित नहीं है, वही बातें घुमा-फिराकर आती हैं, और इसे follow करना बहुत मुश्किल है
फिर भी जानकारी अपने-आप में महत्वपूर्ण हो सकती है। इसमें यह मजबूत संकेत है कि NIST ने NSA की मदद से जानबूझकर एक कमजोर algorithm को standardize किया
हम सब जानते हैं कि ऐसा हो सकता है
बस अगर कोई इस क्षेत्र को ज़्यादा करीब से follow करता हो, तो उम्मीद है कि वह समझाए कि यहाँ के numbers का मतलब क्या है। मुझे हमेशा लगा है कि public-key crypto को इस तरह कमजोर करना एक जोखिम भरा दांव है, क्योंकि आप यह guarantee नहीं कर सकते कि कोई attacker स्वतंत्र रूप से वही बात नहीं खोज लेगा। कोई secret backdoor key छिपाई जा सकती है। Dual_EC_DRBG आने पर शक इसी तरह का था। लेकिन mathematical result सचमुच छिपाना मुश्किल होता है
उन्होंने यहाँ ऐसा जोखिम क्यों उठाना चाहा होगा
अब तो यह भी समझ नहीं आता कि ऐसी चर्चा की जरूरत क्यों है। हमें अब उनकी जरूरत नहीं है। export restrictions भी खत्म हो चुकी हैं
जरूरत एक ऐसे consortium की है जो hardware vendors का ध्यान खींचे, और NIST व NSA को सिर्फ participant की हैसियत तक सीमित रखे। तब अगर सरकार backdoored standards अपनाती भी है, तो वे बस खुद ही उन्हें इस्तेमाल करेंगे
उन्हें इसकी परवाह क्यों होगी
NIST elliptic curves में क्या हुआ होगा, इस बारे में अभी का अनुमान इसी तरफ है
अगर ऐसा है, तो यह बहुत लंबे समय तक effectively सिर्फ अमेरिका के लिए backdoor हो सकता है
उनका विचार था कि वे attacks में आगे रह सकते हैं, और जब तक 56-bit key आम तौर पर बहुत कमजोर हो जाए, तब तक DES की जगह कुछ और ले लेगा। क्या यह जोखिम भरा था? हाँ। लेकिन एक अर्थ में यह “कामयाब” रहा। इसलिए मैं यह मानकर नहीं चलूंगा कि ऐसा कुछ फिर कभी नहीं होगा
इसके पीछे की theory को kleptography कहा जाता है। इसका मतलब यह भी है कि NSA इतना भ्रमित है कि उसे लगता है वह जानकारी “सुरक्षित” तरीके से चुरा सकता है
पिछले साल इस पर 443 comments वाला एक related thread था
https://news.ycombinator.com/item?id=32360533 ("NSA, NIST, and post-quantum crypto: my second lawsuit against the US government (cr.yp.to)")
“NISTPQC के गुप्त कामकाज का पता लगाना। मार्च 2022 में ‘NSA, NIST, and post-quantum cryptography’ नाम से FOIA request डाली। NIST ने कानून तोड़ते हुए देरी की। civil-rights law firm Loevy & Loevy ने मेरी ओर से lawsuit file किया”
व्यक्तिगत रूप से मैं djb को आम तौर पर पसंद नहीं करता, लेकिन professionally वह federal government को अदालत में लगातार जवाबदेह ठहराते रहे हैं, इसलिए मैं हमेशा support करता हूँ। यह देखकर बहुत खुशी है कि वे अब भी लगे हुए हैं
DJB cryptography में एक महत्वपूर्ण व्यक्ति हैं, और मुझे यहाँ की कई details नहीं पता—इन बातों से अलग, एक जगह credibility काफी गिर गई
खासकर graph वाले हिस्से में वे कहते हैं कि “NIST ने bandwidth graph में कम emphasis देने के लिए पतली लाल bars इस्तेमाल करने का फैसला किया”, लेकिन उनके सबूत से यह बिल्कुल साबित नहीं होता। एक कहीं ज़्यादा plausible explanation है। जिन graphs में bars पतली हैं, वे दूसरे graph की तुलना में ज़्यादा data points वाले bar graphs हैं। कोई भी chart tool खोलकर 12 data points वाले graph की तुलना 9 data points वाले graph से करें, तो 12 वाले में lines पतली होना स्वाभाविक है। इस बिंदु पर मुझे बहुत strongly लगा कि वे हर action की जितनी हो सके उतनी malicious interpretation करना चाहते हैं
अगले item में वे शिकायत करते हैं कि values एक ही order of magnitude की range में होने के बावजूद log scale इस्तेमाल नहीं किया गया। यह log scale इस्तेमाल करने का अच्छा case नहीं लगता, और इस मामले में यह कैसे justified हो सकता है, मुझे साफ नहीं है
यह जानते हुए कि DJB NTRU से जुड़े थे, इस बात का एहसास हटाना मुश्किल है कि इसका काफी हिस्सा competition हारने पर खट्टा reaction है
कोई और assumption करना कम-से-कम मुझे तो काफी naive लगता है
शक करने की पर्याप्त वजह है
इस field के competitors का एक-दूसरे के काम की review करना स्वाभाविक है
cryptographers की जबरदस्त लड़ाइयों को professionally देखते हुए मैंने जो सीखा: Bernstein के खिलाफ bet मत लगाओ, और NIST पर भरोसा मत करो
NIST ने जवाब दिया है: https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/W2VO...
पक्का नहीं कि N(IST)SA में कोई trust बचा भी है या नहीं
curve25519 का उनकी P curves से ज़्यादा widely used होना encouraging है, और उम्मीद है community इसी direction में आगे बढ़ती रहेगी और भविष्य में उन्हें largely ignore करेगी
सरकार को lead या decide नहीं करना चाहिए। FIPS, regulations आदि में बेहतर होगा कि इन्हें current consensus इकट्ठा करने और follow करने की भूमिका के आसपास organize किया जाए