An attempt at organizing the remaining paragraphs

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 2<sup>48<
 
 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 ~2<sup>64</sup> attempts with a 128-bit authentication tag and ~2<sup>128</sup> 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.