AES-GCM-HKDF स्ट्रीमिंग AEAD

यह दस्तावेज़ औपचारिक रूप से गणित के उस फ़ंक्शन के बारे में बताता है जिसे AES-GCM-HKDF स्ट्रीमिंग कुंजियों से दिखाया जाता है. इसे प्रोटो फ़ॉर्मैट में type.googleapis.com/google.crypto.tink.AesGcmHkdfStreamingKey के तौर पर एन्कोड किया जाता है.

एन्क्रिप्ट (सुरक्षित) करने का यह तरीका, आम तौर पर HRRV15¹ पर आधारित होता है. सुरक्षा विश्लेषण के लिए, हम HS20² देखें.

कुंजी और पैरामीटर

कुंजियों के बारे में नीचे बताए गए तरीके से बताया गया है (इस दस्तावेज़ में सभी साइज़ बाइट में हैं):

• \(\mathrm{KeyValue}\), एक बाइट स्ट्रिंग.
• \(\mathrm{CiphertextSegmentSize} \in \{1, 2, \ldots, 2^{31}-1\}\).
• \(\mathrm{DerivedKeySize} \in \{16, 32\}\).
• \(\mathrm{HkdfHashType} \in \{\mathrm{SHA1}, \mathrm{SHA256}, \mathrm{SHA512}\}\).

मान्य पासकोड, इन प्रॉपर्टी के लिए भी काम करते हैं:

• \(\mathrm{len}(\mathrm{KeyValue}) \geq \mathrm{DerivedKeySize}\).
• \(\mathrm{CiphertextSegmentSize} > \mathrm{DerivedKeySize} + 24\) (यह इसके बराबर है \(\mathrm{len}(\mathrm{Header}) + 16\) जैसा कि बाद में बताया गया है).

इनमें से किसी भी प्रॉपर्टी का उल्लंघन करने वाली कुंजियों को Tink मंज़ूरी मिलने पर अस्वीकार कर दिया जाता है. ऐसा, कुंजी को पार्स किए जाने या उससे जुड़े प्रिमिटिव बनाए जाने पर किया जाता है.

एन्क्रिप्ट (सुरक्षित) करने का फ़ंक्शन

मैसेज को एन्क्रिप्ट (सुरक्षित) करने के लिए, \(\mathrm{Msg}\) इससे जुड़े डेटा \(\mathrm{AssociatedData}\)का इस्तेमाल किया जाता है. इसके लिए, हम हेडर बनाते हैं, मैसेज को सेगमेंट में बांटते हैं, हर सेगमेंट को एन्क्रिप्ट करते हैं, और एन्क्रिप्ट (सुरक्षित) किए गए सेगमेंट को जोड़ते हैं.

हेडर बनाना

हम \(\mathrm{Salt}\) एक जैसी रैंडम स्ट्रिंग \(\mathrm{DerivedKeySize}\) और एक जैसी रैंडम स्ट्रिंग \(\mathrm{NoncePrefix}\) 7 लंबाई वाली स्ट्रिंग चुनते हैं.

इसके बाद, हम \(\mathrm{Header} := \mathrm{len}(\mathrm{Header}) \| \mathrm{Salt} \| \mathrm{NoncePrefix}\)सेट करते हैं, जहां हेडर की लंबाई को एक बाइट के तौर पर कोड में बदला जाता है. ध्यान दें कि \(\mathrm{len}(\mathrm{Header}) \in \{24, 40\}\).

इसके बाद, हम HKDF³ का इस्तेमाल,आउटपुट की लंबाई के साथ \(\mathrm{HkdfHashType}\)और इनपुट \(\mathrm{ikm} := \mathrm{KeyValue}\), \(\mathrm{salt} := \mathrm{Salt}\), और \(\mathrm{info} := \mathrm{AssociatedData}\)से मिले हैश फ़ंक्शन के साथ करते हैं \(\mathrm{DerivedKeySize}\). हम नतीजे को \(\mathrm{DerivedKey}\)कहते हैं.

मैसेज को स्प्लिट करें

इसके बाद, मैसेज \(\mathrm{Msg}\) को इन हिस्सों में बांटा जाएगा: \(\mathrm{Msg} = M_0 \| M_1 \| \cdots \| M_{n-1}\).

उनकी अवधि इन शर्तों को पूरा करने के लिए चुनी जाती है:

• \(\mathrm{len}(M_0) \in \{0,\ldots, \mathrm{CiphertextSegmentSize} - \mathrm{len}(\mathrm{Header}) - \mathrm{16}\}\).
• अगर \(n>1\), तो \(\mathrm{len}(M_1), \ldots, \mathrm{len}(M_{n-1}) \in \{1,\ldots, \mathrm{CiphertextSegmentSize} - \mathrm{16}\}\).
• अगर \(n>1\)है, तो \(\mathrm{len}(M_{0}), \ldots, \mathrm{len}(M_{n-2})\) की लंबाई ऊपर दी गई शर्तों के मुताबिक ज़्यादा से ज़्यादा होनी चाहिए.

\(n\) ज़्यादा से ज़्यादा \(2^{32}\)हो सकते हैं. ऐसा न करने पर, एन्क्रिप्ट (सुरक्षित) करने की सुविधा काम नहीं करती.

ब्लॉक एन्क्रिप्ट करें

सेगमेंट को एन्क्रिप्ट (सुरक्षित) करने के लिए \(M_i\), हम \(\mathrm{IV}_i := \mathrm{NoncePrefix} \| \mathrm{i} \| b\)का हिसाब लगाते हैं. इसमें \(\mathrm{i}\) बिग-एंडियन एन्कोडिंग में 4 बाइट और अगर $i < n-1$ और 0x01 है, तो बाइट $b$ 0x00 होता है.

फिर हम \(M_i\) AES-GCM का उपयोग करके एन्क्रिप्ट करते हैं⁴, जहाँ कुंजी\(\mathrm{DerivedKey}\)है, आरंभीकरण वेक्टर \(\mathrm{IV}_i\)​​है, और संबंधित डेटा खाली स्ट्रिंग है. \(C_i\) इस एन्क्रिप्शन का परिणाम है (यानी लिंक किए गए AES-GCM संदर्भ के अनुभाग 5.2.1.2 में \(C\) और \(T\) का संयोजन).

एन्क्रिप्ट (सुरक्षित) किए गए सेगमेंट जोड़ें

आखिर में, सभी सेगमेंट को \(\mathrm{Header} \| C_0 \| \cdots \| C_{n-1}\)के तौर पर जोड़ा जाता है, जो कि आखिरी साइफ़रटेक्स्ट होता है.

डिक्रिप्शन

डिक्रिप्शन, एन्क्रिप्शन को उलट देता है. हम हेडर का इस्तेमाल,\(\mathrm{NoncePrefix}\)को पाने और साइफ़रटेक्स्ट के हर सेगमेंट को अलग-अलग डिक्रिप्ट करने के लिए करते हैं.

एपीआई, फ़ाइल के आखिरी हिस्से की जांच किए बिना किसी फ़ाइल की शुरुआत में ऐक्सेस या रैंडम ऐक्सेस दे सकते हैं (और आम तौर पर ऐसा करते हैं). इसे जान-बूझकर बनाया गया है, क्योंकि इसे \(M_i\) से \(C_i\)डिक्रिप्ट किया जा सकता है. ऐसा, पिछले और मौजूदा साइफ़रटेक्स्ट ब्लॉक को डिक्रिप्ट किए बिना किया जा सकता है.

हालांकि, एपीआई को इस बात का ध्यान रखना चाहिए कि उपयोगकर्ता फ़ाइल के आखिर में और डिक्रिप्शन की गड़बड़ियों को गलत तरीके से न समझ पाएं: दोनों ही मामलों में, एपीआई को गड़बड़ी दिखानी होती है. दोनों ही मामलों में, एपीआई को गड़बड़ी का पता चलना चाहिए. इस अंतर को अनदेखा करने से, कोई विरोधी फ़ाइलों में काट-छांट कर सकता है.

कुंजियों को क्रम से लगाना और पार्स करना

किसी कुंजी को "टिंक प्रोटो" फ़ॉर्मैट में क्रम से लगाने के लिए, हम सबसे पहले पैरामीटर को aes_gcm_hkdf_streaming.proto पर दिए गए प्रोटो में आसान तरीके से मैप करते हैं. version फ़ील्ड को 0 पर सेट करना ज़रूरी है. इसके बाद हम इसे सामान्य प्रोटो क्रम से लगाने की सुविधा का इस्तेमाल करके क्रम से लगाते हैं और इससे मिली स्ट्रिंग को KeyData प्रोटो के फ़ील्ड की वैल्यू में जोड़ देते हैं. हमने type_url फ़ील्ड को type.googleapis.com/google.crypto.tink.AesGcmHkdfStreamingKey पर सेट किया है. इसके बाद, हम key_material_type को SYMMETRIC पर सेट कर देते हैं और इसे एक कीसेट में जोड़ देते हैं. आम तौर पर, हम output_prefix_type को RAW पर सेट करते हैं. हालांकि, अगर कुंजी को output_prefix_type के लिए सेट की गई किसी दूसरी वैल्यू के साथ पार्स किया गया था, तो Tink RAW या पिछली वैल्यू लिख सकता है.

किसी कुंजी को पार्स करने के लिए, हम ऊपर दी गई प्रक्रिया को उलट देते हैं (प्रोटो को पार्स करते समय आम तौर पर). key_material_type फ़ील्ड को अनदेखा कर दिया जाता है. output_prefix_type की वैल्यू को या तो नज़रअंदाज़ किया जा सकता है या जिन कुंजियों में RAW से output_prefix_type अलग है उन्हें अस्वीकार किया जा सकता है. जिन कुंजियों में 0 से अलग version है उन्हें अस्वीकार करना ज़रूरी है.

ज्ञात समस्याएं

ऊपर दिए गए एन्क्रिप्शन फ़ंक्शन को लागू करने के तरीके को फ़ोर्क सुरक्षित नहीं किया जाना चाहिए. Fork Safety देखें.

रेफ़रंस