specify NR/NewsroomID

[cfm]

#110 (comment)

[rocodes]

So basically, if a newsroom's key changes, its ID changes? I wonder if we should instead go the other way and have a static unchanging ID that is signed somewhere by the newsroom. The NR ID is fed into a KDF, so if a newsroom rotates their signing key, it would have to simultaneously publish 2 IDs for the message expiry period of time, or all users would have to store the old id/old signature hash to be able to decrypt messages signed when a prior NR was in use, which could be confusing.

[edit: See my comment below]

[felixlinker]

What about: Link to the SecureDrop instance web interface with a self-authenticating domain name (https://ieeexplore.ieee.org/document/8901582), that is a subdomain of the news organizations domain name. For example d3adb33f.nytimes.com for nytimes.com. nytimes.com links to that domain name, and nytimes.com is the newsroom ID. Very short description. Happy to elaborate if you're curious :)

[rocodes]

I read the self-authenticating domains paper, thought about options, and talked briefly to @lsd-cat a couple weeks ago about this, and I need to retract with apologies my initial skepticism of the approach @cfm proposed, I think I agree with his approach.

• I'm a bit hesitant about the self authenticating domains approach. Onion urls are more likely to change than the NR key, and can be rotated by instances fairly readily now (for spam reasons, because the tor keys have a different security model than the interactions with sources, for major onion service version upgrades, etc). Even if there was a non-subdomain-based self-authenticating domain method, we might not want to couple the protocol to a transport layer that tightly.
• If the NR id isn't derived from a pubkey, then a malicious autonomous instance has an easier time impersonating a legitimate SecureDrop by duplicating their nr id, and relaying messages from sources.
• While the NR key does sometimes change now, that's in part a function of the existing architecture (wanting to rotate the [shared] submission private key). There will still be edge cases to consider where a NR will rotate their key, but but it's probably better to manage them than it is to try to have a smooth experience that's less resistant to message swapping attacks.
  • Specifically: Newsroom rotates key, but there are still pending (undecrypted) messages for either source or journalist where the old NR id must be supplied to decrypt. This is manageable (NR id is public and small, we can fall back to the old ID for the duration of the message expiry period if the message fails to decrypt using the new NR id).

[Copilot]

Pull request overview

This pull request adds explicit definitions of the newsroom identifier NR in three protocol sections where it's used as a parameter in cryptographic operations. The change specifies that NR = \text{Hash}(vk_{NR}^{sig}), clarifying that the newsroom identifier is the hash of the newsroom's signing verification key.

Changes:

• Added NR definition to section 5 (Sender fetches keys and verifies their authenticity)
• Added NR definition to section 6 (Sender submits a message) and removed redundant text
• Added NR definition to section 7 (Receiver fetches and decrypts messages)

---

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

[cfm]

Rebased from main for #138 and updated key notation per #126.

[cfm]

Just FYI, @lsd-cat, since this is now in conflict with main after #135, review can just be on the merits of this approach. After #117 (comment), it won't land until v0.4 anyway, so I'll mark it as draft.

[rocodes]

Updating after our last meeting - we discussed that it might make more sense to consider the question "is the NR ID deterministically derived from some sort of key material vs is it a random string", instead of going implementation-specific, at this stage, and I'm putting in my vote in favour of that rather than a specific implementation (for the same reasons raised above) - thank you @lsd-cat for the discussion and raising that point.