BadB
Professional
- Messages
- 2,557
- Reaction score
- 2,743
- Points
- 113
In the light of total surveillance, many users are looking towards solutions that allow them to hide their privacy from prying eyes. The two most popular options are Tor and I2P. Tor has repeatedly flashed on the pages of the magazine, and with its reliability, in principle, everything is clear the developers themselves write that it does not grant one hundred percent anonymity. But with I2P, we will have to figure it out on our own today is this thing really as reliable as many people think?
I2P tasks
The main tasks of I2P are as follows:
I2P and tor
The" trigger "that caused massive interest in the" invisible Internet " was the legislative restriction of access to information resources in a number of countries, as well as Snowden's revelations about spying on everyone. Of course, many people did not like this: indeed, why on earth is it unclear who will decide for an adult capable person what information he should receive and what not. As for surveillance, no one likes it at all. Realizing this, the average person rushed to look for two magic buttons "Bypass censorship" and "Hide from surveillance". And he received such "buttons" in the form of special browsers or browser plugins for the Tor network.
Technically literate people also drew attention to the I2P network as an alternative to Tor. Since you, dear reader, are technically competent people (otherwise why do you need a "Carder or Hacker"?), after reading this article, you will understand what tasks the I2P network solves and how it does it.
You should pay attention to the main difference between I2P and Tor: the main task of Tor is to hide the true IP address of the client accessing the server. By and large, servers do not care how clients connect to them rather, Togh is an extra headache for them because of bullies, in the case of I2P, on the contrary, server owners (eepsite) host them anonymously, and clients are forced to use I2P if they want to access these servers. Thus, the Tog is a network of clients, and I2P servers. Of course, there are onion sites in Tog, and output nodes in I2P, but these are rather side technologies.
Myth busters
There are several popular myths about I2P that many people believe in Online. We'll dispel them.
Myth 1: the more participants, the faster the network runs.
But in fact: each new participant must keep their database up-to-date, so the network, and especially floodfills, will simply drown in the flow of such requests. As a result, some nodes will simply become inaccessible to other nodes.
Myth 2: the larger the share of transit traffic, the higher the anonymity.
But in fact: I2P operates with separate packets, so real tunnels are not built on top of the regular Internet, as, for example, in a VPN. For each package, the appropriate delivery method is selected, regardless of whether it is your own package or a transit one. The provider sees the participant's activity as an exchange of encrypted packets with different addresses selected rather haphazardly. In this stream, in addition to tunnel messages, there are a large number of messages transmitted directly. On the other hand, a node can see some of the transit traffic if it is the end of the tunnel and not an intermediate node.in this case, the transit tunnel looks exactly like its own from the outside.
Myth 3: Togh uses multi-layer " onion "encryption, and I2P uses a more progressive" garlic "encryption, in which the message consists of several" garlic "intended for different nodes, while the node can only decrypt its" garlic", the contents of the rest are unknown to it.
In fact, it was originally planned exactly this way, but due to the need to use tunnels in pairs "outgoing-incoming", it was necessary to encrypt the entire "garlic" as a whole, and not each "garlic" separately. Indeed, the message explicitly referred to as "garlic" consists of "chesnochins", but since its structure becomes visible only after decoding, the "chesnochins" actually degenerate into fragments of tunnel messages.
What real "garlic" encryption should look like can be understood from the tunnel creation mechanism: the message consists of several records, all of them are encrypted except for one intended for this node; it re-encrypts the message with its key and sends it further. Naturally, the next node is assigned a different message record.
Thus, the declared "garlic" encryption is used only in one message, which is used relatively rarely, but in the main data stream, the usual multi-layer encryption is used: intermediate nodes encrypt the message each with their own key, and the owner decrypts it using these keys sequentially.
How do I2P participants find each other?
Let's start by looking at the mechanisms built into I2P that allow participants to find each other, and try to find potential vulnerabilities in them. Each I2P node is identified by an I2P address, which is two pairs of public and private keys generated randomly at the time of node creation, without any correlation with the IP address or location. There is no Central source of addresses. it is assumed that the probability of matching two randomly generated addresses is negligible. One key pair is used for asymmetric encryption, and the other is used for signing. The owner of a node is the one who has a file with a full set of keys with a length of 660 bytes. This file is located on the owner's computer and is not transmitted over the network. Two public keys and a 3-byte certificate (always null at the moment) form a 387-byte node identifier, by which the node is known in I2P. Since the full 387-byte identifier is quite inefficient for comparing, sorting, and transmitting data, a 32-byte SHA-256 hash from the identifier is used to designate a node. The base32 string representation of this hash is an address in .b32. i2p addresses. But what if only the hash is known, and you need to know the public keys contained in the identifier, for example, for encryption or signature verification? For this purpose, there is a network database (netDb) — not a very good name, it would be more correct to call it a network database, but this is already established terminology.
Each participant has their own database, and one of the tasks of the client program is to keep the database up-to-date. If the node with the desired hash is not found in the local database, then ask other nodes about it. if the requested node has an address in the database, it will send information about it in response, otherwise it will return a list of three other nodes where, in its opinion, the address may be. In other words, to find out information about a node, you need to know at least its hash — the ability to download a list of all currently known nodes is deliberately absent. There is also a "probing" mechanism, which sends a request for a randomly generated hash with a special flag, and then the node returns a list of three nodes present in its database, whose hashes are most "close" to the requested one, thereby allowing you to find out about new participants.
Deceiving newbies
The presence of a local database allows the participant to access the network immediately, without accessing the node directory servers, as is done in Tog'e (because of this, the Chinese government was able to disable it in 2010 by blocking access to directories). However, such decentralization has one significant drawback: in order to get information about new nodes, some nodes must already be present in the local database. This means that when you first start them, you will have to download them from somewhere. This process is called "reseding" and consists of downloading files from a small number of hard-coded sites. It is enough to block access to these sites, and new nodes will not be able to start. However, in this case, for the first launch, you can simply take the list of nodes from someone else. It is much worse if access is not blocked, but redirected to sites with a fake list of nodes this means that the new node risks being isolated from the rest of the network, and there is no easy way to recognize this situation. To the developers ' credit, they understand the scale of the problem and are working to distribute the initial list of nodes as an archive signed with their key through various channels.
Invisible Internet
The I2P network consists of two types of nodes: routers that have regular IP addresses in addition to I2P addresses and are visible on the regular Internet, and nodes that are located behind routers and do not have their own IP addresses-they form the "invisible Internet". Routers are represented in the network database by the RouterInfo structure, which, in addition to the full identifier, contains one or more external IP addresses and available protocols, as well as a list of the router's capabilities, the most important of which is floodfill. Floodfill routers serve as a kind of" Bulletin Board " where nodes publish information about themselves and where customer requests come from. To avoid forgery, data is signed with the key included in the address. Since information about the router changes quite rarely, the corresponding files are saved on disk and loaded into memory at startup. A properly functioning I2P client should have about several thousand such files.
This is what the RouterInfo file of a typical floodfill looks like
The "invisible Internet" is represented by LeaseSet data structures containing the full identifier, an additional encryption key, and a list of tunnels leading to the router with this node. Although incoming tunnels are also available for routers themselves, they never form Leasesets: routers should always be accessed by establishing direct connections with them, while tunnels are used only for receiving responses to requests. Since the lifetime of a single tunnel is ten minutes, Leasesets also exist for a short time, and therefore they are not saved on disk, but they are re-requested again when restarting. Tunnels and the encryption key from the Leaseset are the only way to access the "invisible" node, that is, knowing the address, you should first request its LeaseSet from the nearest floodfill and then send a message to one of the tunnels. To get a response, you need to create your own LeaseSet, which can be sent along with the message or published on the nearest floodfill.
The inability to determine which router a particular LeaseSet is located on is a cornerstone of the technology for ensuring anonymity in the I2P network. Accordingly, most malicious attacks are aimed at solving the opposite problem. To this end, I2P uses strong cryptography to transmit information, hiding data from particularly curious providers of different levels, and successfully applied electronic signatures make the network resistant to man-in-the-middle attacks.
Intercepting tunnels
To ensure anonymity within I2P, tunnels are used, which are chains of routers through which messages are transmitted. There are two types of tunnels: outgoing and incoming. Outgoing messages are designed to hide the sender's location, while incoming messages hide the recipient's location. Because Leasesets are a list of input nodes and IDs of incoming tunnels, information about outgoing tunnels is not published. The location of the second end of the tunnel is kept secret. To receive responses, the client sends its own LeaseSet To the server. Only the tunnel Creator knows which way the tunnel is laid and, accordingly, at which node its second end is located. All intermediate tunnel participants only know the next node to send the reencrypted message to. But this is in theory — in practice, intermediate nodes also know where the message came from, because messages between nodes are transmitted over the regular Internet and it is not difficult to find out the sender's IP address. Further, if the database size is sufficient, you can also find RouterInfo. Thus, if the intermediate node of the tunnel belongs to an attacker, then he immediately recognizes two of his neighbors, which compromises one - or two-step tunnels, since it allows you to track the entire chain. Theoretically, it is possible to increase the length of tunnels up to eight nodes, but practically every additional node dramatically slows down the speed of operation and reliability, since the presence of a node online for the entire duration of the tunnel's existence is not guaranteed. This is why i2p currently uses three-step tunnels. Thus, in order to successfully deanonymize a node, an attacker should know the route of any of the tunnels at any given time for this purpose, it is enough that two nodes of the same tunnel are accessible to the attacker. With the current network size of several thousand nodes, such a scenario is quite possible for large structures. If the previously described reeding interception does not help much in deanonymizing servers, since servers select the nodes of incoming tunnels themselves, then this method is ideal for detecting clients visiting "unreliable" resources: all nodes, including the output nodes used by the client to build its outgoing tunnels, will a priori belong to the attacker. This way, you will immediately know where the message intended for any incoming server tunnel came from.
Exception attack
For those who do not have sufficient resources to capture a large number of nodes, but have the time and patience, another method is suitable. Its goal is to sharply narrow the circle of "suspected" routers (with proper luck, even to one), on which the desired node can be located. The possibility of such an attack is due to the P2P nature of the I2P network most network routers are not online 24 hours a day, because they are located on the computers of its participants. On the other hand, i2p features are exploited:
Identify neighbors by the smell of garlic
To ensure anonymity on both sides, tunnels are used in pairs: the outgoing tunnel of the sender and the incoming tunnel of the recipient. Since tunnels are created independently of each other, the output and input routers at the junction of the tunnels see unencrypted transmitted data. Therefore, an additional layer of encryption is used on top of the tunnel one a special "garlic" message, fully encrypted and intended for end nodes in the chain. The problem is that the node's router is responsible for decrypting such messages, not the node itself. Thus, the encryption key present in the full identifier is not used. instead, the Leaseset contains a separate key intended for encryption, generated by the router on which this LeaseSet is located. However, the key must be the same for all nodes located on the router, even if each LeaseSet uses its own set of tunnels. Otherwise, it is impossible, because the "garlic" message must be decoded before it becomes clear who this or that "garlic" is intended for. As a result, the initially sound idea of "garlic" data transmission took such an ugly form when transmitted through a couple of tunnels. Thus, the encryption key published in the Leaseset is the unique identifier of the corresponding router. It is enough to compromise any of the nodes to also compromise all the others, including the client ones. To perform this attack, an attacker should launch one or more floodfills, where nodes will publish their Leasesets.
Conclusions
Summing up the above, we come to the conclusion: the anonymity of I2P in its current state is only basic, allowing you to hide only from passive observation, such as collecting marketing information. Of course, carrying out these types of attacks requires serious resources, such as high-speed servers and specialized software, but if someone really needs it, they can reveal anonymity quite quickly. An increase in the number of nodes in the network could solve this problem, but with the current network organization, this will lead to its actual collapse. At the same time, I2P is perfectly suited for building "unkillable" resources, access to which cannot be restricted in principle.
xakep.ru
I2P tasks
The main tasks of I2P are as follows:
- Hide the location of eepsites.
- Hide the location of clients connecting to eepsites, including from the sites themselves.
- Make it impossible for providers and/or backbone nodes to restrict access to sites.
I2P and tor
The" trigger "that caused massive interest in the" invisible Internet " was the legislative restriction of access to information resources in a number of countries, as well as Snowden's revelations about spying on everyone. Of course, many people did not like this: indeed, why on earth is it unclear who will decide for an adult capable person what information he should receive and what not. As for surveillance, no one likes it at all. Realizing this, the average person rushed to look for two magic buttons "Bypass censorship" and "Hide from surveillance". And he received such "buttons" in the form of special browsers or browser plugins for the Tor network.
Technically literate people also drew attention to the I2P network as an alternative to Tor. Since you, dear reader, are technically competent people (otherwise why do you need a "Carder or Hacker"?), after reading this article, you will understand what tasks the I2P network solves and how it does it.
You should pay attention to the main difference between I2P and Tor: the main task of Tor is to hide the true IP address of the client accessing the server. By and large, servers do not care how clients connect to them rather, Togh is an extra headache for them because of bullies, in the case of I2P, on the contrary, server owners (eepsite) host them anonymously, and clients are forced to use I2P if they want to access these servers. Thus, the Tog is a network of clients, and I2P servers. Of course, there are onion sites in Tog, and output nodes in I2P, but these are rather side technologies.
Myth busters
There are several popular myths about I2P that many people believe in Online. We'll dispel them.
Myth 1: the more participants, the faster the network runs.
But in fact: each new participant must keep their database up-to-date, so the network, and especially floodfills, will simply drown in the flow of such requests. As a result, some nodes will simply become inaccessible to other nodes.
Myth 2: the larger the share of transit traffic, the higher the anonymity.
But in fact: I2P operates with separate packets, so real tunnels are not built on top of the regular Internet, as, for example, in a VPN. For each package, the appropriate delivery method is selected, regardless of whether it is your own package or a transit one. The provider sees the participant's activity as an exchange of encrypted packets with different addresses selected rather haphazardly. In this stream, in addition to tunnel messages, there are a large number of messages transmitted directly. On the other hand, a node can see some of the transit traffic if it is the end of the tunnel and not an intermediate node.in this case, the transit tunnel looks exactly like its own from the outside.
Myth 3: Togh uses multi-layer " onion "encryption, and I2P uses a more progressive" garlic "encryption, in which the message consists of several" garlic "intended for different nodes, while the node can only decrypt its" garlic", the contents of the rest are unknown to it.
In fact, it was originally planned exactly this way, but due to the need to use tunnels in pairs "outgoing-incoming", it was necessary to encrypt the entire "garlic" as a whole, and not each "garlic" separately. Indeed, the message explicitly referred to as "garlic" consists of "chesnochins", but since its structure becomes visible only after decoding, the "chesnochins" actually degenerate into fragments of tunnel messages.
What real "garlic" encryption should look like can be understood from the tunnel creation mechanism: the message consists of several records, all of them are encrypted except for one intended for this node; it re-encrypts the message with its key and sends it further. Naturally, the next node is assigned a different message record.
Thus, the declared "garlic" encryption is used only in one message, which is used relatively rarely, but in the main data stream, the usual multi-layer encryption is used: intermediate nodes encrypt the message each with their own key, and the owner decrypts it using these keys sequentially.
How do I2P participants find each other?
Let's start by looking at the mechanisms built into I2P that allow participants to find each other, and try to find potential vulnerabilities in them. Each I2P node is identified by an I2P address, which is two pairs of public and private keys generated randomly at the time of node creation, without any correlation with the IP address or location. There is no Central source of addresses. it is assumed that the probability of matching two randomly generated addresses is negligible. One key pair is used for asymmetric encryption, and the other is used for signing. The owner of a node is the one who has a file with a full set of keys with a length of 660 bytes. This file is located on the owner's computer and is not transmitted over the network. Two public keys and a 3-byte certificate (always null at the moment) form a 387-byte node identifier, by which the node is known in I2P. Since the full 387-byte identifier is quite inefficient for comparing, sorting, and transmitting data, a 32-byte SHA-256 hash from the identifier is used to designate a node. The base32 string representation of this hash is an address in .b32. i2p addresses. But what if only the hash is known, and you need to know the public keys contained in the identifier, for example, for encryption or signature verification? For this purpose, there is a network database (netDb) — not a very good name, it would be more correct to call it a network database, but this is already established terminology.
Each participant has their own database, and one of the tasks of the client program is to keep the database up-to-date. If the node with the desired hash is not found in the local database, then ask other nodes about it. if the requested node has an address in the database, it will send information about it in response, otherwise it will return a list of three other nodes where, in its opinion, the address may be. In other words, to find out information about a node, you need to know at least its hash — the ability to download a list of all currently known nodes is deliberately absent. There is also a "probing" mechanism, which sends a request for a randomly generated hash with a special flag, and then the node returns a list of three nodes present in its database, whose hashes are most "close" to the requested one, thereby allowing you to find out about new participants.
Deceiving newbies
The presence of a local database allows the participant to access the network immediately, without accessing the node directory servers, as is done in Tog'e (because of this, the Chinese government was able to disable it in 2010 by blocking access to directories). However, such decentralization has one significant drawback: in order to get information about new nodes, some nodes must already be present in the local database. This means that when you first start them, you will have to download them from somewhere. This process is called "reseding" and consists of downloading files from a small number of hard-coded sites. It is enough to block access to these sites, and new nodes will not be able to start. However, in this case, for the first launch, you can simply take the list of nodes from someone else. It is much worse if access is not blocked, but redirected to sites with a fake list of nodes this means that the new node risks being isolated from the rest of the network, and there is no easy way to recognize this situation. To the developers ' credit, they understand the scale of the problem and are working to distribute the initial list of nodes as an archive signed with their key through various channels.
Invisible Internet
The I2P network consists of two types of nodes: routers that have regular IP addresses in addition to I2P addresses and are visible on the regular Internet, and nodes that are located behind routers and do not have their own IP addresses-they form the "invisible Internet". Routers are represented in the network database by the RouterInfo structure, which, in addition to the full identifier, contains one or more external IP addresses and available protocols, as well as a list of the router's capabilities, the most important of which is floodfill. Floodfill routers serve as a kind of" Bulletin Board " where nodes publish information about themselves and where customer requests come from. To avoid forgery, data is signed with the key included in the address. Since information about the router changes quite rarely, the corresponding files are saved on disk and loaded into memory at startup. A properly functioning I2P client should have about several thousand such files.
This is what the RouterInfo file of a typical floodfill looks like
The "invisible Internet" is represented by LeaseSet data structures containing the full identifier, an additional encryption key, and a list of tunnels leading to the router with this node. Although incoming tunnels are also available for routers themselves, they never form Leasesets: routers should always be accessed by establishing direct connections with them, while tunnels are used only for receiving responses to requests. Since the lifetime of a single tunnel is ten minutes, Leasesets also exist for a short time, and therefore they are not saved on disk, but they are re-requested again when restarting. Tunnels and the encryption key from the Leaseset are the only way to access the "invisible" node, that is, knowing the address, you should first request its LeaseSet from the nearest floodfill and then send a message to one of the tunnels. To get a response, you need to create your own LeaseSet, which can be sent along with the message or published on the nearest floodfill.
The inability to determine which router a particular LeaseSet is located on is a cornerstone of the technology for ensuring anonymity in the I2P network. Accordingly, most malicious attacks are aimed at solving the opposite problem. To this end, I2P uses strong cryptography to transmit information, hiding data from particularly curious providers of different levels, and successfully applied electronic signatures make the network resistant to man-in-the-middle attacks.
Intercepting tunnels
To ensure anonymity within I2P, tunnels are used, which are chains of routers through which messages are transmitted. There are two types of tunnels: outgoing and incoming. Outgoing messages are designed to hide the sender's location, while incoming messages hide the recipient's location. Because Leasesets are a list of input nodes and IDs of incoming tunnels, information about outgoing tunnels is not published. The location of the second end of the tunnel is kept secret. To receive responses, the client sends its own LeaseSet To the server. Only the tunnel Creator knows which way the tunnel is laid and, accordingly, at which node its second end is located. All intermediate tunnel participants only know the next node to send the reencrypted message to. But this is in theory — in practice, intermediate nodes also know where the message came from, because messages between nodes are transmitted over the regular Internet and it is not difficult to find out the sender's IP address. Further, if the database size is sufficient, you can also find RouterInfo. Thus, if the intermediate node of the tunnel belongs to an attacker, then he immediately recognizes two of his neighbors, which compromises one - or two-step tunnels, since it allows you to track the entire chain. Theoretically, it is possible to increase the length of tunnels up to eight nodes, but practically every additional node dramatically slows down the speed of operation and reliability, since the presence of a node online for the entire duration of the tunnel's existence is not guaranteed. This is why i2p currently uses three-step tunnels. Thus, in order to successfully deanonymize a node, an attacker should know the route of any of the tunnels at any given time for this purpose, it is enough that two nodes of the same tunnel are accessible to the attacker. With the current network size of several thousand nodes, such a scenario is quite possible for large structures. If the previously described reeding interception does not help much in deanonymizing servers, since servers select the nodes of incoming tunnels themselves, then this method is ideal for detecting clients visiting "unreliable" resources: all nodes, including the output nodes used by the client to build its outgoing tunnels, will a priori belong to the attacker. This way, you will immediately know where the message intended for any incoming server tunnel came from.
Exception attack
For those who do not have sufficient resources to capture a large number of nodes, but have the time and patience, another method is suitable. Its goal is to sharply narrow the circle of "suspected" routers (with proper luck, even to one), on which the desired node can be located. The possibility of such an attack is due to the P2P nature of the I2P network most network routers are not online 24 hours a day, because they are located on the computers of its participants. On the other hand, i2p features are exploited:
- The tunnel's lifetime is ten minutes.
- A node doesn't participate in the tunnel twice.
- To build a tunnel, a new sequence of nodes is selected each time.
Identify neighbors by the smell of garlic
To ensure anonymity on both sides, tunnels are used in pairs: the outgoing tunnel of the sender and the incoming tunnel of the recipient. Since tunnels are created independently of each other, the output and input routers at the junction of the tunnels see unencrypted transmitted data. Therefore, an additional layer of encryption is used on top of the tunnel one a special "garlic" message, fully encrypted and intended for end nodes in the chain. The problem is that the node's router is responsible for decrypting such messages, not the node itself. Thus, the encryption key present in the full identifier is not used. instead, the Leaseset contains a separate key intended for encryption, generated by the router on which this LeaseSet is located. However, the key must be the same for all nodes located on the router, even if each LeaseSet uses its own set of tunnels. Otherwise, it is impossible, because the "garlic" message must be decoded before it becomes clear who this or that "garlic" is intended for. As a result, the initially sound idea of "garlic" data transmission took such an ugly form when transmitted through a couple of tunnels. Thus, the encryption key published in the Leaseset is the unique identifier of the corresponding router. It is enough to compromise any of the nodes to also compromise all the others, including the client ones. To perform this attack, an attacker should launch one or more floodfills, where nodes will publish their Leasesets.
Conclusions
Summing up the above, we come to the conclusion: the anonymity of I2P in its current state is only basic, allowing you to hide only from passive observation, such as collecting marketing information. Of course, carrying out these types of attacks requires serious resources, such as high-speed servers and specialized software, but if someone really needs it, they can reveal anonymity quite quickly. An increase in the number of nodes in the network could solve this problem, but with the current network organization, this will lead to its actual collapse. At the same time, I2P is perfectly suited for building "unkillable" resources, access to which cannot be restricted in principle.
xakep.ru
