+1 for OCaml, although its ecosystem is way undermaintained. Nadim Sent from my computer
> On 10 Oct 2017, at 9:18 PM, Erwan Ounn <erwan.ounn...@gmail.com> wrote: > > 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 | 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> 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 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 >> 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 >> https://moderncrypto.org/mailman/listinfo/messaging > > _______________________________________________ > Messaging mailing list > Messaging@moderncrypto.org > https://moderncrypto.org/mailman/listinfo/messaging
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ Messaging mailing list Messaging@moderncrypto.org https://moderncrypto.org/mailman/listinfo/messaging
