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

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

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

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

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

  • \(\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\}\).

इसके बाद, हम HKDF3 का इस्तेमाल,आउटपुट की लंबाई के साथ \(\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-GCM4 का इस्तेमाल करके एन्क्रिप्ट (सुरक्षित) करते हैं, जहां कुंजी \(\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 देखें.

रेफ़रंस

  1. होआंग, रेहानिताबार, रोगवे, विज़ार, 2015. पुष्टि किए गए डेटा को एन्क्रिप्ट (सुरक्षित) करने की ऑनलाइन सुविधा और नॉन-रीयूज़ नॉन-मिस-टू-ऐक्शन गलत इस्तेमाल को रोकने की क्षमता. CRYPTO 2015. https://eprint.iacr.org/2015/189 ↩

  2. होआंग, शेन, 2020. Google की टिंक लाइब्रेरी में स्ट्रीमिंग एन्क्रिप्शन की सुरक्षा. https://eprint.iacr.org/2020/1019 ↩

  3. आरएफ़सी 5869. एचएमएसी पर आधारित एक्सट्रैक्ट-ऐंड-एक्सपैंड की डेरिवेशन फ़ंक्शन (एचकेडीएफ़). https://www.rfc-editor.org/rfc/rfc5869 ↩

  4. एनआईएसटी एसपी 800-38D. ऑपरेशन के साइफ़र मोड को ब्लॉक करने के सुझाव: Galois/Counter Mode (GCM) और GMAC. https://csrc.nist.gov/pubs/sp/800/38/d/final ↩