[messaging] Ronion anonymous routing protocol framework

[Ximin Luo]

Nazar Mokrynskyi:
> Hi folks,
> 
> Recently I've being exploring anonymous routing protocols (Tor, mixed networks) because I need such for one of my projects.
> 
> Each project seemed to design the whole thing from the ground up and they are protocols are quite complex as a whole.
> 
> I thought it could be a good idea to create something like Noise, but for anonymous routing.
> 
> In a nutshell Ronion aims to design a generic anonymous routing protocol framework agnostic to encryption algorithm and transport layer.
> 
> If you want to re-implement Tor with Ronion you do the following:
> * choose transport layer where messages delivery order is guaranteed (TCP)
> * choose your crypto (like Noise IK for end-to-end encryption and some stream cipher for onion-like non-authenticated layered encryption)
> * choose algorithm for nodes selection for future circuit
> * choose address format (depends on transport layer and use case, can be IP:port or public key)
> 
> And Ronion will provide a framework for circuit creation, communication between nodes, messages forwarding and data delivery.
> 

This sounds pretty cool. I agree that too many projects try to do "too much" and things should be split up a bit.

> Ronion is relatively simple, provides only very basic primitives and greatly limits its responsibilities to facilitate diversity of higher-level protocols on top of it.
> 
> Besides proposed specification repository contains an implementation in JavaScript (LiveScript) and tests against that implementation to ensure it can work at all.
> JavaScript language was selected for initial implementation because I'll need to run everything within browser for my project.
> 
> If you're building something that might use this spec as the low-level framework, I'd be interested to discuss how to make this spec suitable for you.
> 
> Also I'd like to request some feedback from those who have a bit of spare time to make sure I didn't mess up something badly and there are no obvious flaws.
> 
> Ronion specification: https://github.com/nazar-pc/ronion/blob/master/spec.md
> 

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

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

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