Update ciphersuite in docs

Signed-off-by: Brooklyn Zelenka <hello@brooklynzelenka.com>

Author: expede

design/ciphersuite.md

@@ -3,18 +3,9 @@
 | Feature           | Algorithm                 |
 |-------------------|---------------------------|
 | Hash              | BLAKE3                    |
-| Symmetric Crypto  | [XChaCha20-BLAKE3-MiCKey] |
+| Symmetric Crypto  | [XChaCha20-Poly1305]      |
 | Asymmetric Crypto | Curve25519, EdDSA, X25519 |
 
-## XChaCha20-BLAKE3-MiCKey
-[XChaCha20-BLAKE3-MiCKey]: #xchacha20-blake3-mickey
-
-(Where "MiCKey" provisionally stands for "Misuse-resistant and Committed Key")
-
-This is a key committing, nonce misuse-resistant variant of [XChaCha20-BLAKE3] [^bchacha-note].
-
-[^bchacha-note]: Why not SChaCha or BChaCha? These look even better, but we're starting to increase the amount of custom crypto that we're rolling. The reasons for the enhancements in these variants make sense, but we're not going to (e.g.) implement our own library that doesn't include HChaCha.
-
 ### Key Commitment & Misuse Resistant Nonces
 
 > [!CAUTION]
@@ -45,24 +36,18 @@ This strategy also commits to a specific key (and redundantly commits to the mes
 
 Note that to avoid allocating space for the entire payload in the nonce preimage (on creation and validation), we first hash the content.
 
-> [!NOTE]
-> The extra hash step mentioned above may be superfluous, need to double check
->
-> — expede
-
 (Keyed) BLAKE3 by default produces 32-bytes of output. While we could keep this entire value as the nonce, to conform to XChaCha20 we truncate it to 24 bytes (196-bits).
 
 ## Sub-Protocols
 
 | Feature                  | Algorithm                                                                             |
 |--------------------------|---------------------------------------------------------------------------------------|
 | Group Definition         | Capability Graphs                                                                     |
-| Read Group Key Agreement | DCGKA ("Duckling")                                                                    |
-| Read Access Revocation   | DCGKA's in-built PCS mechanism                                                        |
-| Transitive Read Access   | DCGKA + Capabilities                                                                  |
+| Read Group Key Agreement | BeeKEM (Continuous Group Key Agreement)                                               |
+| Read Access Revocation   | BeeKEM's in-built PCS mechanism                                                       |
+| Transitive Read Access   | BeeKEM + Capabilities                                                                 |
 | Granular Edit Access     | Modified (partition tolerant) OCap, predicate attenuation                             |
 | Edit Revocation          | Causality locking, backdating detection, default to "whiteout" (skip materialization) |
 
 <!-- External Links -->
 [encryptment]: https://eprint.iacr.org/2019/016.pdf
-[XChaCha20-BLAKE3]: https://kerkour.com/chacha20-blake3#xchacha20-blake3