สตรีมมิง AEAD สำหรับ HMAC ของ AES-CTR
จัดทุกอย่างให้เป็นระเบียบอยู่เสมอด้วยคอลเล็กชัน
บันทึกและจัดหมวดหมู่เนื้อหาตามค่ากำหนดของคุณ
เอกสารนี้กำหนดฟังก์ชันทางคณิตศาสตร์อย่างเป็นทางการซึ่งแสดงโดยคีย์สตรีมมิง AES-CTR HMAC (เข้ารหัสในรูปแบบโปรโตเป็น type.googleapis.com/google.crypto.tink.AesCtrHmacStreamingKey)
การเข้ารหัสนี้อิงตาม [HRRV15]1 อย่างคร่าวๆ สําหรับการวิเคราะห์ความปลอดภัย โปรดดูที่ [HS20]2 โปรดทราบว่าการทดสอบข้ามภาษาของ Tink ยังมีไฟล์ทดสอบ aes_ctr_hmac_streaming_key_test.py ซึ่งมี test_manually_created_test_vector พร้อมคำแนะนำแบบสมบูรณ์เกี่ยวกับวิธีรับข้อความที่เข้ารหัส
คีย์และพารามิเตอร์
คีย์จะอธิบายด้วยส่วนต่อไปนี้ (ขนาดทั้งหมดในเอกสารนี้เป็นหน่วยไบต์)
- \(\mathrm{InitialKeyMaterial}\)ซึ่งเป็นสตริงไบต์: ข้อมูลคีย์เริ่มต้น
- \(\mathrm{CiphertextSegmentSize} \in \{1, 2, \ldots, 2^{31}-1\}\)
- \(\mathrm{DerivedKeySize} \in \{16, 32\}\)
- \(\mathrm{HkdfHashType} \in \{\mathrm{SHA1}, \mathrm{SHA256},
\mathrm{SHA512}\}\)
- \(\mathrm{HmacHashType} \in \{\mathrm{SHA1}, \mathrm{SHA256},
\mathrm{SHA512}\}\)
- \(\mathrm{HmacTagSize} \in \mathbb{N}\)
คีย์ที่ถูกต้องจะต้องมีคุณสมบัติตรงตามพร็อพเพอร์ตี้ต่อไปนี้ด้วย
- \(\mathrm{len}(\mathrm{InitialKeyMaterial}) \geq \mathrm{DerivedKeySize}\)
- ถ้า \(\mathrm{HmacHashType} = \mathrm{SHA1}\) แล้ว \(\mathrm{HmacTagSize}
\in \{10, \ldots, 20\}\)
- ถ้า \(\mathrm{HmacHashType} = \mathrm{SHA256}\) แล้ว \(\mathrm{HmacTagSize}
\in \{10, \ldots, 32\}\)
- ถ้า \(\mathrm{HmacHashType} = \mathrm{SHA512}\) แล้ว \(\mathrm{HmacTagSize}
\in \{10, \ldots, 64\}\)
- \(\mathrm{CiphertextSegmentSize} > \mathrm{DerivedKeySize} +
\mathrm{HmacTagSize} + 8\) (ค่านี้เท่ากับ
\(\mathrm{len}(\mathrm{Header}) + \mathrm{HmacTagSize}\) ตามที่อธิบายไว้ภายหลัง)
Tink จะปฏิเสธคีย์ที่ไม่เป็นไปตามคุณสมบัติเหล่านี้ (เมื่อมีการแยกวิเคราะห์คีย์หรือเมื่อสร้างพรอมิตที่เกี่ยวข้อง)
ฟังก์ชันการเข้ารหัส
หากต้องการเข้ารหัสข้อความ \(\mathrm{Msg}\) ที่มีข้อมูลที่เกี่ยวข้อง
\(\mathrm{AssociatedData}\)เราจะสร้างส่วนหัว แบ่งข้อความออกเป็นส่วนๆ เข้ารหัสแต่ละส่วน และต่อเชื่อมส่วนต่างๆ เราอธิบายขั้นตอนเหล่านี้ดังต่อไปนี้
ในการสร้างส่วนหัว ก่อนอื่นเราจะเลือกสตริงแบบสุ่มแบบสม่ำเสมอ \(\mathrm{Salt}\)ที่มีความยาว \(\mathrm{DerivedKeySize}\)ถัดไปเราจะเลือกสตริงแบบสุ่มแบบสม่ำเสมอที่มีความยาว 7\(\mathrm{NoncePrefix}\)
จากนั้นเราตั้งค่า\(\mathrm{Header} := \mathrm{len}(\mathrm{Header}) \| \mathrm{Salt} \|
\mathrm{NoncePrefix}\)โดยความยาวของส่วนหัวจะเข้ารหัสเป็นไบต์เดี่ยว เราพบว่า
\(\mathrm{len}(\mathrm{Header}) \in \{24, 40\}\)
ถัดไป เราใช้ HKDF3 กับฟังก์ชันแฮช \(\mathrm{HkdfHashType}\)เพื่อคํานวณข้อมูลคีย์ที่มีความยาว
\(\mathrm{DerivedKeySize} + 32\) สําหรับข้อความนี้
\(k := \mathrm{HKDF}(\mathrm{InitialKeyMaterial}, \mathrm{Salt},
\mathrm{AssociatedData})\)
ระบบจะใช้อินพุตในอินพุตที่เกี่ยวข้องของ
\(\mathrm{HKDF}\)โดย \(\mathrm{InitialKeyMaterial}\) คือ \(\mathrm{ikm}\)
\(\mathrm{Salt}\) คือเกลือ และ
\(\mathrm{AssociatedData}\) จะใช้เป็น \(\mathrm{info}\)
จากนั้น \(k\) สตริงจะแบ่งออกเป็น 2 ส่วน \(k_1 \| k_2 := k\)ดังนี้
\(\mathrm{len}(k_1) = \mathrm{DerivedKeySize}\) และ \(\mathrm{len}(k_2) = 32\)
การแยกข้อความ
ข้อความ \(M\) จะแบ่งออกเป็นส่วนๆ ดังนี้ \(M = M_0 \| M_1 \| \cdots
\| M_{n-1}\)
ความยาวของวิดีโอจะเลือกให้เป็นไปตามข้อกำหนดต่อไปนี้
- \(\mathrm{len}(M_0) \in \{0,\ldots, \mathrm{CiphertextSegmentSize} -
\mathrm{len}(\mathrm{Header}) - \mathrm{HmacTagSize}\}\)
- ถ้า \(n > 1\)ให้ \(\mathrm{len}(M_1), \ldots, \mathrm{len}(M_{n-1})
\in \{1,\ldots, \mathrm{CiphertextSegmentSize} - \mathrm{HmacTagSize}\}\)
- หาก \(n > 1\)\(M_{0}, \ldots, M_{n-2}\) ต้องมีความยาวสูงสุดตามข้อจำกัดข้างต้น
ในการแยกนี้ \(n\) ต้องมีความยาวไม่เกิน \(2^{32}\)มิฉะนั้นการเข้ารหัสจะไม่สำเร็จ
การเข้ารหัสบล็อก
หากต้องการเข้ารหัสกลุ่ม \(M_i\)ก่อนอื่นเราจะคํานวณ
\(\mathrm{IV}_i := \mathrm{NoncePrefix} \| \mathrm{i} \| b \| 0x00000000\)
โดยเข้ารหัส \(\mathrm{i}\) เป็น 4
ไบต์โดยใช้การเข้ารหัส Big-Endian และตั้งค่าไบต์ $b$ เป็น 0x00 หาก $i < n-1$
และ 0x01 ในกรณีอื่น
จากนั้นเราจะเข้ารหัส \(M_i\) โดยใช้คีย์ AES CTR \(k_1\)และเวกเตอร์การเริ่มต้น
\(\mathrm{IV}_i\)กล่าวคือ อินพุตสําหรับการเรียกใช้ AES คือ
\(\mathrm{IV}_i, \mathrm{IV}_i + 1, \mathrm{IV}_i + 2, \ldots\)
โดยที่ \(\mathrm{IV}_i\) จะตีความเป็นจํานวนเต็มแบบ Big-endian
ซึ่งจะให้ผลลัพธ์เป็น \(C'_i\)
เราคํานวณแท็กโดยใช้ HMAC ด้วยฟังก์ชันแฮชที่ระบุโดย \(\mathrm{HmacHashType}\) และคีย์ \(k_2\) ในการเชื่อมต่อ\(\mathrm{IV}_i \| C'_i\)
จากนั้นเราจะต่อข้อความที่เข้ารหัสตามด้วยแท็กเพื่อรับ \(C_i\)
ต่อกลุ่ม
สุดท้าย ระบบจะต่อกลุ่มทั้งหมดเป็น\(\mathrm{Header} \| C_0 \| \cdots \| C_{n-1}\)ซึ่งเป็นข้อความที่เข้ารหัสขั้นสุดท้าย
ฟังก์ชันการถอดรหัส
การถอดรหัสคือการถอดรหัสการเข้ารหัส เราใช้ส่วนหัวเพื่อรับ Nonce และถอดรหัสข้อความที่เข้ารหัสแต่ละส่วนแยกกัน
API อาจ (และมักจะ) อนุญาตการเข้าถึงแบบสุ่มหรือการเข้าถึงส่วนต้นของไฟล์โดยไม่ตรวจสอบส่วนท้ายของไฟล์ ซึ่งเราตั้งใจให้เป็นแบบนั้น เนื่องจากสามารถถอดรหัส \(M_i\) จาก \(C_i\)ได้โดยไม่ต้องถอดรหัสบล็อกข้อความที่เข้ารหัสก่อนหน้าและที่เหลือทั้งหมด
อย่างไรก็ตาม API ควรระมัดระวังไม่ให้ผู้ใช้สับสนระหว่างข้อผิดพลาดเกี่ยวกับไฟล์สิ้นสุดและข้อผิดพลาดในการถอดรหัส เนื่องจากทั้ง 2 กรณี API อาจต้องแสดงข้อผิดพลาด และ การละเว้นความแตกต่างอาจทําให้คู่แข่งตัดไฟล์ได้อย่างมีประสิทธิภาพ
การจัดรูปแบบและการแยกวิเคราะห์คีย์
หากต้องการจัดรูปแบบคีย์เป็นรูปแบบ "Tink Proto" ก่อนอื่นเราจะแมปพารามิเตอร์ในลักษณะที่ชัดเจนไปยังโปรโตที่ระบุไว้ที่ aes_ctr_hmac_streaming.proto
ต้องตั้งค่าช่อง version เป็น 0
จากนั้นเราจะจัดรูปแบบโดยใช้การแปลงเป็นอนุกรมโปรโตปกติ และฝังสตริงที่ได้ไว้ในค่าของช่องโปรโต KeyData เราตั้งค่าช่อง type_url เป็น type.googleapis.com/google.crypto.tink.AesCtrHmacStreamingKey
จากนั้นตั้งค่า key_material_type เป็น SYMMETRIC และฝังลงในชุดคีย์ เรามักจะตั้งค่า output_prefix_type เป็น RAW ข้อยกเว้นคือหากมีการแยกวิเคราะห์คีย์ด้วยการตั้งค่าค่าอื่นสําหรับ output_prefix_type ไว้ Tink อาจเขียน RAW หรือค่าก่อนหน้า
หากต้องการแยกวิเคราะห์คีย์ เราจะย้อนกระบวนการข้างต้น (ตามปกติเมื่อแยกวิเคราะห์ Proto) ระบบจะละเว้นช่อง key_material_type ระบบอาจละเว้นค่าของ output_prefix_type หรือปฏิเสธคีย์ที่มี output_prefix_type แตกต่างจาก RAW
ระบบจะปฏิเสธคีย์ที่มี version ต่างจาก 0
ข้อมูลอ้างอิง
เนื้อหาของหน้าเว็บนี้ได้รับอนุญาตภายใต้ใบอนุญาตที่ต้องระบุที่มาของครีเอทีฟคอมมอนส์ 4.0 และตัวอย่างโค้ดได้รับอนุญาตภายใต้ใบอนุญาต Apache 2.0 เว้นแต่จะระบุไว้เป็นอย่างอื่น โปรดดูรายละเอียดที่นโยบายเว็บไซต์ Google Developers Java เป็นเครื่องหมายการค้าจดทะเบียนของ Oracle และ/หรือบริษัทในเครือ
อัปเดตล่าสุด 2025-07-25 UTC
[[["เข้าใจง่าย","easyToUnderstand","thumb-up"],["แก้ปัญหาของฉันได้","solvedMyProblem","thumb-up"],["อื่นๆ","otherUp","thumb-up"]],[["ไม่มีข้อมูลที่ฉันต้องการ","missingTheInformationINeed","thumb-down"],["ซับซ้อนเกินไป/มีหลายขั้นตอนมากเกินไป","tooComplicatedTooManySteps","thumb-down"],["ล้าสมัย","outOfDate","thumb-down"],["ปัญหาเกี่ยวกับการแปล","translationIssue","thumb-down"],["ตัวอย่าง/ปัญหาเกี่ยวกับโค้ด","samplesCodeIssue","thumb-down"],["อื่นๆ","otherDown","thumb-down"]],["อัปเดตล่าสุด 2025-07-25 UTC"],[[["\u003cp\u003eThis document defines the AES-CTR HMAC Streaming key and its mathematical function for encryption and decryption, loosely based on the HRRV15 and HS20 security analyses.\u003c/p\u003e\n"],["\u003cp\u003eThe encryption process involves creating a header, splitting the message into segments, encrypting each segment using AES CTR with a derived key, and concatenating the segments along with the header.\u003c/p\u003e\n"],["\u003cp\u003eKeys are described by parameters including InitialKeyMaterial, CiphertextSegmentSize, DerivedKeySize, HkdfHashType, HmacHashType, and HmacTagSize, with specific validity constraints.\u003c/p\u003e\n"],["\u003cp\u003eDecryption reverses the encryption process, allowing for potential random access to segments but requiring careful handling of end-of-file and decryption errors.\u003c/p\u003e\n"],["\u003cp\u003eSerialization and parsing of keys involve mapping parameters to a proto format, embedding them in a KeyData proto, and setting specific fields like type_url, key_material_type, and output_prefix_type.\u003c/p\u003e\n"]]],["AES-CTR HMAC Streaming keys define an encryption method involving key parameters like `InitialKeyMaterial`, `CiphertextSegmentSize`, `DerivedKeySize`, `HkdfHashType`, `HmacHashType`, and `HmacTagSize`. Encryption creates a header with a random salt and nonce prefix, derives key material using HKDF, and splits the message into segments. Each segment is encrypted using AES-CTR with a unique IV and HMAC tag, then concatenated to form the ciphertext. Decryption reverses this process. Keys are serialized into a specific proto format.\n"],null,["# AES-CTR HMAC Streaming AEAD\n\nThis document formally defines the mathematical function represented by\nAES-CTR HMAC Streaming keys (encoded in proto format as\n`type.googleapis.com/google.crypto.tink.AesCtrHmacStreamingKey`).\n\nThis encryption is loosely based on \\[HRRV15\\]^[1](#fn1)^. For an analysis of the\nsecurity we refer to \\[HS20\\]^[2](#fn2)^. Note also that the Tink cross language tests\nhave a test\n[aes_ctr_hmac_streaming_key_test.py](https://github.com/google/tink/blob/master/testing/cross_language/streaming_aead/aes_ctr_hmac_streaming_key_test.py) which\ncontains `test_manually_created_test_vector` with a complete walkthrough on how\nto get a ciphertext.\n\nKey and parameters\n------------------\n\nKeys are described by the following parts (all sizes in this document are in\nbytes):\n\n- \\\\(\\\\mathrm{InitialKeyMaterial}\\\\), a byte string: the initial key material.\n- \\\\(\\\\mathrm{CiphertextSegmentSize} \\\\in \\\\{1, 2, \\\\ldots, 2\\^{31}-1\\\\}\\\\).\n- \\\\(\\\\mathrm{DerivedKeySize} \\\\in \\\\{16, 32\\\\}\\\\).\n- \\\\(\\\\mathrm{HkdfHashType} \\\\in \\\\{\\\\mathrm{SHA1}, \\\\mathrm{SHA256}, \\\\mathrm{SHA512}\\\\}\\\\).\n- \\\\(\\\\mathrm{HmacHashType} \\\\in \\\\{\\\\mathrm{SHA1}, \\\\mathrm{SHA256}, \\\\mathrm{SHA512}\\\\}\\\\).\n- \\\\(\\\\mathrm{HmacTagSize} \\\\in \\\\mathbb{N}\\\\).\n\nValid keys additionally satisfy the following properties:\n\n- \\\\(\\\\mathrm{len}(\\\\mathrm{InitialKeyMaterial}) \\\\geq \\\\mathrm{DerivedKeySize}\\\\).\n- If \\\\(\\\\mathrm{HmacHashType} = \\\\mathrm{SHA1}\\\\) then \\\\(\\\\mathrm{HmacTagSize} \\\\in \\\\{10, \\\\ldots, 20\\\\}\\\\).\n- If \\\\(\\\\mathrm{HmacHashType} = \\\\mathrm{SHA256}\\\\) then \\\\(\\\\mathrm{HmacTagSize} \\\\in \\\\{10, \\\\ldots, 32\\\\}\\\\).\n- If \\\\(\\\\mathrm{HmacHashType} = \\\\mathrm{SHA512}\\\\) then \\\\(\\\\mathrm{HmacTagSize} \\\\in \\\\{10, \\\\ldots, 64\\\\}\\\\).\n- \\\\(\\\\mathrm{CiphertextSegmentSize} \\\u003e \\\\mathrm{DerivedKeySize} + \\\\mathrm{HmacTagSize} + 8\\\\) (This equals \\\\(\\\\mathrm{len}(\\\\mathrm{Header}) + \\\\mathrm{HmacTagSize}\\\\) as explained later).\n\nKeys which do not satisfy any of these properties are rejected by Tink (either\nwhen the key is parsed or when the corresponding primitive is created).\n\nEncryption function\n-------------------\n\nTo encrypt a message \\\\(\\\\mathrm{Msg}\\\\) with associated data\n\\\\(\\\\mathrm{AssociatedData}\\\\), we create a header,\nsplit the message into segments, encrypt each segment, and concatenate\nthe segments. We explain these steps in the following.\n\n### Creating the header\n\nTo create the header, we first pick a uniform random string \\\\(\\\\mathrm{Salt}\\\\)\nof length \\\\(\\\\mathrm{DerivedKeySize}\\\\). We next pick a uniform random string\n\\\\(\\\\mathrm{NoncePrefix}\\\\) of length 7.\n\nWe then set\n\\\\(\\\\mathrm{Header} := \\\\mathrm{len}(\\\\mathrm{Header}) \\\\\\| \\\\mathrm{Salt} \\\\\\|\n\\\\mathrm{NoncePrefix}\\\\),\nwhere the length of the header is encoded as a single byte. We note that\n\\\\(\\\\mathrm{len}(\\\\mathrm{Header}) \\\\in \\\\{24, 40\\\\}\\\\).\n\nNext, we use HKDF^[3](#fn3)^ with hash-function \\\\(\\\\mathrm{HkdfHashType}\\\\)\nto compute key material of length\n\\\\(\\\\mathrm{DerivedKeySize} + 32\\\\) for this message:\n\\\\(k := \\\\mathrm{HKDF}(\\\\mathrm{InitialKeyMaterial}, \\\\mathrm{Salt},\n\\\\mathrm{AssociatedData})\\\\).\nThe inputs are used in the corresponding respective inputs of\n\\\\(\\\\mathrm{HKDF}\\\\): \\\\(\\\\mathrm{InitialKeyMaterial}\\\\) is \\\\(\\\\mathrm{ikm}\\\\),\n\\\\(\\\\mathrm{Salt}\\\\) is the salt, and\n\\\\(\\\\mathrm{AssociatedData}\\\\) is used as \\\\(\\\\mathrm{info}\\\\).\n\nThe string \\\\(k\\\\) is then split into two parts \\\\(k_1 \\\\\\| k_2 := k\\\\),\nsuch that\n\\\\(\\\\mathrm{len}(k_1) = \\\\mathrm{DerivedKeySize}\\\\) and \\\\(\\\\mathrm{len}(k_2) = 32\\\\).\n\n### Splitting the message\n\nThe message \\\\(M\\\\) is next split into parts: \\\\(M = M_0 \\\\\\| M_1 \\\\\\| \\\\cdots\n\\\\\\| M_{n-1}\\\\).\n\nTheir lengths are chosen so that they satisfy:\n\n- \\\\(\\\\mathrm{len}(M_0) \\\\in \\\\{0,\\\\ldots, \\\\mathrm{CiphertextSegmentSize} - \\\\mathrm{len}(\\\\mathrm{Header}) - \\\\mathrm{HmacTagSize}\\\\}\\\\).\n- If \\\\(n \\\u003e 1\\\\), then \\\\(\\\\mathrm{len}(M_1), \\\\ldots, \\\\mathrm{len}(M_{n-1}) \\\\in \\\\{1,\\\\ldots, \\\\mathrm{CiphertextSegmentSize} - \\\\mathrm{HmacTagSize}\\\\}\\\\).\n- If \\\\(n \\\u003e 1\\\\), then \\\\(M_{0}, \\\\ldots, M_{n-2}\\\\) must have maximal length according to the above to constraints.\n\nIn this splitting, \\\\(n\\\\) may at most be \\\\(2\\^{32}\\\\). Otherwise, encryption fails.\n\n### Encrypting the blocks\n\nTo encrypt segment \\\\(M_i\\\\), we first compute\n\\\\(\\\\mathrm{IV}_i := \\\\mathrm{NoncePrefix} \\\\\\| \\\\mathrm{i} \\\\\\| b \\\\\\| 0x00000000\\\\),\nwhere we encode \\\\(\\\\mathrm{i}\\\\) in 4\nbytes using big-endian encoding, and set the byte $b$ to be `0x00` if $i \\\u003c n-1$\nand `0x01` otherwise.\n\nWe then encrypt \\\\(M_i\\\\) using AES CTR key \\\\(k_1\\\\), and initialization vector\n\\\\(\\\\mathrm{IV}_i\\\\). In other words, the inputs to the invocations of AES are\n\\\\(\\\\mathrm{IV}_i, \\\\mathrm{IV}_i + 1, \\\\mathrm{IV}_i + 2, \\\\ldots\\\\)\nwhere \\\\(\\\\mathrm{IV}_i\\\\) is interpreted as big-endian integer.\nThis yields \\\\(C'_i\\\\).\n\nWe compute the tag using HMAC with the hash function given\nby \\\\(\\\\mathrm{HmacHashType}\\\\) and with key \\\\(k_2\\\\) over the concatenation\n\\\\(\\\\mathrm{IV}_i \\\\\\| C'_i\\\\).\n\nWe then concatenate the ciphertext followed by the tag to get \\\\(C_i\\\\).\n\n### Concatenate the segments\n\nFinally, all segments are concatenated as\n\\\\(\\\\mathrm{Header} \\\\\\| C_0 \\\\\\| \\\\cdots \\\\\\| C_{n-1}\\\\), which is the final ciphertext.\n\nDecryption function\n-------------------\n\nDecryption simply inverts the encryption. We use the header to obtain the nonce,\nand decrypt each segment of ciphertext individually.\n\nAPIs may (and typically do) allow random access, or access to the\nbeginning of a file without inspecting the end of the file. This is\nintentional, since it is possible to decrypt \\\\(M_i\\\\) from \\\\(C_i\\\\),\nwithout decrypting all previous and remaining ciphertext blocks.\n\nHowever, APIs should be careful to not allow users to confuse end-of-file and\ndecryption errors: in both cases the API probably has to return an error, and\nignoring the difference can lead to an adversary being able to effectively\ntruncate files.\n\nSerialization and parsing of keys\n---------------------------------\n\nTo serialize a key in the \"Tink Proto\" format, we first map the parameters\nin the obvious way into the proto given at\n[aes_ctr_hmac_streaming.proto](https://github.com/tink-crypto/tink-java/blob/main/proto/aes_ctr_hmac_streaming.proto).\nThe field `version` needs to be set to 0.\nWe then serialize this using normal proto serialization, and embed the resulting\nstring in the value of field of a\n[KeyData](https://github.com/tink-crypto/tink-java/blob/main/proto/tink.proto) proto. We set the `type_url` field\nto `type.googleapis.com/google.crypto.tink.AesCtrHmacStreamingKey`.\nWe then set `key_material_type` to `SYMMETRIC`, and embed this into a keyset. We\nusually set the `output_prefix_type` to `RAW`. The exception is that if the key\nwas parsed with a different value set for `output_prefix_type`,\nTink may either write `RAW` or the previous value.\n\nTo parse a key, we reverse the above process (in the usual way when parsing\nprotos). The field `key_material_type` is ignored. The value of\n`output_prefix_type` can either be ignored, or keys which\nhave `output_prefix_type` different from `RAW` can be rejected.\nKeys which have a `version` different from 0 are be rejected.\n\nReferences\n----------\n\n*** ** * ** ***\n\n1. \\[HRRV15\\] Hoang, Reyhanitabar, Rogaway, Vizar. Online\n authenticated-encryption and its nonce-reuse misuse-resistance. CRYPTO 2015.\n \u003chttps://eprint.iacr.org/2015/189\u003e [↩](#fnref1)\n\n2. \\[HS20\\] Security of Streaming Encryption in Google's Tink Library.\n Hoang, Shen, 2020.\n \u003chttps://eprint.iacr.org/2020/1019\u003e [↩](#fnref2)\n\n3. \\[HKDF\\] HMAC-based Extract-and-Expand Key Derivation Function (HKDF),\n RFC 5869. \u003chttps://www.rfc-editor.org/rfc/rfc5869\u003e [↩](#fnref3)"]]
