FYI, OCaml has great, imo the best, primitives (modules, functors, etc.) to build modular/swappable software.
If you need a case-study, there’s this excellent paper by CMU’s Fox project about building more complex layered network protocols in SML by leveraging the power of functors: [url: http://www-2.cs.cmu.edu/Groups/fox/papers/lfp-signatures.ps <http://www-2.cs.cmu.edu/Groups/fox/papers/lfp-signatures.ps> | md5: faf082f1f13bba60bd966c23a22c2856]. Note that SML is OCaml’s ancestor. The concepts and the approach are nonetheless relevant to what you’re trying to achieve. > On Oct 10, 2017, at 19:14, Nazar Mokrynskyi <na...@mokrynskyi.com > <mailto:na...@mokrynskyi.com>> wrote: > > Great suggestions and thanks for reading it! > > This is the first time me writing some sort of protocol for wider use, so I'm > just learning how to do it. > Specification document is now reduced in size and > https://github.com/nazar-pc/ronion/blob/master/design.md > <https://github.com/nazar-pc/ronion/blob/master/design.md> is added with > design overview and some diagrams, hopefully it makes more sense this way. > Security and anonymity properties of the protocol are largely influenced by > crypto in use and the way intermediate hops (nodes) are selected, so the > framework should just combine them in non-vulnerable way, which is why I > don't think it is appropriate to talk about anonymizing quantitatively here > (changed the wording in design document to reflect this). > Sincerely, Nazar Mokrynskyi > github.com/nazar-pc <http://github.com/nazar-pc> > On 10/10/17 2:48 PM, Ximin Luo wrote: >> A specification is a document for implementors, after the ideas it >> implements have already been well-tested and proven. And looking at your >> text, that's what it's written from the perspective of - instructions on how >> to write code. However this sort of text is less suitable for reviewers to >> read, to check that the ideas are sound security-wise. >> >> It would be good to produce a more high-level document that describes (1) >> how the protocol works, i.e. the abstract purpose of each packet being >> sent/received and of any subroutines of the protocol, as well as the >> security properties you're (2.a) assuming from lower layers and (2.b) are >> providing to higher layers. >> >> There is a "goals" and "assumptions" section, which starts to answer (2.a) >> and (2.b), however the rest of the document doesn't explain how each step of >> the protocol achieves these goals and uses these assumptions. Also these >> could be filled out in detail a bit: >> >> - "The only assumption about transport layer is that it delivers data in the >> same order as the data were sent" - You can't simply assume this, because >> it's not secure. Granted, most crypto schemes implicitly have some level of >> ordering guarantee. However, you have to specify that (it was not clear to >> me if you did). For example, naive EBC-like encryption where you >> encrypt+auth each packet the same way doesn't work, you have to include a >> counter in there somewhere, or some other order-preserving measure *inside* >> the authentication. >> >> - "anonymizing the connection" - Could you define "anonymizing" more >> quantitatively? There are various definitions in various research papers >> that are all publicly available and easy to find. >> >> - "hiding exact number/size" - many attacks vs anonymity don't need the >> exact number or sizes of anything, they build up a probability distribution >> based on what they've observed. >> >> X > _______________________________________________ > Messaging mailing list > Messaging@moderncrypto.org <mailto:Messaging@moderncrypto.org> > https://moderncrypto.org/mailman/listinfo/messaging
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Messaging mailing list Messaging@moderncrypto.org https://moderncrypto.org/mailman/listinfo/messaging
