I2P_Developers/i2p.www
3
0
Fork 5
Code Issues 27 Pull Requests Actions 1 Packages Projects Releases Wiki Activity

it's->its

Browse Source
This commit is contained in:
eyedeekay
2024-03-30 07:59:02 -04:00
parent 12a875f1df
commit 212934361c
1 changed files with 5 additions and 5 deletions
Download Patch File Download Diff File Expand all files Collapse all files

10
i2p2www/blog/2024/03/29/many-masks-one-mind.draft.rst
View File

@ -19,21 +19,21 @@ I2P routers achieve this information sharing using the NetDB, a DHT based on Kad
The NetDB needs to share two main kinds of entries, "RouterInfos" which peers will use to communicate with other routers directly, and "LeaseSets" which other peers will use to communicate with I2P clients through anonymous tunnels.
Routers are frequently commmunicating NetDB entries with eachother, either by sending the information to a router or client, or requesting information from a router or client.
This means that the entries can arrive directly or indirectly, anonymously or non-anonymously, depending on the needs of the network and the capabilities of the client.
However, as an anonymizing network, it's also important that it remain impossible for information sent anonymously to be requested back non-anonymously.
However, as an anonymizing network, it is also important that it remain impossible for information sent anonymously to be requested back non-anonymously.
It is also important and for information sent non-anonymously to be impossible to request back anonymously.
If it becomes possible for either of those situations to occur, then a linking attack may be carried out which allows an attacker to determine if a clients and routers are sharing a common view of the NetDB.
If it can be reliably determined that the 2 targets share a common view of the NetDB, then there's a very good chance they are on the same router, weakening the target's anonymity drastically.
Because there are so few anonymizing networks, and I2P is the only one where the routing table is shared via the operation of a DHT, this class of attack is all but unique to I2P and it's resolution is important to I2P's success.
Because there are so few anonymizing networks, and I2P is the only one where the routing table is shared via the operation of a DHT, this class of attack is all but unique to I2P and its resolution is important to I2P's success.
{%- endtrans %}
{% trans -%}
Consider the following scenario: There is an I2P router hosting an I2P client.
The router publishes a RouterInfo, and the I2P client publishes it's LeaseSet.
The router publishes a RouterInfo, and the I2P client publishes its LeaseSet.
Because they are both published in the NetDB, other I2P routers can query the NetDB to discover how to communicate with them.
This is normal and essential to the operation of an overlay network of the type implemented by I2P.
An attacker runs an I2P router and queries the NetDB for the target RouterInfo and the target LeaseSet.
It then crafts a new LeaseSet which is unique and and potentially even fake, and sends it down a tunnel to the LeaseSet for the client it is targeting for attack.
The client processes the crafted LeaseSet and adds it to it's own NetDB.
The client processes the crafted LeaseSet and adds it to its own NetDB.
The attacker then requests the crafted LeaseSet back directly, from the router, using the RouterInfo it got from the NetDB.
If the crafted LeaseSet is recieved back as a reply, then the attacker can conclude that the target client and the target router share a common view of the NetDB.
{%- endtrans %}
@ -77,7 +77,7 @@ It must be able to recall:
{% trans -%}
Structurally, the most understandable and reliable way to handle this pattern is to use "Sub-DBs."
Sub-DB's are miniature NetDB's which serve to help the NetDB organize entries without losing track.
Every client gets a Sub-DB for it's own use, and the router itself gets a fully-fledged NetDB.
Every client gets a Sub-DB for its own use, and the router itself gets a fully-fledged NetDB.
Using Sub-DB's, we give our master of disguise a rolodex of secrets organized by who shared those secrets with him.
When a request is sent to a client, it only looks for entries which have been communicated to the client, and when a request is sent to a router, only the router-wide NetDB is used.
By doing things this way, we resolve not only the simplest form of the attack, but also undermine the potency of the entire attack class.