इस पेज पर, कुंजियों और प्राइमिटिव आउटपुट के लिए Tink के वायर फ़ॉर्मैट के बारे में बताया गया है. इस दस्तावेज़ का मकसद, क्रिप्टोग्राफ़र को Tink में अन्य भाषाएं जोड़ने में मदद करना है. साथ ही, यह उन हाई-लेवल क्रिप्टो लाइब्रेरी के मैनेजर के लिए भी है जिन्हें वायर के साथ काम करने वाला मोड चाहिए. इसे आम दर्शकों के लिए नहीं बनाया गया है.
पासकोड को क्रम से लगाना
Tink, अपने कीवर्ड को सीरियलाइज़ करने के लिए Google protobuf का इस्तेमाल करता है.
- बाइनरी में क्रम से लगाया गया पासकोड, क्रम से लगाया गया पासकोड प्रोटो है, जिसे tink.proto में बताया गया है. किसी कुंजी की KeyData वैल्यू प्रॉपर्टी, उस कुंजी टाइप का क्रम से लगाया गया प्रोटो है.
- JSON में क्रम से लगाया गया पासकोड, JSON फ़ॉर्मैट में क्रम से लगाया गया पासकोड प्रोटो है. ध्यान दें कि KeyData की वैल्यू अब भी बाइनरी सीरियलाइज़्ड प्रोटो है.
- एन्क्रिप्ट की गई कुंजी का सेट, EncryptedKeyset प्रोटो है, जिसे tink.proto में परिभाषित किया गया है. इसमें एन्क्रिप्ट किया गया बाइनरी सीरियलाइज़ किया गया पासकोड और वैकल्पिक रूप से, एन्क्रिप्ट नहीं किया गया KeysetInfo मेटाडेटा शामिल होता है.
Tink आउटपुट प्रीफ़िक्स
ज़्यादातर Tink प्राइमिटिव, पांच बाइट के आउटपुट प्रीफ़िक्स के साथ काम करते हैं. इसमें ये शामिल हैं:
- एक बाइट वाला वर्शन:
0x01
- चार बाइट की कुंजी का हिंट: यह इस्तेमाल की गई कुंजी का आईडी है.
कुछ लेगसी कुंजियां, वर्शन बाइट 0x00
के साथ भी काम कर सकती हैं.
ध्यान दें कि इस प्रीफ़िक्स की पुष्टि नहीं की गई है और सुरक्षा के मकसद से इस पर भरोसा नहीं किया जा सकता. Tink, डिक्रिप्ट करने या पुष्टि करने की प्रोसेस को तेज़ करने के लिए, इस जानकारी का इस्तेमाल एक हिंट के तौर पर करता है.
AEAD
आम तौर पर, Tink एईएडी सिफरटेक्स्ट को इस तरह फ़ॉर्मैट करता है:
prefix || IV || ciphertext || tag
जब तक उससे जुड़े आरएफ़सी में कुछ और न बताया गया हो. prefix
खाली है या फिर यह पांच बाइट का Tink आउटपुट प्रीफ़िक्स है.
AES-CTR-HMAC
AES-CTR-HMAC के लिए, Tink, संबंधित डेटा (AD) के साथ MAC का हिसाब इस तरह लगाता है:
AD || IV || ciphertext || bitlen(AD)
यहां bitlen(AD)
, एडी की लंबाई को बिट में दिखाता है. इसे 64-बिट बिग-एंडाइन के तौर पर दिखाया जाता है, जिसमें बिना साइन वाला पूर्णांक होता है. यह एचएमएसी स्कीम, Mcgrew के तौर पर एईएस-सीबीसी-एचएमएसी के ड्राफ़्ट का पालन करती है.
डिटरमिनिस्टिक एईएडी
Tink, AES-SIV के लिए RFC 5297 को लागू करता है. इसके लिए, वह सिफरटेक्स्ट की शुरुआत में सिंथेटिक शुरू करने वाला वेक्टर (SIV) डालता है. प्रिमिटिव, पांच बाइट का Tink आउटपुट प्रीफ़िक्स जोड़ सकता है.
आरएफ़सी 5297, जुड़े हुए डेटा की सूची के साथ काम करता है. हालांकि, Tink सिर्फ़ एक जुड़े हुए डेटा के साथ काम करता है. यह आरएफ़सी 5297 में मौजूद एक एलिमेंट वाली सूची से मेल खाता है. खाली डेटा से जुड़ी सूची में एक खाली एलिमेंट होता है, न कि खाली सूची.
स्ट्रीमिंग AEAD
AES-CTR HMAC और AES-GCM-HKDF देखें.
एन्वेलप एन्क्रिप्शन
एन्वलप एन्क्रिप्शन, डेटा एन्क्रिप्शन पासकोड DEK
का इस्तेमाल करके डेटा को एन्क्रिप्ट करता है. इसके लिए, Tink के एईएडी प्राइमिटिव का इस्तेमाल किया जाता है. एन्क्रिप्ट (सुरक्षित) करने की सुविधा इस तरह काम करती है:
- दिए गए पासकोड टेंप्लेट (या पासकोड पैरामीटर) का इस्तेमाल करके, एक नया
DEK
जनरेट किया जाता है. DEK
को बाइट स्ट्रिंग में सीरियलाइज़ किया जाता है. सीरियलाइज़ेशन फ़ॉर्मैट, प्रोटो टाइप प्रोटो के प्रोटोकॉल बफ़र सीरियलाइज़ेशन को फ़ॉर्मैट करता है. उदाहरण के लिए, यह एईएस GCM टाइप के डीईके के लिए, aes_gcm.proto में तय किया गया,AesGcmKey
प्रोटोकॉल बफ़र मैसेज है. प्रोटोकॉल बफ़र को सीरियलाइज़ करने का तरीका जानने के लिए, प्रोटोकॉल बफ़र को सीरियलाइज़ करना लेख पढ़ें.- सीरियल किए गए
DEK
को बाहरी सेवा देने वाली कंपनी (उदाहरण के लिए, GCP) से एन्क्रिप्ट (सुरक्षित) करके,encrypted DEK
में बदल दिया जाता है. DEK
का इस्तेमाल, उस डेटा के साथ सादा टेक्स्ट को एन्क्रिप्ट करने के लिए किया जाता है जोciphertext
में मौजूद है. इसलिए,ciphertext
का फ़ॉर्मैट,DEK
से जुड़े AEAD प्रिमिटिव जैसा ही होता है.
एन्वेलप एन्क्रिप्शन का आउटपुट फ़ॉर्मैट इस तरह का होता है:
encrypted DEK length || encrypted DEK || ciphertext
encrypted DEK length
चार बाइट का होता है. इसमें encrypted DEK
की लंबाई को 32-बिट बिग-एंडियन पूर्णांक के तौर पर सेव किया जाता है.
MAC
Tink, इन आरएफ़सी का पालन करता है. प्राइमिटिव, टैग में पांच बाइट का Tink आउटपुट प्रीफ़िक्स जोड़ सकते हैं.
पीआरएफ़ सेट
Tink, इन आरएफ़सी का पालन करता है. ध्यान दें कि पीआरएफ़ सेट के लिए, कुंजी का टाइप, उसी एल्गोरिदम के एमएसी कुंजी टाइप से अलग होता है. इसकी वजह यह है कि इसमें आउटपुट की लंबाई शामिल नहीं होती. PRF सेट की, कभी भी Tink आउटपुट प्रीफ़िक्स नहीं जोड़ती हैं. इससे यह पक्का होता है कि आउटपुट असल में एक पीआरएफ़ है.
हाइब्रिड एन्क्रिप्शन
Tink के हाइब्रिड एन्क्रिप्शन के लिए, वायर फ़ॉर्मैट सामान्य तौर पर यह होता है:
prefix || encapsulated_key || encrypted_data
prefix
खाली है या पांच बाइट का Tink आउटपुट प्रीफ़िक्स है. हर बटन टाइप में, यह जानकारी होती है कि कितने बाइट पार्स करने हैं और encapsulated_key
से उन बाइट को कैसे पार्स करना है.
HPKE (हाइब्रिड पब्लिक पासकोड एन्क्रिप्शन)
Tink, आरएफ़सी 9180 में बताए गए HPKE स्टैंडर्ड का पालन करता है. HPKE सिफरसूट में ये तीन प्राइमिटिव शामिल होते हैं.
- पासकोड को सुरक्षित करने का तरीका (केईएम)
- पासकोड बनाने वाला फ़ंक्शन (केडीएफ़)
- असोसिएटेड डेटा के साथ पुष्टि करने वाला एन्क्रिप्शन (एईएडी)
HPKE स्टैंडर्ड में, आरएफ़सी 9180, सेक्शन
10 में सामान्य वायर फ़ॉर्मैट की जानकारी नहीं दी गई है. Tink के HPKE लागू करने के तरीके में, इन encapsulated_key
और encrypted_data
वैल्यू का इस्तेमाल किया जाता है.
encapsulated_key
- भेजने वाले की सीरियलाइज़ की गई सार्वजनिक कुंजी
- आरएफ़सी 9180, सेक्शन 4.1 में इसे
enc
के तौर पर बताया गया है - फ़ॉर्मैट, इस्तेमाल किए गए खास HPKE KEM के हिसाब से तय होता है
encrypted_data
- एन्क्रिप्ट (सुरक्षित) किया गया टेक्स्ट और टैग (जैसे,
ciphertext || tag
के बिना) - आरएफ़सी 9180, सेक्शन 4 में इसे
ct
के तौर पर बताया गया है - फ़ॉर्मैट, इस्तेमाल किए गए खास HPKE AEAD के हिसाब से तय होता है
- एन्क्रिप्ट (सुरक्षित) किया गया टेक्स्ट और टैग (जैसे,
X25519 डिफ़ी-हेलमैन पर आधारित केएम
X25519 DHKEMs के लिए, वैल्यू enc
, भेजने वाले की 32-बाइट की डिफ़ी-हेलमैन सार्वजनिक कुंजी होती है.
ECIES-AEAD-HKDF
Tink के ECIES-AEAD-HKDF को लागू करने के लिए, encapsulated_key
, पासकोड को एन्क्रिप्ट करने के तरीके (KEM) का आउटपुट है और encrypted_data
, डेटा को एन्क्रिप्ट करने के तरीके (DEM) का आउटपुट है.
KEM
कुंजी के टाइप के आधार पर, Tink, आरएफ़सी 8422/ANSI.X9-62.2005
कोडिंग स्टैंडर्ड का पालन करते हुए, कॉम्प्रेस किए गए और अनकंप्रेस किए गए एलिप्टिक कर्व पॉइंट का इस्तेमाल करता है. बिना कंप्रेस किए गए पॉइंट के लिए, बाइट 0x04
के बाद x
और y
को तय साइज़ के पूर्णांक के तौर पर कोऑर्डिनेट किया जाता है. कंप्रेस किए गए निर्देशांक के लिए, बाइट 0x02
या 0x03
और x
निर्देशांक का इस्तेमाल, तय साइज़ के पूर्णांक के तौर पर किया जाता है. X25519
के लिए, आरएफ़सी 7748 की परिभाषा का इस्तेमाल किया जाता है (x
को तय साइज़ के पूर्णांक के तौर पर कोऑर्डिनेट किया जाता है).
DEM
encrypted_data
के लिए, Tink उसी फ़ॉर्मैट का इस्तेमाल करता है जो AEAD के लिए इस्तेमाल किया जाता है. इसमें, आईवी की जानकारी देना भी शामिल है.
कुंजी का डेरिवेशन
सबसे पहले, शेयर किए गए पॉइंट का x कॉर्डिनेट x_ss
कैलकुलेट किया जाता है. इसके बाद, एईएडी के लिए पासकोड इस पर सेट हो जाता है:
HKDF(ikm = encapsulated_key || x_ss, salt = salt_of_key, info = context_info, length = dem_key_size)
जहां encapsulated_key
, बाइट के तौर पर KEM का पूरा आउटपुट है.
डिजिटल हस्ताक्षर
Tink, इन आरएफ़सी का पालन करता है. प्राइमिटिव, जनरेट किए गए टैग में पांच बाइट का Tink आउटपुट प्रीफ़िक्स जोड़ सकते हैं.
ECDSA
पासकोड में मौजूद EcdsaSignatureEncoding फ़ील्ड के आधार पर, ECDSA हस्ताक्षर का फ़ॉर्मैट IEEE P1363
या ASN.1 DER
होता है.
IEEE P1363
हस्ताक्षर का फ़ॉर्मैट r || s
है. इसमें r
और s
को शून्य से पैड किया गया है. साथ ही, बाइट में इनका साइज़, कर्व के क्रम के बराबर होता है. उदाहरण के लिए, NIST P-256
कर्व के लिए, r
और s
को 32 बाइट तक शून्य से पैड किया जाता है.
DER सिग्नेचर को ASN.1
का इस्तेमाल करके कोड में बदला जाता है:
ECDSA-Sig-Value :: = SEQUENCE { r INTEGER, s INTEGER }
खास तौर पर, एन्कोडिंग:
0x30 || totalLength || 0x02 || r's length || r || 0x02 || s's length || s
Tink, हस्ताक्षर की पुष्टि करने के सबसे सही तरीकों का पालन करता है. इसके लिए, वह सिर्फ़ DER कोड में एन्क्रिप्ट किए गए ECDSA हस्ताक्षर स्वीकार करता है. BER कोड में एन्क्रिप्ट किए गए अन्य हस्ताक्षर अमान्य होते हैं.
इससे, हस्ताक्षर में बदलाव करने से जुड़े हमलों को रोकने में मदद मिलती है. ये हमले अक्सर क्रिप्टो करंसी सिस्टम पर असर डालते हैं.