On Tue, Oct 17, 2017 at 10:31:55AM +0200, Jeff Burdges wrote: > On Tue, 2017-10-17 at 06:06 +0000, James McGlasan wrote: > > - Paths are undirectional and do not rely on slow (latency) > > bidirectional-telescoping to establish connections. > > I've never read any analysis showing that unidirectional paths improve > protections, but maybe.
I mentioned this more for the point of performance, but this does reduce the timing information that bidirectional relays learn. From the paper [1]. Section 5.2. Passive De-anonymization Forward/backward flow correlation. The forward and backward headers are derived from distinct cryptographic keys and therefore cannot be linked. Only the destination is able to correlate forward and backward traffic, and could exploit this to discover the round-trip time between the source and itself, which is common to all low-latency anonymity systems. Sources willing to thwart such RTT-based attacks from malicious destinations could introduce a response delay for additional protection. > > - Relays do not maintain any per-connection or flow state. (cheaper on > > memory and file descriptors) > > Afaik HORNET does not work unless you add replay protection, making it > ultimately stateful, no? HORNET works fine without replay protection on the relays, the endpoints can still detect all replays and if this is consistent for any specific relay, then that relay may loose reputation and no one would use it. A reputation system is not covered by HORNET, but external auditing and localized heuristics will always be important for any such network. > > - Relays .. know only .. if they are encrypting (towards an endpoint) > > or decrypting (towards a rendezvous point). > > Really? Are you sure HORNET nodes know if they are encrypting or > decrypting? That sounds unlikely to me. Yes, assuming I've read the following correctly. Section 4.4.3. Processing for the backward path. Sending and processing a HORNET packet along the backward path is the same as that for the forward path, with the exception of processing involving the data payload. Because D does not possess the symmetric keys that each node on the backward path shares with S, D cannot onion-encrypt its payload. Therefore, instead of `REMOVE_LAYER`, D and the intermediate nodes use `ADD_LAYER` to process the data payload, and the source node recovers the data with `REMOVE_LAYER`. > > A PIR service may be used to bootstrap a DHT network whose nodes are > > hidden by the onion routing protocol itself. I plan to use S/Kademlia > > for my implementation, although this may be replaced with a byzantine > > fault tolerant DHT later. > > I'm not familiar enough with recent things here, but one protocol I know > of basically glues a cheap PIR inspired layer onto a Byzantine gossip > protocol : > https://gnunet.org/sites/default/files/Brahms-Comnet-Mar09.pdf > It sounds okay for informing routers about other routers, but it'll > leave clients vulnerable to epistemic attacks. > > I've never heard anyone propose hiding queries in the onion routing > protocol. It sounds like the right direction to me, but network people > tend to like their layers. I've taken a quick skim over the paper and if I understand correctly, it enables an arbitrary party to make a random selection of nodes, not allow those nodes to randomly select themselves. That may be better suitable for selecting relays, but not to populate the DHT bootstrap PIR. Instead, we allow the DHT nodes to elect themselves, to register into the PIR and audit the PIR service. Auditing the PIR will work in two ways (1) any elected nodes verify their own presence in the set by looking up their entry and (2) performing random lookups to connect to random DHT nodes, then verify that the real network is reachable through that node and we're not enclosed under an eclipse attack. Although only the elected DHT nodes may audit (1), anyone may audit (2). The DHT will store the rendezvous point of the DHT node and the path between these. This also serves the additional purpose of advertising HORNET relays which the client may use to form their anonymised connections to their bootstrap DHT nodes to then learn about more HORNET relays, some of which may have shorter lifetimes for key rotation / weak forward secrecy. > > > It needs to be a AEZ or another wide block cipher. > > > > Why aren't you authenticating? We want to reduce malleability and > > tagging attacks! Sphinx and HORNET use unauthenticated encryption for > > the payload and a MAC to authenticate the payload and header, > > We were talking about the payload because he was talking about onion > services. I avoided bringing up the Sphinx header because it'd confuse > people. Fair. > > HORNET will discard any corruptions early. > > This does not sound compatible with receiver anonymity. Sorry, I mixed details between Sphinx and HORNET. Sphinx* will discard any corrupted messages at the relay that detects the corruption. HORNET does not notice, but the endpoints do. To avoid tagging on a sphinx based mixnet, a dummy payload may be used in place of omission. Section 5.4. Payload tagging or tampering. HORNET does not use per-hop MACs on the payload of data packets for efficiency and because the destination would not be able to create such MACs for the packets it sends (since the session keys of the nodes are known only to the source). The lack of integrity protection allows an adversary to tag payloads. Admittedly, the use of tagging, especially in conjunction with replay attacks, allows the adversary to improve the effectiveness of confirmation attacks. However, end-to-end MACs protect the integrity of the data, making such attacks (at a large scale) detectable by the end hosts. James. [1]: https://arxiv.org/abs/1507.05724 _______________________________________________ Messaging mailing list Messaging@moderncrypto.org https://moderncrypto.org/mailman/listinfo/messaging