AES-GCM-HKDF স্ট্রিমিং AEAD

এই দস্তাবেজটি আনুষ্ঠানিকভাবে AES-GCM-HKDF স্ট্রিমিং কী দ্বারা উপস্থাপিত গাণিতিক ফাংশনটিকে সংজ্ঞায়িত করে, প্রোটো ফর্ম্যাটে type.googleapis.com/google.crypto.tink.AesGcmHkdfStreamingKey হিসাবে এনকোড করা হয়েছে।

এই এনক্রিপশনটি ঢিলেঢালাভাবে HRRV15 1 এর উপর ভিত্তি করে। নিরাপত্তা বিশ্লেষণের জন্য, আমরা HS20 2 পড়ি।

কী এবং পরামিতি

কীগুলি নিম্নলিখিত অংশগুলি দ্বারা বর্ণনা করা হয়েছে (এই নথিতে সমস্ত আকার বাইটে রয়েছে):

  • \(\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\) সমান যা পরে ব্যাখ্যা করা হয়েছে)।

যে কীগুলি এই বৈশিষ্ট্যগুলির কোনওটিই সন্তুষ্ট করে না সেগুলি টিঙ্ক দ্বারা প্রত্যাখ্যান করা হয়, হয় যখন কীটি পার্স করা হয় বা যখন সংশ্লিষ্ট আদিম তৈরি করা হয়।

এনক্রিপশন ফাংশন

সম্পর্কিত ডেটা \(\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 3 ব্যবহার করি \(\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 বাইট বিগ-এন্ডিয়ান এনকোডিং এবং বাইট $b$ হল 0x00 যদি $i < n-1$ এবং 0x01 অন্যথায়।

আমরা তখন AES-GCM 4 ব্যবহার করে \(M_i\) এনক্রিপ্ট করি, যেখানে কীটি হল\(\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}\)পেতে হেডার ব্যবহার করি এবং সাইফারটেক্সটের প্রতিটি সেগমেন্টকে পৃথকভাবে ডিক্রিপ্ট করি।

APIs (এবং সাধারণত করে) র্যান্ডম অ্যাক্সেস, বা ফাইলের শেষ পরিদর্শন ছাড়াই একটি ফাইলের শুরুতে অ্যাক্সেসের অনুমতি দিতে পারে। এটি ইচ্ছাকৃত, যেহেতু পূর্ববর্তী এবং অবশিষ্ট সাইফারটেক্সট ব্লকগুলি ডিক্রিপ্ট না করে \(M_i\) থেকে \(C_i\)-placeholder41 ডিক্রিপ্ট করা সম্ভব।

যাইহোক, API-এর সতর্কতা অবলম্বন করা উচিত যাতে ব্যবহারকারীরা ফাইলের শেষ এবং ডিক্রিপশন ত্রুটিগুলিকে বিভ্রান্ত করতে না পারে: উভয় ক্ষেত্রেই API-কে সম্ভবত একটি ত্রুটি ফেরত দিতে হবে এবং পার্থক্য উপেক্ষা করার ফলে একটি প্রতিপক্ষকে কার্যকরভাবে ফাইল ছেঁটে ফেলতে সক্ষম হতে পারে।

ক্রমিককরণ এবং কীগুলির পার্সিং

"Tink Proto" ফরম্যাটে একটি কীকে সিরিয়ালাইজ করতে, আমরা প্রথমে aes_gcm_hkdf_streaming.proto এ প্রদত্ত প্রোটোতে স্পষ্টভাবে প্যারামিটারগুলি ম্যাপ করি। ক্ষেত্র version 0 তে সেট করা দরকার। তারপরে আমরা এটিকে সাধারণ প্রোটো সিরিয়ালাইজেশন ব্যবহার করে সিরিয়ালাইজ করি এবং ফলাফল স্ট্রিংটিকে একটি কীডেটা প্রোটোর ক্ষেত্রের মানটিতে এম্বেড করি। আমরা 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 আছে এমন কীগুলি অবশ্যই প্রত্যাখ্যান করতে হবে।

জ্ঞাত সমস্যা

উপরোক্ত এনক্রিপশন ফাংশনের বাস্তবায়ন কাঁটা নিরাপদ হবে বলে আশা করা যায় না। ফর্ক নিরাপত্তা দেখুন।

তথ্যসূত্র

  1. Hoang, Reyhanitabar, Rogaway, Vizar, 2015। অনলাইন প্রমাণীকৃত-এনক্রিপশন এবং এর অ-পুনঃব্যবহার অপব্যবহার-প্রতিরোধ। CRYPTO 2015। https://eprint.iacr.org/2015/189 ↩

  2. Hoang, Shen, 2020. Google-এর Tink লাইব্রেরিতে স্ট্রিমিং এনক্রিপশনের নিরাপত্তা। https://eprint.iacr.org/2020/1019 ↩

  3. RFC 5869. HMAC-ভিত্তিক Extract-and-expand Key Derivation Function (HKDF)। https://www.rfc-editor.org/rfc/rfc5869 ↩

  4. NIST SP 800-38D. অপারেশনের ব্লক সাইফার মোডের জন্য সুপারিশ: গ্যালোইস/কাউন্টার মোড (GCM) এবং GMAC। https://csrc.nist.gov/pubs/sp/800/38/d/final ↩