में मैं एक वेब एप्लिकेशन पर काम कर रहा हूं जो सर्वर पक्ष पर ईसीसी के साथ डेटा एन्क्रिप्ट करने और ब्राउज़र में डिक्रिप्ट करने में सक्षम होना चाहिए। जेएस में यह सक्षम एकमात्र लाइब्रेरी है जो एसजेसीएल है। हालांकि, चूंकि एसजेसीएल में ईसीसी समर्थन इस समय थोड़ा सा त्याग दिया गया है, इसलिए मैंने fork का उपयोग किया है, जिसमें कुंजी धारावाहिक समर्थन और demo आसान समझ के लिए है।जेएस में एसजेसीएल के साथ एल्लिप्टिक वक्र क्रिप्टोग्राफी रूबी
पहले, मैं जे एस में एक ईसीसी कुंजी युग्म उत्पन्न:
{"point":[1110230655,241884220,775655552,-849225963,-883815628,-1984298210,-736346431,1387519594,-1810604283,-1235638489,1333314084,-1219216530,614640565,-1148742381,1038670260,1013716131,758346573,1162278003,1232401864,-1948620456,533899535,-1478577959,1853846180,-1553049184],"curve":384}
तो मैं एक प्रारूप OpenSSL द्वारा समझा जा सकता करने के लिए यह सार्वजनिक कुंजी परिवर्तित करने के लिए प्रयास किया है:
keypair = sjcl.ecc.elGamal.generateKeys(384, 10);
document.writeln(JSON.stringify(keypair.pub.serialize()));
कुछ इस तरह आउटपुट।
ar = [1110230655,241884220,775655552,-849225963,-883815628,-1984298210,-736346431,1387519594,-1810604283,-1235638489,1333314084,-1219216530,614640565,-1148742381,1038670260,1013716131,758346573,1162278003,1232401864,-1948620456,533899535,-1478577959,1853846180,-1553049184]
# ugly bit magic to somehow convert the above array into a proper byte array (in form of a string)
kstr = [(ar.map { |i| (i>=0)?('0'*(8-i.to_s(16).length)+i.to_s(16)):("%08X" % (2**32-1+i+1)) }*'').upcase].pack("H*")
# opening a public key generated with the openssl cli tool showed a structure like this:
algokey = OpenSSL::ASN1::ObjectId 'id-ecPublicKey'
algovalue = OpenSSL::ASN1::ObjectId 'secp384r1'
algo = OpenSSL::ASN1::Sequence.new [algokey,algovalue]
# for some reason OpenSSL seems to prepend 0x04 to all public keys
key = OpenSSL::ASN1::BitString.new "\x04#{kstr}"
root = OpenSSL::ASN1::Sequence.new [algo,key]
pub = OpenSSL::PKey.read(root.to_der)
इस बिंदु तक, मेरा कोड ठीक काम करता है। यही है, यह किसी भी अपवाद का उत्पादन नहीं करता है।
हालांकि, दोनों पुस्तकालयों के साथ साझा रहस्य उत्पन्न करते समय, मैंने पाया कि एसजेसीएल ने 'टैग' उत्पन्न किया जो 9 6 बाइट लंबा था, जबकि ओपनएसएसएल ने 48 बाइट उत्सर्जित किए थे।
मेरी समस्या यह है कि एसजेसीएल सादे ईसीडीएच का उपयोग नहीं करता है। यह ऐसा कुछ उपयोग करता है जो एक त्वरित Google खोज के आधार पर ईसीएमक्यूवी लगता है। इसलिए, 'टैग' एसजेसीएल आउटपुट वक्र (x और y बिंदुओं, 2 * 48 बाइट्स के निर्देशांक) पर एक बिंदु था, जबकि ओपनएसएसएल आउटपुट एक साझा रहस्य था (ईसीडीएच द्वारा निर्धारित बिंदु के एक्स समन्वय)।
मेरी समस्या यह है कि मुझे नहीं पता कि ओपनएसएसएल में ईसीएमक्यूवी के लिए कोई समर्थन है या नहीं (कुछ पेटेंट समस्याएं हैं, अगर मैं सही हूं)। यहां तक कि अगर वहां था, रूबी बाध्यकारी इसका समर्थन नहीं करता है।
तो मेरी वास्तविक सवाल:
- मेरी निष्कर्ष सही ऊपर प्रलेखित रहे हैं?
- यदि हां, तो क्या कोई भी अन्य रूबी लाइब्रेरी जानता है जिसे मैं ओपनएसएसएल के बजाय उपयोग कर सकता हूं, जो ईसीएमक्यूवी का समर्थन करता है?
लिख सकते हैं क्यों नहीं SJCL की devs पूछना? क्या आप जानते हैं कि ब्राउजर में क्रिप्टो का उपयोग करने वाली अधिकांश योजनाएं (एसएसएल/टीएलएस लागू किए बिना) असुरक्षित हैं? –
ठीक है, ऐसा लगता है कि देवों को अब व्यर्थ है। :) और असुरक्षित होने के बारे में: मुझे इसके बारे में पता है, मैं गरीब आदमी के एसएसएल को लागू करने की कोशिश नहीं कर रहा हूं। यह घुसपैठियों से सर्वर डेटा समझौता करने से उपयोगकर्ता डेटा की सुरक्षा के बारे में है। बेशक एक घुसपैठिया सर्वर पर जेएस कोड को AJAX या कुछ के माध्यम से गुप्त कुंजी पासफ्रेज भेजने के लिए संशोधित कर सकता है, लेकिन यह एक अलग कहानी है। – gsx1022
मुझे नहीं पता कि यह एक अलग कहानी है, यह आपके सुरक्षा मॉडल पर एक हमला परिदृश्य है। लेकिन यदि आप उपयोगकर्ता को स्थानीय डेटा ब्राउज़र में रखते हैं, तो यह वास्तव में मामले में सुरक्षा जोड़ सकता है। उपयोगकर्ता डेटा धारण करने वाला डेटा कंटेनर चोरी हो जाता है। –