[messaging] Ronion anonymous routing protocol framework

Nadim Kobeissi nadim at nadim.computer
Tue Oct 10 12:19:43 PDT 2017

+1 for OCaml, although its ecosystem is way undermaintained.

Sent from my computer

> On 10 Oct 2017, at 9:18 PM, Erwan Ounn <erwan.ounn.84 at 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 <nazar at 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 at moderncrypto.org
>> https://moderncrypto.org/mailman/listinfo/messaging
> _______________________________________________
> Messaging mailing list
> Messaging at moderncrypto.org
> https://moderncrypto.org/mailman/listinfo/messaging

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: Message signed with OpenPGP
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20171010/cad37ff6/attachment.sig>

More information about the Messaging mailing list