XChaCha20 with key ratcheting and multi-recipient DEM.
[cm/encrypted/]'s "/dem/a" equals to "xchacha-krmr".
CEK consists of common 64-bytes part equal in all KEMs (CEK itself),
and 64 bytes long per-KEM/per-recipient random MAC key (prMACx).
Data is split on 128 KiB chunks, each of which is encrypted the following way:

    H = BLAKE2b
    CK{-1} || prMACx{-1} = CEK
    CKi = HKDF-Expand(H,
        prk=HKDF-Extract(H, salt="", ikm=CK{i-1}),
        info="cm/encrypted/xchacha-krmr/kr")
    prMACxi = HKDF-Expand(H,
        prk=HKDF-Extract(H, salt="", ikm=prMACx{i-1}),
        info="cm/encrypted/xchacha-krmr/mr")
    KEY = HKDF-Expand(H, prk=CKi, info="cm/encrypted/xchacha-krmr/key")
    IV = HKDF-Expand(H, prk=CKi, info="cm/encrypted/xchacha-krmr/iv", len=24)
    if {last chunk} then { IV[23] |= 0x01 } else { IV[23] &= 0xFE }
    CIPHERTEXT = XChaCha20(key=KEY, nonce=IV, data=chunk)
    MACx = BLAKE2b-256-MAC(key=prMACxi, H(CIPHERTEXT))
    CIPHERTEXT || MACx || MAC{x+1} [|| MAC{x+2} ...]

Chaining key (CK) and per-recipient MAC (prMAC) key advance with every
chunk. 256-bit encryption key and randomised 192-bit nonce
(initialisation vector) are derived from chaining key.

Nonce's lowest bit is set only if this is the last chunk we encrypting.

MACs are ordered the same way as KEMs in the list.

"/payload"'s chunk length equals to 128KiB+16+32*recipients bytes.

=> https://datatracker.ietf.org/doc/html/rfc5869.html RFC 5869, HKDF
=> https://datatracker.ietf.org/doc/html/rfc7693.html RFC 7693, BLAKE2b
=> https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-xchacha.html XChaCha20-Poly1305 AEAD
=> https://datatracker.ietf.org/doc/html/rfc8439.html RFC 8439
