प्रेरणा
कुछ लोग EdDSA या RedDSA पसंद नहीं करते हैं। हमें कुछ विकल्प पेश करने चाहिये और उन्हें ECDSA हस्ताक्षर ब्लाइंड करने देना चाहिए।
अवलोकन
यह प्रस्ताव ECDSA हस्ताक्षर प्रकार 1, 2, 3 के लिए कुंजी ब्लाइंडिंग का वर्णन करता है।
प्रस्ताव
यह RedDSA के समान तरीके से काम करता है, लेकिन सब कुछ बिग एंडियन में है। केवल समान हस्ताक्षर प्रकारों की अनुमति है, जैसे 1->1, 2->2, 3->3।
परिभाषाएँ
B वक्र का आधार बिंदु
L अंडाकार वक्र का समूह क्रम। वक्र की संपत्ति।
DERIVE_PUBLIC(a) निजी कुंजी को सार्वजनिक में बदलें, एक अंडाकार वक्र पर B को गुणा करके
alpha एक 32-बाइट रैंडम नंबर जो उन लोगों को ज्ञात होता है जो गंतव्य को जानते हैं।
GENERATE_ALPHA(destination, date, secret) वर्तमान तिथि के लिए अल्फा उत्पन्न करें, उन लोगों के लिए जो गंतव्य और गुप्त को जानते हैं।
a गंतव्य को हस्ताक्षरित करने के लिए प्रयुक्त अविश्वस्त 32-बाइट साइनिंग निजी कुंजी
A गंतव्य में अविश्वस्त 32-बाइट साइनिंग सार्वजनिक कुंजी, = DERIVE_PUBLIC(a), जैसा कि संबंधित वक्र में
a' एन्क्रिप्टेड लीजसेट को हस्ताक्षरित करने के लिए प्रयुक्त अंधी 32-बाइट साइनिंग निजी कुंजी यह एक वैध ECDSA निजी कुंजी है।
A' गंतव्य में अंधी 32-बाइट ECDSA साइनिंग सार्वजनिक कुंजी, DERIVE_PUBLIC(a’) के साथ उत्पन्न की जा सकती है, या A और alpha से। यह वक्र पर एक वैध ECDSA सार्वजनिक कुंजी है
H(p, d) SHA-256 हैश फ़ंक्शन जो एक वैयक्तिकरण स्ट्रिंग p और डेटा d लेता है, और 32 बाइट की लंबाई का आउटपुट उत्पन्न करता है।
SHA-256 का उपयोग निम्न रूप में करें::
H(p, d) := SHA-256(p || d)
HKDF(salt, ikm, info, n) एक क्रिप्टोग्राफ़िक कुंजी व्युत्पत्ति फ़ंक्शन जो कुछ इनपुट कुंजी सामग्री ikm लेता है (जिसमें अच्छी एंट्रोपी होनी चाहिए लेकिन इसे एक समान रूप से रैंडम स्ट्रिंग होने की आवश्यकता नहीं है), एक नमक 32 बाइट की लंबाई का, और एक संदर्भ-विशिष्ट ‘info’ मान, और एक आउटपुट उत्पन्न करता है n बाइट की जो कुंजी सामग्री के रूप में उपयोग के लिए उपयुक्त है।
[RFC-5869](https://tools.ietf.org/html/rfc5869) में निर्दिष्ट के अनुसार, HMAC हैश फ़ंक्शन SHA-256 का उपयोग करें
जैसा कि [RFC-2104](https://tools.ietf.org/html/rfc2104) में निर्दिष्ट किया गया है। इसका मतलब है कि SALT_LEN अधिकतम 32 बाइट है।
ब्लाइंडिंग गणनाएँ
एक नया गुप्त अल्फा और ब्लाइंड की जाने वाली कुंजियाँ प्रत्येक दिन (UTC) उत्पन्न की जानी चाहिए। गुप्त अल्फा और ब्लाइंड की जाने वाली कुंजियाँ निम्नलिखित के रूप में गणना की जाती हैं।
GENERATE_ALPHA(destination, date, secret), सभी पार्टियों के लिए:
// GENERATE_ALPHA(destination, date, secret)
// गुप्त वैकल्पिक है, अन्यथा शून्य-लम्बाई
A = गंतव्य की साइनिंग सार्वजनिक कुंजी
stA = A का हस्ताक्षर प्रकार, 2 बाइट बिग एंडियन (0x0001, 0x0002 या 0x0003)
stA' = ब्लाइंड की गई सार्वजनिक कुंजी A' का हस्ताक्षर प्रकार, 2 बाइट बिग एंडियन, हमेशा stA के समान
keydata = A || stA || stA'
datestring = 8 बाइट ASCII YYYYMMDD वर्तमान तिथि UTC से
secret = UTF-8 एन्कोडेड स्ट्रिंग
seed = HKDF(H("I2PGenerateAlpha", keydata), datestring || secret, "i2pblinding1", 64)
// seed को एक 64 बाइट बिग एंडियन मूल्य के रूप में मानें
alpha = seed mod L
BLIND_PRIVKEY(), लीजसेट प्रकाशित करने वाले मालिक के लिए:
// BLIND_PRIVKEY()
alpha = GENERATE_ALPHA(destination, date, secret)
a = गंतव्य की साइनिंग निजी कुंजी
// स्केलर अंकगणित का उपयोग करके जोड़
ब्लाइंड की गई साइनिंग निजी कुंजी = a' = BLIND_PRIVKEY(a, alpha) = (a + alpha) mod L
ब्लाइंड की गई साइनिंग सार्वजनिक कुंजी = A' = DERIVE_PUBLIC(a')
BLIND_PUBKEY(), लीजसेट पुनः प्राप्त करने वाले ग्राहकों के लिए:
// BLIND_PUBKEY()
alpha = GENERATE_ALPHA(destination, date, secret)
A = गंतव्य की साइनिंग सार्वजनिक कुंजी
// समूह तत्वों का उपयोग कर जोड़ (वक्र पर बिंदु)
ब्लाइंड की गई सार्वजनिक कुंजी = A' = BLIND_PUBKEY(A, alpha) = A + DERIVE_PUBLIC(alpha)
A’ की गणना के दोनों तरीके, आवश्यकतानुसार, समान परिणाम देते हैं।
b33 पता
ECDSA की सार्वजनिक कुंजी (X,Y) जोड़ी है, इसलिए P256 के लिए, उदाहरण के लिए, यह 64 बाइट है, बजाय 32 के जैसा कि RedDSA के लिए है। या तो b33 पता लंबा होगा, या सार्वजनिक कुंजी को बिटकॉइन वॉलेट्स की तरह संकुचित प्रारूप में संग्रहीत किया जा सकता है।