docs: update specification from manuscript 243f384

[cfm]

Updates the v0.3 specification to match the definitions and figures in manuscript 243f384. Since there are no major functional or conceptual changes, just dotting of i's and crossing of t's, let's consider this an in-place refinement of version 0.3, not a new version 0.4. Specifically, these changes address from #121....

From @felixlinker in #121 (comment):

• The results of signature verification are left implicit. It will be clear to most readers that one should abort if signature verification fails, but this should be made explicit.
• In Section 2, FPF signs the newsroom's key, but that signature is nowhere verified or referenced.
• In Section 6, the sender includes their $pk^{PKE}_S$ in the plaintext, but journalists have no such key.
• Signature verification is inconsistent with signature generation. The client verifies a signature by the journalist on three items: APKE key, PKE key, fetching key, but journalists never generate such a signature. Suggested fix: Include fetching key in the signature in Section 3.2.
• Removing journalist keys and adding source keys as the last step doesn't type-check. First (this is a nit), we remove three-tuples from $pks$, but $pks$ contains four-tuples. Second, journalists have sets of ephemeral key bundles - not a single one. One could have the journalist remove all key bundles which include their key as the verification key.
• The inclusion of $pk^{sig}_{NR}$ in "reply case" seems redundant. I think it should be removed there? I also don't underestand the case between "all senders" and "anyone" as this section will only be "executed" by senders anyways.

From @ssveitch in #121 (comment):

• I also would suggest writing up the key fetching a verification process as a separate subprotocol and clarify that this should happen whenever a source or journalist visits the instance (and then it can be made clear what happens when signature verification of these keys fails).
• The one thing that is still unspecified is what happens if a (source) recipient tries to verify that a message they decrypted comes from a valid journalist and this verification step fails. (I would guess they just ignore the message?)
• As discussed in a prior meeting, I would generate the source keys from the passphrase differently. Details can be copied from the paper.

Also:

• Closes document generic KGen() #114

[Copilot]

Pull request overview

This PR updates the protocol specification documentation to synchronize with manuscript version cf81f37. The update refines cryptographic notation, corrects key nomenclature (introducing vk for verification keys), adds detailed building blocks documentation, and restructures the protocol flow descriptions with improved clarity and mathematical rigor.

Key changes:

• Updated key notation to distinguish verification keys (vk) from public keys (pk)
• Added comprehensive "Building blocks" section documenting cryptographic primitives (SIG, AEAD, PKE, APKE)
• Restructured protocol flow sections with "Given/Then" format and improved tables
• Updated manuscript reference comments throughout (from 7944378 to cf81f37)

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

You can also share your feedback on Copilot code review for a chance to win a $100 gift card. Take the survey.

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated 9 comments.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

You can also share your feedback on Copilot code review for a chance to win a $100 gift card. Take the survey.

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated 6 comments.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

You can also share your feedback on Copilot code review for a chance to win a $100 gift card. Take the survey.

[rocodes]

@cfm this is a heroic amount of work, thank you. I have 2 comments about the overall protocol description, not about how faithfully you have represented the manuscript, but otherwise LVGTM:

• We need to specify how the info parameter is calculated (we have c2 + info, but maybe we clarify that as far as our last convo, it is a concatenation of c2 (encaps pq_psk_kem_ct) || receiver fetching pubkey (so sender commits to receiver fetch key).
• The way it's specified now, I think the same fetching key is signed $i$ times and included with every journalist one-time key bundle? But I think (and per prior discussion if I remember right) we would just sign it once, and it plus the journalist DH-AKEM reply key (two long-term keys) would be submitted to the server. Users would fetch a "welcome bundle" that includes all the long-term keys (newsroom key, newsroom sig over journalist signing keys, journalist sig over their own fetch+reply keys), and either at the same time or separately (depends if we're trying to add extra PoW?), the one-time journalist key bundles would be fetched, but those would just include the journalist signature over their (SD-APKE_E, SD-PKE_E) pubkeys.

[cfm]

@rocodes in #126 (review):

We need to specify how the info parameter is calculated (we have c2 + info, but maybe we clarify that as far as our last convo, it is a concatenation of c2 (encaps pq_psk_kem_ct) || receiver fetching pubkey (so sender commits to receiver fetch key).

Why don't I add a comment to make explicit that c2 + info is $c_2 \Vert info$, and then we can define the value of info in #124?

The way it's specified now, I think the same fetching key is signed $i$ times and included with every journalist one-time key bundle? But I think (and per prior discussion if I remember right) we would just sign it once, and it plus the journalist DH-AKEM reply key (two long-term keys) would be submitted to the server. Users would fetch a "welcome bundle" that includes all the long-term keys (newsroom key, newsroom sig over journalist signing keys, journalist sig over their own fetch+reply keys), and either at the same time or separately (depends if we're trying to add extra PoW?), the one-time journalist key bundles would be fetched, but those would just include the journalist signature over their (SD-APKE_E, SD-PKE_E) pubkeys.

Good point. I'll open a follow-up ticket.

[rocodes]

I was taking for granted that c2 + info means $c_2||info$ :) I think we require a definition for clarity, even a working one, because I think info = c2 || info is circular, and since we're now (maybe?) using this as canonical and getting feedback from ethz, I don't think it's necesarily better to punt it until it appears in the manuscript.

But if you object, then maybe we can at least leave in a comment what our working definition is, so that people can fact check all/as many as possible assumptions in one place :)

[cfm]

Ah, I see! Let me tack that on.

[cfm]

NB. This isn't circular: pskAEnc()'s keyword argument info takes the concatenation of the local variable c2 and the enclosing AuthEnc()'s positional argument info, which is where we pass $pk_R^{fetch}$:

securedrop-protocol/docs/protocol.md

Line 436 in 98511c2

| $`ct^{APKE} \gets \text{SD-APKE.AuthEnc}(sk_S^{APKE}, pk_{R,i}^{APKE}, pt, NR, pk_R^{fetch})`$ | | |

[cfm]

Confirmed as of manuscript 243f384.

[rocodes]

My comment about circularity was that we could distinguish terms a bit, as in, we could call one $info`$ or something for readability. However, I don't have strong feelings.

[cfm]

ab3ae02 brings us to manuscript 243f384, resolving this TODO:

securedrop-protocol/docs/protocol.md

Line 471 in 4954b80

| $`\forall C_k = (id_k, C_{S_k}, X_k, Z_k):`$ **TODO:** pad up to $n$ total challenges | | |

[rocodes]

Thanks for the extra commits! I think this is looking really good, the only thing still outstanding to me is the repeated fetching key signatures section. I saw you filed it as a separate issue, which is fine, but I still think we shouldn't merge it into main if it's not our desired behaviour, because it will be confusing for people trying to follow along.

I'd suggest we do any of: specify the behaviour as we understand it from our discussions; leave it as is but add a visible "under construction" comment/warning in that section of protocol.md explaining the discrepancy and/or that it's WIP so that people don't take it as canonical while we clarify; or move the PR to "blocked or waiting". I'd like to merge it so I'd kind of be in favour of the first or second options, but I leave it to your discretion.

Thank you again :)

[cfm]

@rocodes in #126 (review):

the only thing still outstanding to me is the repeated fetching key signatures section. I saw you filed it as a separate issue, which is fine, but I still think we shouldn't merge it into main if it's not our desired behaviour, because it will be confusing for people trying to follow along.

I'd suggest we do any of: specify the behaviour as we understand it from our discussions; leave it as is but add a visible "under construction" comment/warning in that section of protocol.md explaining the discrepancy and/or that it's WIP so that people don't take it as canonical while we clarify; or move the PR to "blocked or waiting". I'd like to merge it so I'd kind of be in favour of the first or second options, but I leave it to your discretion.

Sure. How's c8dd13a, so that we can coordinate the changes both here in the spec and "upstream" in the manuscript around #127?

[rocodes]

Thank you - LGTM