Update protocol.md with journalist dh-akem reply key and journalist self-signing procedure

[rocodes]

Description

• Add dh-akem journalist reply key to table.
• Update table headers a bit: I'd to preserve an at-a-glance way to see what specific parameter choices have been made, and I think saying SD-APKE is less clear at a glance than saying DHAKEM(X25519, HKDF-SHA256), so I've adjusted the headings a bit to make room for both types of information.
• Update enrollment and table entry to Include journalist self-signing procedure for long-term reply key and fetching key. (The footnote that this is under discussion is preserved, but since it looks like this is the direction we are trying to go for, indicate that here so there's no ambiguity about our intention).
• Closes switch Diffie‒Hellman operations from plain Curve25519 to Ristretto #100

Checklist

• base branch is message-enc-flow-doc (I sorely regret the name)
• Visual review
• mermaid diagram looks ok - not my strong suit

[rocodes]

lint is failing due to changes unrelated to this commit - I'll push to the base branch

[cfm]

Update table headers a bit: I'd to preserve an at-a-glance way to see what specific parameter choices have been made, and I think saying SD-APKE is less clear at a glance than saying DHAKEM(X25519, HKDF-SHA256), so I've adjusted the headings a bit to make room for both types of information.

Nice. How would you feel about (here or in a follow-up) breaking up the columns like so (e.g.):

Owner	Private key or decapsulation	Public key or encapsulation	Usage	Purpose	Direction	Lifetime	Algorithm	Signed by
Journalist	$J_{apke,sk}$	$J_{apke,pk}$	SD-APKE	Message encryption	Outgoing	Long-term	DH-AKEM(X25519, HKDF-SHA256)	$J_{sig,sk}$

That way the (Usage, Purpose) tuple lines up with how the APIs are documented after #102, and the (Usage, Direction) tuple is clearer.

[cfm]

Sorry; I know the lack of proper notation, especially super- and subscripts, makes this diagram hard both to read and revise. (I'm holding out hope for #80.) If I understand your intentions right, I think this diff can be simplified to:

Suggested change

	Journalist ->> Journalist: generate J{sig},sk,pk
	Journalist ->> Newsroom: J{sig},pk
	Newsroom ->> Journalist: σNR := newsroom's signature on J{sig},pk
	Journalist ->> Journalist: generate J{fetch},sk,pk and J{dh},sk,pk
	Journalist ->> Journalist: σJ := signature over J{fetch},pk and J{dh},pk using J{sig},sk
	Journalist ->> Server: J{sig,fetch,dh},pk<br>σNR, σJ
	Journalist ->> Newsroom: Jsig,pk := journalist's signing key
	Newsroom ->> Journalist: σNR := newsroom's signature on Jsig,pk
	Journalist ->> Journalist: J{fetch,dh},pk := journalist's long-term keys
	Journalist ->> Journalist: σJ := signature over J{fetch,dh},pk using Jsig,sk
	Journalist ->> Server: J{sig,fetch,dh},pk<br>σNR, σJ

In other words:

• Jsig,pk is a spelling of $J_{sig,pk}$
• J{fetch,dh},pk is a shorthand for $J_{fetch,pk}, J_{dh,pk}$
• Generation of private keys is implicit (but we could make it explicit throughout!)

[cfm]

I've added a note at the top that this will close #100!

[cfm]

Nice. Thanks, @rocodes!