From f09cd28197d989ccff79fb0edc20117decc4371e Mon Sep 17 00:00:00 2001 From: Frank Denis Date: Wed, 17 Jan 2024 20:52:07 +0100 Subject: [PATCH 1/9] Reorganize the Security Considerations section --- draft-irtf-cfrg-aegis-aead.md | 40 ++++++++++++++++++++++------------- 1 file changed, 25 insertions(+), 15 deletions(-) diff --git a/draft-irtf-cfrg-aegis-aead.md b/draft-irtf-cfrg-aegis-aead.md index 19f519d..e4a3d6e 100644 --- a/draft-irtf-cfrg-aegis-aead.md +++ b/draft-irtf-cfrg-aegis-aead.md @@ -1558,15 +1558,7 @@ A comprehensive list of known implementations and integrations can be found at [ # Security Considerations -AEGIS-256 offers 256-bit message security against plaintext and state recovery, whereas AEGIS-128L offers 128-bit security. - -An authentication tag may verify under multiple keys, nonces, or associated data, but AEGIS is assumed to be key committing in the receiver-binding game, preventing common attacks when used with low-entropy keys such as passwords. Finding distinct keys and/or nonces that successfully verify the same `(ad, ct, tag)` tuple is expected to require ~264 attempts with a 128-bit authentication tag and ~2128 attempts with a 256-bit tag. - -It is fully committing in the restricted setting where an adversary cannot control the associated data. As shown in {{IR23}}, with the ability to alter the associated data, it is possible to efficiently find multiple keys that will verify the same authenticated ciphertext. - -Protocols mandating a fully committing scheme without that restriction can provide the associated data as input to a cryptographic hash function and use the output as the `ad` parameter of the `Encrypt` and `Decrypt` functions. The selected hash function must ensure a minimum of 128-bit preimage resistance. An instance of such a function is SHA-256 {{!RFC6234}}. - -Under the assumption that the secret key is unknown to the attacker, all AEGIS variants target 128-bit security against forgery attacks regardless of the tag size. +## Usage Guidelines All AEGIS variants MUST be used in a nonce-respecting setting: for a given `key`, a `nonce` MUST only be used once. Failure to do so would immediately reveal the bitwise difference between two messages. @@ -1580,26 +1572,44 @@ With AEGIS-128L and AEGIS-128X, random nonces can safely encrypt up to 248< With AEGIS-256 and AEGIS-256X, random nonces can be used with no practical limits. +All variants can be used as a MAC by calling the `Encrypt()` function with the message as the `ad` and leaving `msg` empty, resulting in just a tag. However, they MUST NOT be used as a hash function; if the key is known, inputs generating state collisions can easily be crafted. Similarly, as opposed to hash-based MACs, tags MUST NOT be used for key derivation as there is no proof they are uniformly random. + +For the same `(key, nonce, ad, msg)` tuple, a different degree of parallelism in AEGIS-128X and AEGIS-256X can produce a different `ct` and `tag`. Furthermore, different `ad` with the same `(key, nonce, msg)` can produce a different `ct` and `tag` with all variants. However, as the `ad` and `msg` are absorbed into the state identically in that order, this does not necessarily hold when the `msg` changes. + +### Key Commitment + +An authentication tag may verify under multiple keys, nonces, or associated data, but AEGIS is assumed to be key committing in the receiver-binding game, preventing common attacks when used with low-entropy keys such as passwords. Finding distinct keys and/or nonces that successfully verify the same `(ad, ct, tag)` tuple is expected to require ~264 attempts with a 128-bit authentication tag and ~2128 attempts with a 256-bit tag. + +It is fully committing in the restricted setting where an adversary cannot control the associated data. As shown in {{IR23}}, with the ability to alter the associated data, it is possible to efficiently find multiple keys that will verify the same authenticated ciphertext. + +Protocols mandating a fully committing scheme without that restriction can provide the associated data as input to a cryptographic hash function and use the output as the `ad` parameter of the `Encrypt` and `Decrypt` functions. The selected hash function must ensure a minimum of 128-bit preimage resistance. An instance of such a function is SHA-256 {{!RFC6234}}. + +### Multi-User Security + AEGIS nonces match the size of the key. AEGIS-128L and AEGIS-128X feature 128-bit nonces, offering an extra 32 bits compared to the commonly used AEADs in IETF protocols. The AEGIS-256 and AEGIS-256X variants provide even larger nonces. With 192 random bits, 64 bits remain available to optionally encode additional information. In all these variants, unused nonce bits can encode a key identifier, enhancing multi-user security. If every key has a unique identifier, multi-target attacks don't provide any advantage over single-target attacks. -Regardless of the variant, the `key` and `nonce` are only required by the `Init` function; other functions only depend on the resulting state. Therefore, implementations can overwrite ephemeral keys with zeros right after the last `Update` call of the initialization function. - -For the same `(key, nonce, ad, msg)` tuple, a different degree of parallelism in AEGIS-128X and AEGIS-256X can produce a different `ct` and `tag`. Furthermore, different `ad` with the same `(key, nonce, msg)` can produce a different `ct` and `tag` with all variants. However, as the `ad` and `msg` are absorbed into the state identically in that order, this does not necessarily hold when the `msg` changes. +## Security Guarantees -Each variant can be used as a MAC by calling the `Encrypt()` function with the message as the `ad` and leaving `msg` empty, resulting in just a tag. However, they MUST NOT be used as a hash function; if the key is known, inputs generating state collisions can easily be crafted. Similarly, as opposed to hash-based MACs, tags MUST NOT be used for key derivation as there is no proof they are uniformly random. +AEGIS-256 offers 256-bit message security against plaintext and state recovery, whereas AEGIS-128L offers 128-bit security. -As shown in {{D23}}, AEGIS-128X and AEGIS-256X share the same security properties and requirements as AEGIS-128L and AEGIS-256 respectively. In particular, the security level and usage limits remain the same. +Under the assumption that the secret key is unknown to the attacker, all AEGIS variants target 128-bit security against forgery attacks regardless of the tag size. AEGIS has been shown to have reforgeability resilience in {{FLLW17}}. Without the ability to set the associated data, a successful forgery does not increase the probability of subsequent forgeries. -The security of AEGIS against timing and physical attacks is limited by the implementation of the underlying `AESRound()` function. Failure to implement `AESRound()` in a fashion safe against timing and physical attacks, such as differential power analysis, timing analysis or fault injection attacks, may lead to leakage of secret key material or state information. The exact mitigations required for timing and physical attacks also depend on the threat model in question. +AEGIS-128X and AEGIS-256X share the same security properties and requirements as AEGIS-128L and AEGIS-256 respectively. In particular, the security level and usage limits remain the same {{D23}}. AEGIS is considered secure against guess-and-determine attacks aimed at recovering the state from observed ciphertexts. This resilience extends to quantum adversaries in the Q1 model, wherein quantum attacks do not confer any practical advantage for decrypting previously recorded ciphertexts or achieving key recovery. Security analyses of AEGIS can be found in {{AEGIS}}, {{M14}}, {{ENP19}}, {{LIMS21}}, {{JLD21}}, {{STSI23}}, {{IR23}}, {{BS23}}, and {{FLLW17}}. +## Implementation Security + +The security of AEGIS against timing and physical attacks is limited by the implementation of the underlying `AESRound()` function. Failure to implement `AESRound()` in a fashion safe against timing and physical attacks, such as differential power analysis, timing analysis, or fault injection attacks, may lead to leakage of secret key material or state information. The exact mitigations required for timing and physical attacks also depend on the threat model in question. + +Regardless of the variant, the `key` and `nonce` are only required by the `Init` function; other functions only depend on the resulting state. Therefore, implementations can overwrite ephemeral keys with zeros right after the last `Update` call of the initialization function. + # IANA Considerations IANA has assigned the following identifiers in the AEAD Algorithms Registry: From 11265b827d3e104a0746d14c3813454c996c1368 Mon Sep 17 00:00:00 2001 From: Frank Denis Date: Wed, 17 Jan 2024 22:52:30 +0100 Subject: [PATCH 2/9] An attempt at organizing the remaining paragraphs --- draft-irtf-cfrg-aegis-aead.md | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/draft-irtf-cfrg-aegis-aead.md b/draft-irtf-cfrg-aegis-aead.md index e4a3d6e..f164a22 100644 --- a/draft-irtf-cfrg-aegis-aead.md +++ b/draft-irtf-cfrg-aegis-aead.md @@ -1560,9 +1560,9 @@ A comprehensive list of known implementations and integrations can be found at [ ## Usage Guidelines -All AEGIS variants MUST be used in a nonce-respecting setting: for a given `key`, a `nonce` MUST only be used once. Failure to do so would immediately reveal the bitwise difference between two messages. +### Key And Nonce Selection -If tag verification fails, the unverified plaintext and the computed message authentication tag MUST NOT be released. As shown in {{VV18}}, even a partial leak of the plaintext without verification would facilitate chosen ciphertext attacks. +All AEGIS variants MUST be used in a nonce-respecting setting: for a given `key`, a `nonce` MUST only be used once. Failure to do so would immediately reveal the bitwise difference between two messages. Every key MUST be randomly chosen from a uniform distribution. @@ -1572,10 +1572,6 @@ With AEGIS-128L and AEGIS-128X, random nonces can safely encrypt up to 248< With AEGIS-256 and AEGIS-256X, random nonces can be used with no practical limits. -All variants can be used as a MAC by calling the `Encrypt()` function with the message as the `ad` and leaving `msg` empty, resulting in just a tag. However, they MUST NOT be used as a hash function; if the key is known, inputs generating state collisions can easily be crafted. Similarly, as opposed to hash-based MACs, tags MUST NOT be used for key derivation as there is no proof they are uniformly random. - -For the same `(key, nonce, ad, msg)` tuple, a different degree of parallelism in AEGIS-128X and AEGIS-256X can produce a different `ct` and `tag`. Furthermore, different `ad` with the same `(key, nonce, msg)` can produce a different `ct` and `tag` with all variants. However, as the `ad` and `msg` are absorbed into the state identically in that order, this does not necessarily hold when the `msg` changes. - ### Key Commitment An authentication tag may verify under multiple keys, nonces, or associated data, but AEGIS is assumed to be key committing in the receiver-binding game, preventing common attacks when used with low-entropy keys such as passwords. Finding distinct keys and/or nonces that successfully verify the same `(ad, ct, tag)` tuple is expected to require ~264 attempts with a 128-bit authentication tag and ~2128 attempts with a 256-bit tag. @@ -1590,6 +1586,12 @@ AEGIS nonces match the size of the key. AEGIS-128L and AEGIS-128X feature 128-bi In all these variants, unused nonce bits can encode a key identifier, enhancing multi-user security. If every key has a unique identifier, multi-target attacks don't provide any advantage over single-target attacks. +### Additional Considerations + +If tag verification fails, the unverified plaintext and the computed message authentication tag MUST NOT be released. As shown in {{VV18}}, even a partial leak of the plaintext without verification would facilitate chosen ciphertext attacks. + +All variants can be used as a MAC by calling the `Encrypt()` function with the message as the `ad` and leaving `msg` empty, resulting in just a tag. However, they MUST NOT be used as a hash function; if the key is known, inputs generating state collisions can easily be crafted. Similarly, as opposed to hash-based MACs, tags MUST NOT be used for key derivation as there is no proof they are uniformly random. + ## Security Guarantees AEGIS-256 offers 256-bit message security against plaintext and state recovery, whereas AEGIS-128L offers 128-bit security. From ee7c9d5a9d52fd9856305c3d9e919c34ba27c1d3 Mon Sep 17 00:00:00 2001 From: Frank Denis Date: Thu, 18 Jan 2024 18:14:11 +0100 Subject: [PATCH 3/9] Shuffle paragraphs around according to Samuel's feedback --- draft-irtf-cfrg-aegis-aead.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/draft-irtf-cfrg-aegis-aead.md b/draft-irtf-cfrg-aegis-aead.md index f164a22..8981b2a 100644 --- a/draft-irtf-cfrg-aegis-aead.md +++ b/draft-irtf-cfrg-aegis-aead.md @@ -1586,10 +1586,16 @@ AEGIS nonces match the size of the key. AEGIS-128L and AEGIS-128X feature 128-bi In all these variants, unused nonce bits can encode a key identifier, enhancing multi-user security. If every key has a unique identifier, multi-target attacks don't provide any advantage over single-target attacks. -### Additional Considerations +## Implementation Security If tag verification fails, the unverified plaintext and the computed message authentication tag MUST NOT be released. As shown in {{VV18}}, even a partial leak of the plaintext without verification would facilitate chosen ciphertext attacks. +The security of AEGIS against timing and physical attacks is limited by the implementation of the underlying `AESRound()` function. Failure to implement `AESRound()` in a fashion safe against timing and physical attacks, such as differential power analysis, timing analysis, or fault injection attacks, may lead to leakage of secret key material or state information. The exact mitigations required for timing and physical attacks also depend on the threat model in question. + +Regardless of the variant, the `key` and `nonce` are only required by the `Init` function; other functions only depend on the resulting state. Therefore, implementations can overwrite ephemeral keys with zeros right after the last `Update` call of the initialization function. + +### Additional Considerations + All variants can be used as a MAC by calling the `Encrypt()` function with the message as the `ad` and leaving `msg` empty, resulting in just a tag. However, they MUST NOT be used as a hash function; if the key is known, inputs generating state collisions can easily be crafted. Similarly, as opposed to hash-based MACs, tags MUST NOT be used for key derivation as there is no proof they are uniformly random. ## Security Guarantees @@ -1606,12 +1612,6 @@ AEGIS is considered secure against guess-and-determine attacks aimed at recoveri Security analyses of AEGIS can be found in {{AEGIS}}, {{M14}}, {{ENP19}}, {{LIMS21}}, {{JLD21}}, {{STSI23}}, {{IR23}}, {{BS23}}, and {{FLLW17}}. -## Implementation Security - -The security of AEGIS against timing and physical attacks is limited by the implementation of the underlying `AESRound()` function. Failure to implement `AESRound()` in a fashion safe against timing and physical attacks, such as differential power analysis, timing analysis, or fault injection attacks, may lead to leakage of secret key material or state information. The exact mitigations required for timing and physical attacks also depend on the threat model in question. - -Regardless of the variant, the `key` and `nonce` are only required by the `Init` function; other functions only depend on the resulting state. Therefore, implementations can overwrite ephemeral keys with zeros right after the last `Update` call of the initialization function. - # IANA Considerations IANA has assigned the following identifiers in the AEAD Algorithms Registry: From 7095f1702df19ae92897f55e8f3e8ff143175137 Mon Sep 17 00:00:00 2001 From: Frank Denis Date: Sat, 20 Jan 2024 13:04:27 +0100 Subject: [PATCH 4/9] Incorporate Samuel's feedback --- draft-irtf-cfrg-aegis-aead.md | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/draft-irtf-cfrg-aegis-aead.md b/draft-irtf-cfrg-aegis-aead.md index 8981b2a..fa077cc 100644 --- a/draft-irtf-cfrg-aegis-aead.md +++ b/draft-irtf-cfrg-aegis-aead.md @@ -1560,7 +1560,7 @@ A comprehensive list of known implementations and integrations can be found at [ ## Usage Guidelines -### Key And Nonce Selection +### Key and Nonce Selection All AEGIS variants MUST be used in a nonce-respecting setting: for a given `key`, a `nonce` MUST only be used once. Failure to do so would immediately reveal the bitwise difference between two messages. @@ -1594,7 +1594,7 @@ The security of AEGIS against timing and physical attacks is limited by the impl Regardless of the variant, the `key` and `nonce` are only required by the `Init` function; other functions only depend on the resulting state. Therefore, implementations can overwrite ephemeral keys with zeros right after the last `Update` call of the initialization function. -### Additional Considerations +## Additional Considerations All variants can be used as a MAC by calling the `Encrypt()` function with the message as the `ad` and leaving `msg` empty, resulting in just a tag. However, they MUST NOT be used as a hash function; if the key is known, inputs generating state collisions can easily be crafted. Similarly, as opposed to hash-based MACs, tags MUST NOT be used for key derivation as there is no proof they are uniformly random. @@ -1604,6 +1604,8 @@ AEGIS-256 offers 256-bit message security against plaintext and state recovery, Under the assumption that the secret key is unknown to the attacker, all AEGIS variants target 128-bit security against forgery attacks regardless of the tag size. +Encrypting a message with the same key and nonce but different additional data generates distinct ciphertexts that do not reveal any additional information about the message. + AEGIS has been shown to have reforgeability resilience in {{FLLW17}}. Without the ability to set the associated data, a successful forgery does not increase the probability of subsequent forgeries. AEGIS-128X and AEGIS-256X share the same security properties and requirements as AEGIS-128L and AEGIS-256 respectively. In particular, the security level and usage limits remain the same {{D23}}. From ad2b6e6a830d26e58654429385e3a495951c735e Mon Sep 17 00:00:00 2001 From: Frank Denis Date: Sat, 20 Jan 2024 13:07:27 +0100 Subject: [PATCH 5/9] Additional Considerations -> Other Uses of AEGIS --- draft-irtf-cfrg-aegis-aead.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/draft-irtf-cfrg-aegis-aead.md b/draft-irtf-cfrg-aegis-aead.md index fa077cc..2fb47d9 100644 --- a/draft-irtf-cfrg-aegis-aead.md +++ b/draft-irtf-cfrg-aegis-aead.md @@ -1580,6 +1580,10 @@ It is fully committing in the restricted setting where an adversary cannot contr Protocols mandating a fully committing scheme without that restriction can provide the associated data as input to a cryptographic hash function and use the output as the `ad` parameter of the `Encrypt` and `Decrypt` functions. The selected hash function must ensure a minimum of 128-bit preimage resistance. An instance of such a function is SHA-256 {{!RFC6234}}. +### Other Uses of AEGIS + +All variants can be used as a MAC by calling the `Encrypt()` function with the message as the `ad` and leaving `msg` empty, resulting in just a tag. However, they MUST NOT be used as a hash function; if the key is known, inputs generating state collisions can easily be crafted. Similarly, as opposed to hash-based MACs, tags MUST NOT be used for key derivation as there is no proof they are uniformly random. + ### Multi-User Security AEGIS nonces match the size of the key. AEGIS-128L and AEGIS-128X feature 128-bit nonces, offering an extra 32 bits compared to the commonly used AEADs in IETF protocols. The AEGIS-256 and AEGIS-256X variants provide even larger nonces. With 192 random bits, 64 bits remain available to optionally encode additional information. @@ -1594,10 +1598,6 @@ The security of AEGIS against timing and physical attacks is limited by the impl Regardless of the variant, the `key` and `nonce` are only required by the `Init` function; other functions only depend on the resulting state. Therefore, implementations can overwrite ephemeral keys with zeros right after the last `Update` call of the initialization function. -## Additional Considerations - -All variants can be used as a MAC by calling the `Encrypt()` function with the message as the `ad` and leaving `msg` empty, resulting in just a tag. However, they MUST NOT be used as a hash function; if the key is known, inputs generating state collisions can easily be crafted. Similarly, as opposed to hash-based MACs, tags MUST NOT be used for key derivation as there is no proof they are uniformly random. - ## Security Guarantees AEGIS-256 offers 256-bit message security against plaintext and state recovery, whereas AEGIS-128L offers 128-bit security. From 0a6f23fa75902ef7e0d806778b4d7a9018e43273 Mon Sep 17 00:00:00 2001 From: Frank Denis Date: Sat, 20 Jan 2024 13:27:43 +0100 Subject: [PATCH 6/9] Move Other Uses of AEGIS down --- draft-irtf-cfrg-aegis-aead.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/draft-irtf-cfrg-aegis-aead.md b/draft-irtf-cfrg-aegis-aead.md index 2fb47d9..cc83fbd 100644 --- a/draft-irtf-cfrg-aegis-aead.md +++ b/draft-irtf-cfrg-aegis-aead.md @@ -1580,16 +1580,16 @@ It is fully committing in the restricted setting where an adversary cannot contr Protocols mandating a fully committing scheme without that restriction can provide the associated data as input to a cryptographic hash function and use the output as the `ad` parameter of the `Encrypt` and `Decrypt` functions. The selected hash function must ensure a minimum of 128-bit preimage resistance. An instance of such a function is SHA-256 {{!RFC6234}}. -### Other Uses of AEGIS - -All variants can be used as a MAC by calling the `Encrypt()` function with the message as the `ad` and leaving `msg` empty, resulting in just a tag. However, they MUST NOT be used as a hash function; if the key is known, inputs generating state collisions can easily be crafted. Similarly, as opposed to hash-based MACs, tags MUST NOT be used for key derivation as there is no proof they are uniformly random. - ### Multi-User Security AEGIS nonces match the size of the key. AEGIS-128L and AEGIS-128X feature 128-bit nonces, offering an extra 32 bits compared to the commonly used AEADs in IETF protocols. The AEGIS-256 and AEGIS-256X variants provide even larger nonces. With 192 random bits, 64 bits remain available to optionally encode additional information. In all these variants, unused nonce bits can encode a key identifier, enhancing multi-user security. If every key has a unique identifier, multi-target attacks don't provide any advantage over single-target attacks. +### Other Uses of AEGIS + +All variants can be used as a MAC by calling the `Encrypt()` function with the message as the `ad` and leaving `msg` empty, resulting in just a tag. However, they MUST NOT be used as a hash function; if the key is known, inputs generating state collisions can easily be crafted. Similarly, as opposed to hash-based MACs, tags MUST NOT be used for key derivation as there is no proof they are uniformly random. + ## Implementation Security If tag verification fails, the unverified plaintext and the computed message authentication tag MUST NOT be released. As shown in {{VV18}}, even a partial leak of the plaintext without verification would facilitate chosen ciphertext attacks. From 2a9428ecdaffa657d3e590bca3f35173d4c08b9c Mon Sep 17 00:00:00 2001 From: Frank Denis Date: Sat, 20 Jan 2024 13:33:50 +0100 Subject: [PATCH 7/9] Sort references chronologically --- draft-irtf-cfrg-aegis-aead.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-irtf-cfrg-aegis-aead.md b/draft-irtf-cfrg-aegis-aead.md index cc83fbd..e026a56 100644 --- a/draft-irtf-cfrg-aegis-aead.md +++ b/draft-irtf-cfrg-aegis-aead.md @@ -1612,7 +1612,7 @@ AEGIS-128X and AEGIS-256X share the same security properties and requirements as AEGIS is considered secure against guess-and-determine attacks aimed at recovering the state from observed ciphertexts. This resilience extends to quantum adversaries in the Q1 model, wherein quantum attacks do not confer any practical advantage for decrypting previously recorded ciphertexts or achieving key recovery. -Security analyses of AEGIS can be found in {{AEGIS}}, {{M14}}, {{ENP19}}, {{LIMS21}}, {{JLD21}}, {{STSI23}}, {{IR23}}, {{BS23}}, and {{FLLW17}}. +Security analyses of AEGIS can be found in {{AEGIS}}, {{M14}}, {{FLLW17}}, {{ENP19}}, {{LIMS21}}, {{JLD21}}, {{STSI23}}, {{IR23}}, and {{BS23}}. # IANA Considerations From 978695dbb918363f18a1f0ec3a920925beb1c229 Mon Sep 17 00:00:00 2001 From: Frank Denis Date: Sat, 20 Jan 2024 14:04:58 +0100 Subject: [PATCH 8/9] Repeat "same" for clarity --- draft-irtf-cfrg-aegis-aead.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-irtf-cfrg-aegis-aead.md b/draft-irtf-cfrg-aegis-aead.md index e026a56..0980fe2 100644 --- a/draft-irtf-cfrg-aegis-aead.md +++ b/draft-irtf-cfrg-aegis-aead.md @@ -1604,7 +1604,7 @@ AEGIS-256 offers 256-bit message security against plaintext and state recovery, Under the assumption that the secret key is unknown to the attacker, all AEGIS variants target 128-bit security against forgery attacks regardless of the tag size. -Encrypting a message with the same key and nonce but different additional data generates distinct ciphertexts that do not reveal any additional information about the message. +Encrypting the same message with the same key and nonce but different additional data generates distinct ciphertexts that do not reveal any additional information about the message. AEGIS has been shown to have reforgeability resilience in {{FLLW17}}. Without the ability to set the associated data, a successful forgery does not increase the probability of subsequent forgeries. From 5bd83fcce9d50eb3587d2acfcb291ffba82cafb0 Mon Sep 17 00:00:00 2001 From: Frank Denis Date: Sat, 20 Jan 2024 14:54:22 +0100 Subject: [PATCH 9/9] additional data -> associated data --- draft-irtf-cfrg-aegis-aead.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-irtf-cfrg-aegis-aead.md b/draft-irtf-cfrg-aegis-aead.md index 0980fe2..338bd65 100644 --- a/draft-irtf-cfrg-aegis-aead.md +++ b/draft-irtf-cfrg-aegis-aead.md @@ -1604,7 +1604,7 @@ AEGIS-256 offers 256-bit message security against plaintext and state recovery, Under the assumption that the secret key is unknown to the attacker, all AEGIS variants target 128-bit security against forgery attacks regardless of the tag size. -Encrypting the same message with the same key and nonce but different additional data generates distinct ciphertexts that do not reveal any additional information about the message. +Encrypting the same message with the same key and nonce but different associated data generates distinct ciphertexts that do not reveal any additional information about the message. AEGIS has been shown to have reforgeability resilience in {{FLLW17}}. Without the ability to set the associated data, a successful forgery does not increase the probability of subsequent forgeries.