👩‍👦 🙋 🧖🏼 GOST R 34.11-2012 हैश फ़ंक्शन के ओपन-सोर्स कार्यान्वयन और GOST R.10.102 के इलेक्ट्रॉनिक हस्ताक्षर पर उनके प्रभाव के बारे में 🧝🏼 👨‍👨‍👧‍👦 👰🏾

एक समय में, libgcrypt लाइब्रेरी में घरेलू क्रिप्टोग्राफ़िक एल्गोरिदम के कार्यान्वयन ने मुझे बहुत प्रेरित किया। GOST इंजन के साथ खुलने के विकल्प के रूप में libgcrypt लाइब्रेरी पर विचार करने के लिए क्लियोपेट्रा और सामान्य रूप से Kmail और GnuPg में इन एल्गोरिदम का उपयोग करना संभव हो गया। और पिछले शुक्रवार तक सब कुछ बहुत अच्छा था।

मुझे MS Windows पर Microsoft Office में बनाए गए दस्तावेज़ के लिए GOST R 34.10-2012-256 के इलेक्ट्रॉनिक हस्ताक्षर को सत्यापित करने के लिए कहा गया था। और मैंने इसे क्लियोपेट्रा (मेरे पास लिनक्स है) में जांचने का फैसला किया। और आपको क्या लगता है, हस्ताक्षर गलत निकला। संदेह में दरार। मैंने GOST इंजन के साथ खुलने पर जांच करने का निर्णय लिया। हस्ताक्षर सफलतापूर्वक सत्यापित किया गया है। तत्काल क्लियोपेट्रा में फ़ाइल पर फिर से हस्ताक्षर किए और इसने एमएस विंडोज पर चेक पास नहीं किया। हमने अन्य फ़ाइलों पर हस्ताक्षर करने और सत्यापित करने की कोशिश की, सब कुछ ठीक था। सवाल यह था कि परेशानी क्या थी? चूंकि दस्तावेज़ का हैश हस्ताक्षर करने में शामिल है, इसलिए विभिन्न कार्यक्रमों द्वारा हैश की गणना की जाँच करने का निर्णय लिया गया। सबसे पहले, स्ट्रोग के लिए ओपन-सोर्स कार्यान्वयन शामिल थे :

और फिर एक झटका लगा! हैश की गणना "प्रसिद्ध डिग्टिएरेव कार्यान्वयन" द्वारा की गई है, जो कि एंडी के GOST के साथ ओपनसेल में गणना की गई हैश के साथ है, लेकिन लिबगक्रिप्ट और लिब्रेसल का उपयोग करके गणना की गई हैश मूल्य से मेल नहीं खाती है।

जब वह अपने लेख की शुरुआत में लिखा था, तो ru_crypt सही था:

मैं आपको तुरंत चेतावनी देता हूं कि मैंने कार्यान्वयन की शुद्धता की जांच नहीं की है।

वैसे, GOST R 34.10-2012 पर मानक यह भी कहते हैं कि नियंत्रण उदाहरण केवल संदर्भ के लिए हैं। यह स्पष्ट रूप से समझना चाहिए कि परीक्षण मामलों की गारंटी नहीं है कि विभिन्न कार्यान्वयन सभी अवसरों के लिए एक ही परिणाम देते हैं।

हैश मानों की गणना करने के लिए, निम्नलिखित उपयोगिताओं का उपयोग किया गया था:

1) खुलता है

$ openssl dgst [–md_gost12_256|-md_gost12_512] <file>

२) कामवासना

 $libressl dgst [–streebog256|streebog512] <file>

3) libgcrypt

 $gchash [stribog256|stribog512] <file>

४) डिग्ट्येरेव का प्रसिद्ध कार्यान्वयन

 $gost3411-2012 [-2|-5] <file>

यहाँ एक दिलचस्प बात यह भी है: लैटिन ट्रांसक्रिप्शन में, स्ट्रीबोग या तो स्ट्रीबोग या स्ट्रीबॉग लिखते हैं। एकरूपता में आना अच्छा होगा। और इसलिए ऐसा लगता है कि ये अलग-अलग कार्य हैं। व्यक्तिगत रूप से, मैं पहला विकल्प पसंद करता हूं - स्ट्रीबोग।

मुझे एक मध्यस्थ की जरूरत थी।

मध्यस्थ के रूप में, PKCS # 11 टोकन रॉटोकन ईडीएस-2.0 का उपयोग करने का निर्णय लिया गया, जो रूसी क्रिप्टोग्राफिक मानकों का समर्थन करता है GOST R 34.10-2012, GOST R 34.11-2012, VKO GOST 34.10-2012 (RFC 7836) 256 और 512 बिट्स की प्रमुख लंबाई के साथ , और क्रिप्टोग्राफिक सूचना संरक्षण (CPSI) और इलेक्ट्रॉनिक हस्ताक्षर के साधन के रूप में रूस के FSB द्वारा प्रमाणित है।

इसके अलावा, RUTOKEN EDS-2.0 टोकन व्यापक रूप से वितरित किया जाता है और राज्य सेवाओं और अन्य पोर्टलों तक पहुंच के लिए इस पर कई स्टोर प्रमाण पत्र ।
टोकन पर हैश मान की गणना करने के लिए, हम Tcl में test_digest.tcl स्क्रिप्ट का उपयोग करेंगे:

test_digest.tcl

 #! /usr/bin/env tclsh package require pki lappend auto_path . package require pki::pkcs11 #     PKCS#11 set pkcs11_module "/usr/local/lib64/librtpkcs11ecp_2.0.so" #set pkcs11_module "/usr/local/lib64/libls11sw2016.so" puts "Connect the Token and press Enter" gets stdin yes set handle [pki::pkcs11::loadmodule $pkcs11_module] set slots [pki::pkcs11::listslots $handle] foreach slotinfo $slots { set slotid [lindex $slotinfo 0] set slotlabel [lindex $slotinfo 1] set slotflags [lindex $slotinfo 2] if {[lsearch -exact $slotflags TOKEN_PRESENT] != -1} { set token_slotlabel $slotlabel set token_slotid $slotid #    break } } proc usage {use error} { puts "Copyright(C) Orlov Vladimir (http://soft.lissi.ru) 2019" if {$use == 1} { puts $error puts "Usage:\ndigest <stribog256|stribog512> <file for digest>\n" } } set countcert [llength $argv] if { $countcert != 2 } { usage 1 "Bad usage!" exit } set digest_algo [lindex $argv 0] if {$digest_algo != "stribog256" && $digest_algo != "stribog512"} { usage 1 "Bad usage!" exit } set file [lindex $argv 1] if {![file exists $file]} { usage 1 "File $file not exist" exit } puts "Loading file for digest: $file" set fd [open $file] chan configure $fd -translation binary set cert_user [read $fd] close $fd if {$cert_user == "" } { usage 1 "Bad file: $file" exit } set aa [dict create pkcs11_handle $handle pkcs11_slotid $token_slotid] set digest_hex [pki::pkcs11::digest $digest_algo $cert_user $aa] puts "digest_hex=\n$digest_hex" exit

कार्यान्वयन में यह विसंगति कब दिखाई देती है? अब तक, यह निर्धारित करना संभव है कि यह विसंगति एमएस ऑफिस में बनाई गई डॉक्टर फ़ाइलों के हैश की गणना करते समय होती है। इसके अलावा, पहले 143 बाइट्स के हैश को समान माना जाता है, और 144 बाइट्स से हैश की गणना करते समय, मान अलग-अलग होते हैं।

हेक्साडेसिमल में पहले 143 बाइट इस तरह दिखते हैं:

 d0cf11e0a1b11ae1000000000000000000000000000000003e000300feff0900060000000000000000000000010000000100000000000000001000002400000001000000feffffff0000000000000000ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff

उन्हें Doc1_143_hex.txt फ़ाइल में सहेजें।

हेक्साडेसिमल में पहले 144 बाइट्स इस तरह दिखते हैं:

 d0cf11e0a1b11ae1000000000000000000000000000000003e000300feff0900060000000000000000000000010000000100000000000000001000002400000001000000feffffff0000000000000000ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff

उन्हें Doc1_144_hex.txt फ़ाइल में सहेजें।

हेक्साडेसिमल से बाइनरी फॉर्म में अनुवाद करने के लिए हेक्स 2बीन.टीक स्क्रिप्ट का उपयोग करना सुविधाजनक है:

 #!/usr/bin/tclsh proc usage {use error} { if {$use == 1} { puts $error puts "Usage:\nhex2bin <file with hex> <file for bin>\n" } } set countcert [llength $argv] if { $countcert != 2 } { usage 1 "Bad usage!" exit } set file [lindex $argv 0] if {![file exists $file]} { usage 1 "File $file not exist" exit } set fd [open $file] chan configure $fd -translation binary set cert_user [read $fd] close $fd if {$cert_user == "" } { usage 1 "Bad file with hex: $file" exit } set cert_user [binary format H* $cert_user] set fd [open [lindex $argv 1] w] chan configure $fd -translation binary puts -nonewline $fd $cert_user close $fd

हेक्साडेसिमल कोड को बाइनरी में बदलें:

 $./hex2bin Doc1_143_hex.txt Doc1_143.bin $./hex2bin Doc1_144_hex.txt Doc1_144.bin $

अब आप जाँच सकते हैं कि हैश की गणना विभिन्न कार्यान्वयनों द्वारा कैसे की जाती है:
सबसे पहले, Doc1_143, बिन के लिए हैश पर विचार करें:

 $ ./openssl dgst -md_gost12_256 Doc1_143.bin md_gost12_256(Doc1_143.bin)= e63bd3edc44f9a03fece4198b690a8ae291b973ae61b2a0f512a9a7479431a63 $ ./libressl dgst -streebog256 Doc1_143.bin streebog256(Doc1_143.bin)= e63bd3edc44f9a03fece4198b690a8ae291b973ae61b2a0f512a9a7479431a63 $ ./gchash stribog256 Doc1_143.bin e63bd3edc44f9a03fece4198b690a8ae291b973ae61b2a0f512a9a7479431a63 Doc1_143.bin $ ./gost3411-2012 -2 Doc1_143.bin GOST R 34.11-2012 (Doc1_143.bin) = e63bd3edc44f9a03fece4198b690a8ae291b973ae61b2a0f512a9a7479431a63 $

सबसे महत्वपूर्ण क्षण आ गया है, एक प्रमाणित क्रिप्टोग्राफिक सूचना सुरक्षा प्रणाली पर सत्यापन का क्षण:

 $ ./test_digest.tcl stribog256 Doc1_143.bin Connect the Token and press Enter Loading file for digest: Doc1_143.bin digest_hex= e63bd3edc44f9a03fece4198b690a8ae291b973ae61b2a0f512a9a7479431a63 $

जैसा कि आप देख सकते हैं, अच्छे के लिए सब कुछ समाप्त हो गया।

आइए देखें कि Doc1_144.bin फ़ाइल के लिए क्या होता है:

 $ ./openssl dgst -md_gost12_256 Doc1_144.bin md_gost12_256(Doc1_144.bin)= c766085540caaa8953bfcf7a1ba220619cee50d65dc242f82f23ba4b180b18e0 $ ./libressl dgst -streebog256 Doc1_144.bin streebog256(Doc1_144.bin)= 3965c99777eb1b64c783496fe950aa6540bc7baa399a3889995145afbdd76250 $

यही है, हैश के मूल्य मेल नहीं खाते हैं। प्रयोग की शुद्धता के लिए, हम शेष कार्यान्वयन की जाँच करते हैं:

 $ ./gchash_1.7.10 stribog256 Doc1_144.bin 3965c99777eb1b64c783496fe950aa6540bc7baa399a3889995145afbdd76250 Doc1_144.bin $ ./gost3411-2012 -2 Doc1_144.bin GOST R 34.11-2012 (Doc1_144.bin) = c766085540caaa8953bfcf7a1ba220619cee50d65dc242f82f23ba4b180b18e0 $ ./test_digest.tcl stribog256 Doc1_144.bin Connect the Token and press Enter Loading file for digest: Doc1_144.bin digest_hex= c766085540caaa8953bfcf7a1ba220619cee50d65dc242f82f23ba4b180b18e0 $

हैश की गणना "प्रसिद्ध डिग्टेयरव इम्प्लीमेंटेशन" द्वारा की गई हैश की गणना GOST इंजन के साथ ओपनसेल में की गई है, लेकिन यह लिबासक्रिप्ट और लिब्रेसल का उपयोग करके गणना किए गए हैश मान से मेल नहीं खाता है।

यदि हम हैश stribog512 पर विचार करते हैं तो हमें एक समान परिणाम मिलता है।

एक निष्कर्ष है। यदि आप चाहते हैं कि GOST R 34.10-2012 लिब्रेसल और लिबगक्रिप्ट (या शायद अन्य) द्वारा निर्मित इलेक्ट्रॉनिक हस्ताक्षर, रूस के FSB प्रमाणन प्रणाली में प्रमाणित क्रिप्टोग्राफिक सूचना सुरक्षा के साथ, Opensl के साथ संगत होना चाहिए और, सत्यापित करें कंप्यूटिंग हैश के लिए कार्यान्वयन। मुझे उम्मीद है कि यह प्रकाशन कई गलतफहमियों से बचा जाता है, और लिबरल, लिबग्रिप्ट, और संभवत: अन्य लोगों में स्ट्रिबॉग के कार्यान्वयन के लेखक इन विसंगतियों को खत्म करने में मदद करेंगे। आज, मुझे उपरोक्त उत्पादों में स्वीकार करना चाहिए, यह वास्तव में GOST R 34.10-2012 नहीं है जिसे लागू किया गया है, लेकिन कुछ और। यह एक अलग एल्गोरिथ्म है। दिए गए परीक्षण उदाहरण संभवतः GOST R 34.10-2012 के लिए परीक्षण उदाहरण के रूप में शामिल करना अच्छा होगा। और मैं क्लियोपेट्रा और केमेल के लिए libgcrypt को संपादित करने जा रहा हूं। क्लियोपार्ट और रूसी क्रिप्टोग्राफी की कथा अधूरी थी।

पुनश्च लेख पहले से ही तैयार था जब मेरे सहयोगी ने कहा कि कार्यान्वयन के बीच विसंगति तब दिखाई देती है जब 0xFF का पर्याप्त लंबा अनुक्रम सामने आता है। वह, यह क्रम, एमएस ऑफिस की डॉक फाइलों की शुरुआत में मौजूद है। मैंने जाँच की, जिस तरह से यह है। फ़ाइल में 189 बाइट्स थे।

GOST R 34.11-2012 हैश फ़ंक्शन के ओपन-सोर्स कार्यान्वयन और GOST R.10.102 के इलेक्ट्रॉनिक हस्ताक्षर पर उनके प्रभाव के बारे में

More articles: