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 [email protected] https://moderncrypto.org/mailman/listinfo/messaging
