Clarify ristretto255 and journalist fetching key usage

[rocodes]

Description

• Clarify where we use ristretto255 keys as opposed to plain curve25519. For now this avoids talking about the curve25519 keys in dh-akem; this is just about the fetching key and ephemeral clue keys. The intention is to at minimum convey our use of ristretto255 for fetching and the fetching challenges. Terminology/notation not my strong suit so please feel free to make adjustments if it's clunky (cc @redshiftzero)

• In addition, clarify that the fetching key is signed+sent once, on enrollment, and is not part of every journalist one-time key bundle (sign each journalist's fetching key once and return in "welcome bundle" #127)

Fixes #127
Fixes #128

[cfm]

Thanks, @rocodes! Looks great; no substantive changes here, just proofreading for consistency.

[cfm]

Two further notes here from #156, which builds on this branch:

• Clarify where we use ristretto255 keys as opposed to plain curve25519. For now this avoids talking about the curve25519 keys in dh-akem; this is just about the fetching key and ephemeral clue keys. The intention is to at minimum convey our use of ristretto255 for fetching and the fetching challenges. Terminology/notation not my strong suit so please feel free to make adjustments if it's clunky (cc @redshiftzero)

#156 (comment)

• In addition, clarify that the fetching key is signed+sent once, on enrollment, and is not part of every journalist one-time key bundle (sign each journalist's fetching key once and return in "welcome bundle" #127)

I took the liberty of adding a TODO for the welcome bundle itself, which I don't believe is specified yet despite the reference to #127? In the interest of getting this and #156 in sooner rather than later, I'd be happy to draft that this sprint.

[rocodes]

@cfm thank you for review! I'll push changes presently. re comments:

• The "welcome bundle" as far as the protocol is concerned is RequestKeys in step 5, so I think we're ok unless you think we should add more details
• Re co-pilot's suggestion about my footnote, I don't think it's better/clearer? I can just change it to "Fetching KeyGen uses the Ristretto255 prime order group" if that works for you? I just want it to be as simple and clear as possible

[cfm]

• The "welcome bundle" as far as the protocol is concerned is RequestKeys in step 5, so I think we're ok unless you think we should add more details

Ah, yes: $pk_J^{fetch}$ is still retained per J, just not per J_i. I'd somehow gotten it into my head that the "welcome bundle" idea implies a new per-session request in addition to the per-message RequestKeys. But I see now that that's more like #56 (comment) and not necessary here.

• Re co-pilot's suggestion about my footnote, I don't think it's better/clearer? I can just change it to "Fetching KeyGen uses the Ristretto255 prime order group" if that works for you? I just want it to be as simple and clear as possible

Sure; just thought I'd pass it along. I think it's just being finicky about what it means to restrict the KDF() output to Ristretto. I'll defer to you (and rebase all of #156 with whatever you decide here).

[cfm]

Simpler to keep the text out of LaTeX (but by all means let's keep the comment if you think we should document this divergence):

Suggested change

	[^8]: $\mathbb{Z}_\ell \text{ (ristretto255 scalar field)}$.
	<!-- In protocol manuscript, $\mathcal{E}_H \subset \mathbb{Z}$ per Definition 4 of Alwen et al.
	(2020), ["Analyzing the HPKE Standard"][alwen2020]. -->
	[^8]: $\mathbb{Z}_\ell$ (ristretto255 scalar field).

[rocodes]

I'm gonna keep it if you don't hate it because it is a place where I'm using "formal" ish notation that isn't in the paper, and our future selves could ask "why" and then be glad we found this later.

The paper uses $\mathcal{E}_H \subset \mathbb{Z}$ to take advantage of pre existing proofs, but we restrict things further than that. This might not be the exact right or necessary way to explain it ("cryptographers hate this one weird trick?" :/) so I'm open to revising later, eg based on @redshiftzero or anyone's feedback, but I was trying to make sure it's clear that we know there's a difference and we are consistent throughout that if we say ristretto, we don't just say $\mathbb{Z}$

[rocodes]

When I asked S about this, the comment was "it makes sense for the spec and the notation we use to diverge, and you might want to just use algorithms instead of the abstraction layer". I think we like the link to the abstractions so that people can cross-reference the docs, but just trying to kind of meet both needs I guess

[rocodes]

Rebased; kept ristretto255.KGen() even though I acknowledge it doesn't fit the exact same pattern we use everywhere; addressed other comments (I think/hope)!

[cfm]

Thanks, @rocodes—including for workshopping it with me.