define message and ciphertext structures for de/serialization

[cfm]

This is a stub ticket for the record, prompted by recent conversations with @felixlinker and:

securedrop-protocol/docs/wip-protocol-0.3.md

Line 92 in a0252a8

- Still for discussion: Message (plaintext) structure. Includes at minimum the pubkeys needed for replies, but could also include NR key/identifier (avoid cross-instance replays), additional application-level metadata.

securedrop-protocol/securedrop-protocol/benches/encrypt_decrypt.rs

Lines 78 to 86 in 71073e5

	// Plaintext metadata
	pub struct Metadata {
	pub sender_pubkey_bytes: [u8; LEN_DHKEM_ENCAPS_KEY],
	pub pq_psk_ss_encaps: [u8; LEN_MLKEM_SHAREDSECRET_ENCAPS],
	pub dhakem_ss_encaps: [u8; LEN_DHKEM_SHAREDSECRET_ENCAPS],
	}
	// TODO: NOT FOR PROD, parsing untrusted ct
	impl Metadata {

[rocodes]

Updated notes after #86 (comment) / #116:

What we call "Envelope" is the entire payload to the server when sending a message. (It's $(C, Z, X)$ in the manuscript).

The last 2 components, $Z, X$ are the (DH) clue; $C$ is the concatenation of all the ciphertext and includes
(1) dhakem_shared_secret_encaps || pq_psk_kem_shared_secret_encaps || authenc_message_ciphertext + (2) metadata_encaps_shared_secret || metadata_ciphertext. The respective SD-APKE and SD-PKE output each of these.

We're calling "Message" the plaintext structure that contains the plaintext and any additional info that will be serialized and encrypted using SD-APKE AuthEnc. It's the least well specified, coming back to it in a sec.

What we called "Metadata" (named this way because the HPKE RFC 9.9 strategy for encrypting the dh-akem key and optionally the psk id in authenc constructions is called Metadata Protection, but maybe it's not the best name) is just the sender dh-akem pubkey needed to decrypt the message.

Plaintext

Metadata {
    dh_akem_sender_bytes;
}

# this is the part that needs the most figuring out!
Message { 
    plaintext;
    some_sort_of_id_or_timestamp; # tbd what kind of application level info we want here
    sender_reply_key_pq_psk_kem; # if source is sender, attach keys needed to receive replies
    sender_reply_key_metadata_xwing; # if source is sender, attach keys needed to receive replies
    recipient_fetch_key_commitment; # tbd, could be including recipient fetching key
    # newsroom_id is included in the KDF, any reason to include it here?
    # sender_dhakem_key is covered already; key is attached in other ciphertext, hpke authopen will fail for wrong key
    # ? anything else: eg do we need a recipient xwing key commitment?
    # ? versioning format, anything we could need for application level design and maintainability? 
}

This presumes that signatures over journalist keys are fetched when pubkeys are fetched (ie a signature over a one-time key bundle, or a signature over a fetching/reply key) and so they aren't attached inside a message (may need more discussion with #32 ).

[rocodes]

Related: #122 (comment)