cm/encrypted/

    Encrypted container, some kind of analogue to ASN.1-based CMS
    EnvelopedData, LibrePGP or age.
    => CMS
    => LibrePGP
    => age

    * Ability to use multiple recipients
    * Either passphrase- or public-key based KEMs
    * Hybrid PQ/T KEMs
    * Ability to authenticate the sender
    * Optionally anonymous recipients and sender
    * Streaming friendly
    * Ability to parallelise encryption/decryption procedures
    * Current DEM schemes do explicit key commitment
    * Current DEM schemes use key ratcheting and rotation
    * Ability to safely encrypt to multiple recipients

    Stored in a file, it should begin with "cm/encrypted" [encoding/MAGIC].

        encrypted {
            {field . {map}}
            {field dem {with dem}}
            {field kem {list} {of kem} >0}
            {field id {hexlet} optional}
            {field payload {bin} optional}
            {field pubs {list} {of type map} optional >0} {# attached public keys}
        }

        dem {
            {field . {map}}
            {field a {str} >0} {# xchapoly-krkc}
                               {# xchacha-krmr}
                               {# kuznechik-ctr-hmac-kr}
        }

        kem {
            {field . {map}}
            {field a {str} >0}
            {field cek {bin} >0}
        }

        schema-include fpr.tcl
        schema-include kem-with-encap.tcl
        schema-include kem-gost3410-hkdf.tcl
        schema-include kem-balloon-blake2b-hkdf.tcl
        schema-include kem-pbkdf2.tcl

    "/payload" contains the ciphertext. It is encrypted with random "content
    encryption key" (CEK) with an algorithm specified in "/dem/a" (data
    encapsulation mechanism). "/dem" may contain additional fields
    supplementing the decryption process, like initialisation vector.

    If "/payload" is absent, then ciphertext is provided by other means, for
    example just by following the "cm/encrypted" structure. It is recommended
    to encode it as a BLOB, which chunk's length depends on DEM algorithm.

    CEK is encapsulated in "/kem/*/cek" entries (key encapsulation
    mechanisms), using "/kem/*/a" algorithm.

    If KEM uses public-key based cryptography, then recipient's
    [cm/pub/]lic key(s) must be provided. Optional "/kem/*/to", public key's
    fingerprint, may provide a hint to quickly search for the key on the
    recipient's side.

    Optional "/id" is used in KEMs for domain separation and envelope
    identification. UUIDv4 is recommended.
    If absent, then null UUID is used in KDF.

    [cm/encrypted/authcrypt] -- authenticated public-key encryption
    [cm/keywrap/] | key wrapping mechanisms
    [cm/dem/]     | data encapsulation mechanisms
    [cm/kem/]     | key encapsulation mechanisms