Issues in SecureDrop Protocol Specification

[felixlinker]

The latest iteration of the SecureDrop protocol specification has some issues.

• Signatures do not include message tags.
• 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.

Issues in Section 5:

• 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.
• It is unclear which $pk^{APKE}_{R,i}$ is sent to the client. I know it's the ephemeral key, but this is not explicit. Suggested fix: Instead of saying "Store ... for $J$", store them in some variable or say "Store ... as key bundle for $J$" and then later say "for all key bundles" (instead of "for all i").
• 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.

[cfm]

Thanks, @felixlinker! These are exactly the kinds of gaps we wanted #92 to reveal. I'll propose revisions to close them next week.

[rocodes]

Thanks @felixlinker, this is super helpful! we talked a bit about "abort if verification/decryption fails" being implied but not specified last week as well, it will be great to decide how much detail we spend there or if we state somewhere a more general assumption like "on verification/decryption error, the user stops." I think for implementation we will want very unambiguous instructions for implementors to avoid oracles/side channels etc, but I defer to others re how much detail we should have at this stage.

Re underspecified/inaccurate areas: as a more general comment on doing this work, I find it helpful when we write down our understanding of the intended behaviour in "plain" language before translating it into symbols so that we can clarify what's a notation error vs what's actual gap in the protocol, and for any followup work (eg attachments protocol), I'd maybe ask of the FPF folks that we do a quick bullet point sketch as a first step and get a shared signoff on that, just to make sure there are no missing pieces before the more formal drafting?

(This is my understanding of the points felix raised, to that end - open to correction, and we can discuss next time we meet as well if that's better)

• Signature inconsistency: the client should first verify (FPF's signature over NR key, if available, then NR signature over all journalist signing keys, then journalist signature over their own fetching key and dh-akem reply key). Then when the client (sender) gets a one-time key bundle of a recipient's ((DH_AKEM, PQ_PSK_MLKEM), HYBRID_METADATA_XWING)) keys, which iiuc we're calling (SD-APKE, SD-PKE), this bundle comes with a self-signature, which they verify and ascertain is part of the set of keys found in the first step.
• Thank you for the one-time / key bundle notation fixup, appreciated
• I think the "removing journalist key-bundle/swap with source" comes from the manuscript's notation, maybe we can sync up next time to figure out the best way to express that (we talked last time about whether we'd send $n$ or $n+1$ messages so this seems like a good followup)
• NR sig in reply case: agree with you, this is probably a holdover from when the NR signed all the journalist's keys (from Luca's thesis)

thank you again :)

[ssveitch]

Just a few more things...

• I would not use overlapping notation for the signatures of the long-term journalist keys and the signatures on the ephemeral ones. It's a bit easier to distinguish if you use different notation.
• 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.