Implemented newer message fetching mechanism; minor code refactoring; major documentation refactoring #17
Conversation
There was a problem hiding this comment.
@lsd-cat, per https://freedomofpress.slack.com/archives/C123KPJ1X/p1697658988775359 I've performed a documentation-focused "review" as follows:
- readme
- text
- notation
- diagram
- code
- skimmed
- read exhaustively
- played with locally
Along with the suggestions I've left inline, I'm "approving" this pull request (a) because this is great work! and (b) so that you can merge it when you're ready. As always, please take what's useful to you and leave the rest! And let me know if you'd like me to do more of the above or follow up with any concrete changes.
imgs/sd_schema.png
Outdated
There was a problem hiding this comment.
Still refers to challenges, where the readme and code now uses gdh. I know we're still finalizing terminology—just noting the discrepancy for now.
There was a problem hiding this comment.
Thanks, I did a full review of the schema and had to do significant changes to bring the terminology more consistent and fix a few errors especially related to for cycles superscripts.
| * *JC<sub>SK</sub>*: Long term Journalist message-fetching private key | ||
| * *JC<sub>PK</sub>*: Long term Journalist message-fetching public key | ||
| * *JE<sub>SK</sub>*: Ephemeral per-message key-agreement private key | ||
| * *JE<sub>PK</sub>*: Ephemeral per-message key-agreement public key |
There was a problem hiding this comment.
Seeing these keys listed out this way, for message-fetching and group key agreement, is clarifying. It helps me understand that where before we were talking about a two-step interactive protocol that achieves the desired mechanism (challenge/response), we're now talking about a composition of two cryptographic negotiations that achieve the desired properties (three-party enumeration, two-party retrieval).
| 4. *Source* generates the unique passphrase randomly *PW = G()* (the only state that identify the specific *Source*) | ||
| 5. *Source* derives *S<sub>PK</sub>, S<sub>SK</sub> = G(KDF(encryption_salt + PW))* | ||
| 6. *Source* derives *SC<sub>PK</sub>, SC<sub>SK</sub> = G(KDF(challenge_salt + PW))* | ||
| Only a source can initiate a conversation; there are no other choices as sources are effectively unknown until they initiate contact first. |
There was a problem hiding this comment.
Would it be worth making explicit the other places where the same operation (sending/replying, fetching, reading) are not symmetrical? Right now that requires carefully reading (e.g.) the Journalist message id fetching protocol and Source message id fetching protocol sections and comparing them line by line.
(I can propose text if helpful!)
There was a problem hiding this comment.
Sure thing, feel free to suggest the text where you think it is more appropriate. I have added colors to the diagram so that it is more clear that the server side is symmetrical, while the client functions are not.
There was a problem hiding this comment.
https://github.com/freedomofpress/securedrop-poc/blob/8776722eab78a6fc446f97e2d0d147644c59b54b/imgs/sd_schema.png is perfect, because it can be read comparatively. I've proposed making that comparison explicitly in #18.
|
Note that there are still some discrepancies in subscripts between the chart and the text description. It is not super relavant, as i/j/n are just placeholders, but it would be nice to match them everywhere. |
See #16