On 2016-05-26 13:37, George Kadianakis wrote:
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.
Hi!
In the following there is a fundamental explanation of OC and the problems with prop224.
OnionCat simply does 2 things:
1) It is a VPN adapter based on the Tor (or I2P) network (on its hidden services). There is no central VPN server, instead OnionCat connects peer-to-peer to the other participants. Because it is based on layer 3 (as most other VPNs) all packets (not just TCP) may be routed through it. OnionCat uses IPv6 as L3 protocol.
2) OnionCat generates an end point IP address which is based on the hidden service ID (e.g. iuddxo47v5mhoqyz.onion <-> fd87:d87e:eb43:4506:3bbb:9faf:5877:4319). This has 3 major advantages: a) every end point automatically gets a unique IP thus the user does not have to care about it and b) they are cryptographically tied together, thus one cannot simply spoof an address, c) there is almost no configuration necessary because OC can "automatically find" its way through Tor because of its ability to translate between hidden service ID and IP address.
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.
For Alice and Bob to communicate together they need to know the IPv6 address of each other (as in any other IP-based network).
What happens technically within OnionCat? 1) OnionCat receives an IPv6 packet, decodes the header and retrieves the destination IPv6. 2) OC converts the IPv6 address to an .onion-id 3) OC request a circuit from the Tor client with this destination .onion-id 4) Tor connects 5) OC forwards the IP packets through the circuit. 6) At the other end packets "drop out" of the Tor circuit into OC which in turn forwards the packets to the local kernel.
Whats the problem know with Prop224? For OC to work properly it needs to be able to convert .onion-ids to IPv6 addresses back and forth. This works well with the current 80-bit hashes but it does not work with hashes greater than 80bits.
So what's the solution? The solution is to use some kind of database to do lookups, i.e. find the proper .onion-id given a specific IPv6 address.
Actually, it doesn't matter what kind of database this is but it should obviously NOT break anonymity. Because of that Internet DNS may be problematic although it would be very easy to implement.
IMO a better place would be the HS directory :)
Bernhard