real-or-random
commented
4 months ago I wonder how to best argue about security (e.g. security of one-time pad in encpedpop, proofs of certifying_eq) without having the code available in the markdown.
Yeah, that's a valid point. I don't know. If nothing else works, it's certainly an option to bring some essential parts of the code back later (or pseudocode variants of it), or simply add link to specific lines, once the code is more stable. I guess we can postpone this to the future. Right now, this PR helps us finish the code, and we can reevaluate after this is done.
This is one possible implementation of the idea in #20. This so far just changes the structure, we'll still need to write some text to explain the function signatures (but we'll need some text anyway).
What do you think?
edit: As a follow-up to this, we could then improve the coding standards a bit, because then we have easier access to tools (code formatter, linter... e.g., https://docs.astral.sh/ruff/ is a simple and modern all-in-one tool).
I also suggest that we then add some more structure to the code (modules, classes, ...) to turn it the spec more into a prototype implementation instead of "extended pseudocode". I feel it's appropriate for a protocol of this complexity, but also note that it's essentially independent of this PR, and I think this PR makes sense even if we don't want to do this.