str4d str4d@i2pmail.org writes:
[ text/plain ] On 27/04/16 22:31, grarpamp wrote:
On 4/25/16, Tim Wilson-Brown - teor teor2345@gmail.com wrote:
On 22 Apr 2016, at 17:03, grarpamp grarpamp@gmail.com wrote:
FYI: The onioncat folks are interested in collaborating with tor folks regarding prop224.
https://gitweb.torproject.org/torspec.git/tree/proposals/224-rend-spec-ng.tx...
I'm interested in what kind of collaboration onioncat would like to do on prop224, next-generation hidden services. It would be great to work this out in the next few weeks, as we're coding parts of the proposal right now.
Yep :) And I know Bernhard was hoping to get in touch with Roger on this before long.
Basically, prop224 HS being wider than 80 bits will break onioncat's current HS onion <---> IPv6 addressing mechanism.
They're looking at various backward compatibility options, as well as possibly making side use of the HSDir DHT, or even integrating more directly with the tor client.
Just FYI, I recently migrated all of I2P's spec proposals to the website, and came across a seven-year-old proposal that Bernhard wrote about improving I2P support in GarliCat:
https://geti2p.net/spec/proposals/105-garlicat-name-translation
I don't know how well it has aged, but given that Tor is now facing the same issues that I2P has, perhaps it can be of some use if resurrected from the dead :)
Hello,
disclaimer: I've never used onioncat and I'm not even sure what are the use cases for it. I just read the docs on its webpage in an attempt to understand the system and maybe contribute to this thread. I probably don't understand the system sufficiently yet.
Starting with a question wrt the "Scalable Solution" for I2P, I did not exactly understand how the DNS approach would work for garlicat. Would GC do the DNS request? Or the application? And to which DNS server? Some GC-specific DNS server? The solution seems plausible, but it requires the extra DNS protocol round trip.
BTW, if the application-layer protocol supports DNS, can't we just fake the DNS protocol part and resolve the DNS query inside onioncat? So, Alice is in onioncat as "aliceonioncathiddenservice.onion" and she passes her onion to Bob who wants to torrent with her through onioncat. Alice gives "aliceonioncathiddenservice.onion" to her friend Bbo, and Bob tries to connect to it through his application (e.g. a torrent client). Bob's application will probably do a DNS query for the onion address, which onioncat can intercept (?). At that point, onioncat can register the onion address as the destination, and pass back a fake IPv6 address to the torrent client. From that point and on, the torrent client will use the fake IPv6 address, and onioncat will reroute the connection through the onion circuit to "aliceonioncathiddenservice.onion".
I'm not sure if the above idea will work, but even if it does, it's worse than the current onioncat, since it requires the application-layer protocol to support DNS.