A general introduction to I2P

By casbt1osint.blogspot.com 28 min

View Original

An aggressive market is ready to make money on everything that can be sold, but popular offers in the field of private communication are fiction and lies. This happens for simple reasons: firstly, the business was invented not by patrons, but by selfish people; secondly, any entrepreneur, even with the best intentions, is accountable to third parties and in disputable situations always puts his interests above the interests of the client.

Now we will talk about I2P - a non-commercial singularity of network privacy and anonymity, where no one except you knows where and who transfers your information. The I2P Network (stands for Invisible Internet Project) is an overlay decentralized peer-to-peer network. Overlay means it works on top of other networks, for example, the regular Internet; decentralized - distributed, without a single point of failure: one node falls, half a network, or 3 users remain in the entire network - I2P will still function. I2P is a peer-to-peer network, since all participants have equal rights and opportunities: each user of the hidden network builds his tunnels through other participants and is himself a potential link in the chain of another user.

If you have never encountered I2P, this article is the start of your journey to truly private and anonymous communication; if you're a seasoned hidden network enthusiast, this overview will surely fill in the gaps and help streamline the knowledge you already have.

The difference between a traditional network and a hidden one

The traditional Internet is nothing more than an extensive network of computers. It is designed in such a way that tracking user actions is not difficult: the ISP has access to the history of your web surfing, whether you like it or not. This may be a VPN provider, in any case, some third parties know about your interests. Thanks to this, the global network turns into a tool of manipulation and one-sided propaganda.

Hidden networks, the so-called "darknet", are aimed at the opposite - the complete anonymity of users.

On the example of a sketchy town, we will depict the differences between the ordinary Internet and a primitive hidden network. The example is greatly simplified to form a general understanding.

Residents communicate through windows - this is the exchange of information through open channels. Pay attention to the presence of an "authorized" neighbor (house number 2), who hears everything, and, as we know, writes down. Let's draw an analogy of information encryption with a secret language: even if the neighbors speak a language unfamiliar to the spy, at least he knows that certain houses maintain contact. In the case of the regular Internet, the ISP stores information about the sites you visit. He does not need to know what exactly you wrote on the opposition forum. One fact of visiting such a resource says a lot. Two houses (#4 and #5) have connected underground tunnels - they exchange messages without shouting to the street. The spy does not see that these people are communicating.

An important term that will be needed in the future is DPI (deep packet inspection). In our illustration, this concept can be used to characterize the spy's ability to understand the secret meaning of the words he hears. For example, people will yell the word "trumpet" out the window before communicating through hidden tunnels. The spy will quickly understand this and begin to scour the houses where the code word came from. This will be referred to as DPI detection.

To represent a hidden peer-to-peer network, where all nodes have equal rights and opportunities, we will make an important remark: each house can only send a message to its nearest neighbor, asking to send a message further. This is an illustration of a peer-to-peer network in which each node simultaneously acts as a recipient, sender and transit node. Several problems are obvious: the anonymity of the sender, the safety and secrecy of data at transit nodes, and the presence of malicious network participants who may try to analyze messages passing through them to determine the identity of anonymous subscribers. The I2P network was originally designed with the assumption that all intermediate nodes are compromised or malicious. I2P tunnels are unidirectional, i.e. incoming traffic goes through one chain of nodes, and outgoing - on the other. In addition, all transmitted encrypted network messages tend to overlap each other, merging into information noise, which makes it pointless to try to listen and analyze the passing data stream.

Basic understanding of cryptography

There are two main types of encryption algorithms: symmetric and asymmetric. This knowledge will be needed to understand the further story.

Symmetric algorithms are simpler and therefore work many times faster: they use one key to encrypt and decrypt information. The weak point of this approach is the transfer of a key from one user to another. If an attacker can intercept the key, he will gain access to secret information. The security factor in symmetric encryption (in particular AES, a common algorithm) is the initialization vector (IV). The initialization vector is a critical component that mimics the first block of information. Since with AES encryption, each block of 16 bytes affects the next block, the integrity of the information is critical.

Asymmetric encryption is immune to this threat because Each user has two keys: public and private. The public key is transmitted openly and is used to encrypt information that can later be decrypted only with the private key from the corresponding bundle. Asymmetric encryption is used everywhere, but it loses a lot to symmetric algorithms in terms of speed. In the case when there is a lot of encryption, as in I2P, and maximum performance is needed, asymmetric key agreement algorithms are used. In simple terms: users exchange public keys, the interception of which does not threaten anything, and on their basis mathematically derive a common symmetric key. This is called concordance. Once agreed, users have a fast cryptographic operation speed, as

Important cryptographic operations include hash functions. Unlike encryption, they do not change the original information, and do not have keys as such.

Passing information through a hash function, we get a unique string. The resulting string is called a hash sum and allows you to check the integrity of the information, because. even the smallest change in information will produce a completely new hash sum.

The digital signature is a derivative of the joint use of asymmetric encryption algorithms and a hash function: first, the hash sum is displayed, and then the secret key contains the key identifier of the signing user. Having the public key of the signer, we independently check the hash sum of the information and compare it with the one that the sender originally pledged. This checks the accuracy of the information received.

General principles of I2P operation

In the I2P network, all packets are encrypted on the sender's side and decrypted only on the recipient's side, while none of the intermediate participants in the exchange is able to intercept the original data. For this reason, there is no need to worry about application programs encrypting their traffic. For example, a site in I2P does not need to use TLS encryption so that user input is not intercepted, as is done on the regular Internet, i.e. there is no need to use the HTTPS protocol.

Also, none of the network participants knows who the sender is and who the recipient is, since the status of the node from which the packet came is unknown, it can be the sender or intermediate, and the next one to which this packet needs to be sent can be the recipient or such or an intermediate node. The intermediate node cannot find out the endpoints of the sender and recipient in any way, just as it cannot find out what happened to the packet just transmitted to the next node: whether it processed it or passed it somewhere further.

I2P uses the concept of routers and endpoints: A router is an impersonal member of the network: neither a client nor a server is just a transit node that is no different from others. By establishing a direct connection between themselves, the routers see each other's real IP addresses, but this information does not say anything other than the likely use of the I2P network by the subscriber on the other end. If an attacker decides to identify all network participants, he will stumble upon various errors such as proxy servers, and in any case will not have actual data on any intranet activity of identified users. By installing an I2P network client on your device, you are actually installing an I2P router - an impersonal network link.

The endpoint, on the contrary, is a meaningful entity - either a server or a client, but its real location is unknown. I2P network endpoint addresses use identifiers derived from the public key of the signature: the hash sum gives a unique fixed-length string, at the end of which, for readability, the “.b32.i2p” pseudo-domain zone is substituted - this is how the usual intranet address is obtained. To use human-readable domains in the ".i2p" zone, such as acetone.i2p, there are free registrars that are fairly straightforward to use. The domain is bound to the full address.

The endpoint is created by the router administrator, while the router continues its "gray" work, not informing anyone about the addresses located on it. The router, receiving information that is intended for a local resource, does not pass it on, but none of the network participants can find out: the receiving router behaves the same way as a regular transit node.

Transit nodes are part of a chain of servers that form a tunnel. The tunnel can be thought of as a pipe passing through several rooms: water enters from one end and exits from the other, while observers in the intermediate rooms see the pipe, can hear the noise of the flow inside, but do not know what exactly flows through it. In I2P, all routers by default can take part in building other people's tunnels, but no one knows what, where and to whom it is transmitted through these tunnels. When creating a destination, the user himself determines the length of incoming and outgoing tunnels, as well as their number. This information remains known only to the creator of the tunnel: the intermediate links know nothing about the other transit nodes and their total number.

In the illustration, empty circles are routers. Only on our diagram, these circles are nearby, in fact, these are computers around the globe. Outgoing user tunnels are shown in brown and incoming tunnels in blue. The owner of the egress tunnel knows nothing about the incoming destination tunnel, except for its end, through which it sends information to the requested resource.

By default, the length of the tunnels is 3 nodes, but depending on the needs of the user, it can be 1 transit node or as many as 8, and even 0, then there will be a direct connection to the tunnel of the second party. As you can see, the target resource administrator has a 4-node input tunnel. Having received a request, the web resource sends a response to the user's input tunnel through its output tunnel, i.e. in a completely different way. Looking at the diagram, you can imagine how difficult it is for the user to determine the real location of the interlocutor. Considering that every 10 minutes an existing tunnel is replaced by a new one with new digital signatures and encryption keys, deanonymizing someone seems like fantasy.

An important essence of the I2P network is floodfills: special routers that collect information about the network and exchange it with each other. Anyone can be a floodfil by setting the appropriate parameter in the router's configuration file. All server endpoints of the network (i.e., the points to which a connection is expected) automatically publish information about themselves to floodfiles, which is collectively called a lisset.

Lizset will include the full endpoint address, encryption keys, and a list of incoming tunnels. Referring to any address in I2P, you automatically request a lisset of this address from a random floodfil. If the floodfil does not know the requested address, it reports the addresses of other floodfils and the search continues. The floodfil is a router (not an endpoint) and accepts connections directly, i.e. does not have its own entrance tunnels. However, endpoints access it exclusively through anonymous chains, thereby hiding the location of the published resources and those who want to access them.

Since each endpoint has an average of three input tunnels that change every 10 minutes, the access to floodfiles is like an avalanche, albeit with a small data flow. Due to this, a chaotic movement of service information always occurs in the network, forming "white noise".

In addition to searching for lissets, white noise is generated by network probing: each router polls a random flood file with a small frequency, receiving three new routers in response (thus increasing its own network pattern and finding new flood files). The main source of network noise on the router is transit traffic: it creates a lot of network activity regardless of the endpoints located on the router. Also, being a transit link, the router mixes a payload with the traffic of other people's tunnels - the traffic of its hidden services. The more transit traffic on the router, the more absolute the secrecy of its endpoints: any actions on a hidden resource, even a DDoS attack, cannot be compared with the network activity of a particular server. An active network node has an average of 5000 active routers in its database and receives hundreds, and even thousands of absolutely random transit connections. As they say: try to analyze.

Separately, we note the mechanism for selecting a flood file by the user. This is an important issue that has been given due attention during development. Since any of the floodfiles can contain a malicious user, the task was to make his attempts at analysis and other dishonest actions not applicable to a specific person. The floodfil for the request is selected as follows: the target address and today's date are taken. From this information, a SHA256 hash is derived - data of the same length as a regular address is obtained. Then the floodfile is searched in the local database of the router: the one that will give the smallest number during the “EXCLUSIVE OR” operation with the “target address + date” block is used. This approach makes host selection for service requests unpredictable and changing daily for each address. Within the framework of this material, the “accidental floodfil” is mentioned,

We recently mentioned DPI - the study of network packets in order to determine the type of information transmitted. Mentioned for good reason, because you should be aware of this technology, as well as the fact that all I2P traffic is resistant before analysis. Network traffic is encrypted from the very bottom, starting with the transport protocols. I2P uses: NTCP2 , as a crypto analogue of TCP, and SSU, as a crypto analogue of UDP. An I2P router receives network traffic from applications accessing the hidden network and wraps familiar protocols into their encrypted counterparts. After processing in network packets, it is impossible to reveal anything intelligible, because everything is encrypted, including headers and size. The size of the packets is hidden by padding, i.e. filling packets with random data up to a certain size. Information about the real size of the network packet is transmitted in it in encrypted form. When decrypted on the end device, the mixed "garbage" is simply discarded. Thus, the "white noise" of the network, i.e. information that is practically meaningless for a person is mixed with user information and from the outside is absolutely indistinguishable from it.

The described network organization eliminates the need to use IP addresses in intranet routing and allows all resources to remain anonymous, since no one knows what is located on a particular router: is it just an output proxy of an ordinary user or a world-class web resource.

Supplementing and consolidating everything that has been said, we will describe in detail the process from the first launch of the router to the opening of a web page. At the first start, the router does not have any data about the network, so a random read-server is accessed, which gives the user its database of known routers. Resids are kept by enthusiasts, their list is freely available. In fact, the information from the resid is a zip archive of the netDb folder, in which each router stores information about the network. Since the data is transmitted via the regular Internet, in order to avoid substitution along the way, the archives are signed with a digital key. The public keys of all current resources are contained in the I2P router itself. If for some reason we do not want to access public research servers, we can use existing network databases, for example, from our other routers. Reseed is not accessed if there are at least 25 routers in the netDb folder. After connecting to several actual participants, automatic continuous expansion of the network pattern begins.

Building tunnels

To create tunnels that provide an exhaustive level of privacy, I2P uses the so-called "garlic encryption". "Garlic" I2P is a block of information, including several "garlic" of 528 bytes. "Chesnochins" are laid in a random order, so their sequence does not carry any information. Each recipient of the "garlic" identifies his "clove" by the first 16 bytes that are part of the hash of his address. After the desired "clove of garlic" is found, the instructions contained in it are decrypted by the router's key.

According to the instructions, all the garlic can be transferred to the next node, where the procedure will be repeated. When building an outgoing tunnel, the last receiver instruction tells the tunnel creator that the chain is complete. Since all tunnels are unidirectional, it is told the entrance tunnel. The first outgoing tunnels are created with the response returned to a tunnel of zero length, i.e. directly to the creator, however, this is a rare occurrence and the fact that the tunnel length is zero is known only to its creator, so the user is not compromised.

When creating an incoming tunnel, the picture is even more elegant: through the outgoing tunnel, garlic is transmitted to a random router, the last recipient of which is the creator himself. From the perspective of the last hop, handing over the garlic to the tunnel creator is perceived as handing over to the next hop. That is why transit nodes cannot know the length of the tunnels and their owners.

When building a tunnel with a length of no more than 4 participants, i2pd forms a "garlic" of 4 cloves, in other cases, a "garlic" of 8 parts is formed. Empty garlic cloves are filled with random information and are indistinguishable from real ones.

The I2P protocol does not provide for tunnels longer than 8 participants, however, in practice, 4 hops are considered to be a complete solution.

The "garlic" contains information for each participant:

1. Tunnel number on his router (random 4 bytes).

2. The address of the next router and the tunnel number on it (almost like the IP address and port number in a regular network).

3. Symmetric encryption key and initialization vector (IV) encryption key. The initialization vector itself is contained at the beginning of the message.

4. The role of the node in the chain: final or intermediate.

5. The symmetric encryption key and initialization vector for the response. They encrypt the status of the transit router: is it ready to accept a new tunnel. If at the end it turns out that at least one router disagreed, the tunnel will not be created and the entire creation process will start from scratch.

Depending on the type of tunnel (inbound or outbound), the last link assumes the role of either "Endpoint" or "Gateway". Between participants in the same tunnel, encrypted information is transmitted in blocks of 1 kilobyte - this is the current protocol standard. The task of the last outgoing node is to collect information into a more powerful packet and send it to the right user on his incoming tunnel. The work of the incoming tunnel router is the opposite: it divides the received information into blocks and sends it to the other end of the tunnel. Each tunnel exists for 10 minutes. In order to avoid disconnection, the parties create new tunnels in advance and exchange their lissets. Read more about the tunnel in a separate article .

Interaction model

By default, i2pd provides SOCKS and HTTP proxies for applications. A proxy is an intermediary. In our case, it is an intermediary for accessing a hidden network. By default, SOCKS5 is available at 127.0.0.1:4447, HTTP proxy on port 4444. To open a web page hosted on the I2P network, you need to set the appropriate settings in the browser. In Firefox, the proxy is conveniently configured through the network configuration, or through the FoxyProxy plugin. When we entered the site address in the configured browser, the I2P router received our request and started working.

First, a random floodfile is called with a request for a lisset of the desired destination. The user exit proxy is the endpoint, i.e. hidden entity. In order not to disclose its location, the floodfil is accessed through a chain of transit nodes. We also give it our input tunnel data for the response. Let's say that the floodfill doesn't know the required address, so instead of a lisset it returns three random floodfills from its database. From the received new floodfiles, one is randomly selected, to which the router repeats the previous request. In our example, the second floodfill gives the desired lisset: all the necessary information to communicate with the endpoint, which includes information about the entrance tunnels and keys. There are usually at least three entrance tunnels. By selecting a random destination input tunnel, the router sends a request through it to the server. If everything went well and the request arrived, the server sends us a web page. In a normal network, this happens along the same path from where the request came from, but in I2P things are completely different. The local proxy endpoint sends its response lisset along with our request. Having reached the server, we told him the address for the answer: in order for the web page to open in the browser, the server needs to use itsoutgoing tunnel send a response to our incoming . Having accepted the answer through the incoming tunnel, our router processes the information and the treasured page opens in our browser!

User information, passing through the tunnels, is subjected to "onion", i.e. multilayer encryption. Before sending a message to the outgoing tunnel, the router sequentially wraps it in several layers of encryption using the keys that were issued to the transit nodes of the tunnel. Each node of the outgoing tunnel, receiving information with the originally issued key, removes one layer of encryption and passes the information further. The last node of the outgoing chain, Endpoint, removes the last layer of onion encryption, forwards information to the incoming tunnel. In the incoming tunnel, onion encryption is mirrored: the Gateway encrypts the information with its own key, which was given to it by the tunnel creator, and passes it on. Each subsequent input tunnel node adds its own layer of encryption. The creator of the incoming tunnel, upon receiving information, removes all layers of onion encryption with keys that were issued to transit nodes. User information is end-to-end encrypted using the destination's public key, so no transit node has any sensitive information, and the final recipient, having removed all onion encryption, decrypts the information with its asymmetric key and performs signature verification.

If someone tries to break into the tunnel and slip their information, impersonating the real sender, the signature will be incorrect and the information will be rejected. After the session is established, to optimize performance, the endpoints use a set of one-time symmetric keys and tags to them, applying the corresponding keys and exchanging only tags among themselves.

Read more about tunnels in a separate article .

Practical use

The scope of I2P is vast and not limited to just websites. You can host any web resources in I2P: forums, bulletin boards, git repositories, blogs and personal one-pagers. It is quite possible to organize even network turn-based games that do not require low latency when transmitting packets, such as chess or cards. You can also find the use of I2P in building exit tunnels from an indefinite place to the global network, for completeness, placing exit proxies on anonymously paid servers. By organizing ssh access to a rented machine via I2P, you only need to go to the server through other networks once to install i2pd and configure the tunnel that will accept connections. The only limitation of fantasy is the speed of data transfer within the network. It should be noted

Development of the protocol

All this is interesting, but a natural question arises: who is behind this? Judging by the complexity of the protocol, you might think that this, like in the case of the Tor network, is something related to intelligence agencies and government funding, but no. I2P is a completely free project, born and maintained by enthusiasts to this day. The development of I2P in the Java programming language was started by a certain JRANDOM. The first release took place in 2003. A few years later, JRANDOM stepped away from development without leaving any news about itself, and its place was taken by a user with the nickname zzz - an American, presumably from the New York area, who at the time of the publication of the article is still in charge of development. So 10 years passed: the community grew, the I2P router was written as best they could, and official documentation was also written at that time. When searching for "I2P", the first link is usuallygeti2p.net - the official page of the same I2P router in Java. But the story doesn't end there.

In 2013, a Russian-speaking user orignal with a French nickname, apparently a big fan of pirate literature, found a message in the Flibusta online library about the inaccessibility of downloading books via the clearnet, i.e. normal internet. Instead, users were encouraged to use I2P. However, Orignal, as he says, did not find an existing normal implementation of the protocol, but only a kind of division in Java. Despite the fact that the development of “this product” has already been underway for ten years, orignal, as a sophisticated programmer, did not appreciate it. At that time, there were a dozen more attempts on the net to write an i2p router in C and C ++, in which absolutely nothing had been done. There was something in the product called "i2pcpp", but it was also far from something suitable. And what does orignal do: in three months he wrote a working program in C ++, suitable for downloading books from Flibusta, and I already wanted to stop there. It was July 2013 outside. However, a certain person persuaded him to present his experience inarticle on Habré. The fact is that orignal had to delve into the wilds of the Java code, because. official documentation was not complete and had a fragmented structure. After the publication of the first article, something happened: probably, noticing the interest of the public, and feeling some excitement inherent in all programmers, writers and composers, orignal took up writing a full-fledged network client. The debut release of 0.1.0 took place on October 17, 2014. To implement it, orignal had to implement several cryptographic functions in C ++ (which, with the extension of the OpenSSL library, were later replaced by library ones). The new client was called i2pd - Invisible Internet Protocol Daemon. After the first release, orignal was joined by enthusiasts who also started working on improving the new I2P router.

In the early years, a lot of skepticism was shown to the i2pd initiative by outside observers: PurpleI2P was looking for the hand of the Kremlin, bookmarks from the FSB, traces of Freemasons and reptilians. The very name Purple at the apogee of the drug addiction was reduced by some individuals to the flag of the Russian Federation: a mixture of red, blue and white colors gives the same purple. However, orignal, the lead developer of i2pd, explained that the name PurpleI2P does not contain a great secret: the name was coined after a mug of English ale with an eye to the royal crown of the British Empire. Perhaps this can be considered a reference to i2pd's leadership over the original client in Java.

Orignal to this day continues to publish Russian-language articles about I2P, telling the general public about the development of the protocol. New nicknames appear in the team of enthusiastic programmers, while others, on the contrary, go permanently offline. Most development planning happens on IRC, on the ILITA network. The Russian-speaking community is quite active and everything is actually discussed on IRC: from new features in I2Pd to the climate in Africa and new memes.

Each version of the router is replaced by the next, the community lives, the developers are constantly coding something. So that there are no questions about what is changing, if everything is working well anyway, let's briefly talk about the development of the protocol: how many paranoids decide that the protocol does not change, but only the backdoor from law enforcement agencies is honed. At the beginning of the journey, the branches of the java router and the C ++ router did not develop synchronously, the coordination of nuances with the neighboring camp occurred with some delay. Now the developers, despite the differences in views, together implement significant solutions. The most notable change in recent years is the transition from the NTCP transport protocol to NTCP2. This protocol is an adapted crypto-analogue of the familiar TCP and is used everywhere: from opening a web page to downloading a torrent. The main difference between the two protocols is the use of an encryption algorithm: the old NTCP uses Diffie-Hellman, which is very slow and greedy for system resources, while NTCP2 uses an elliptic curve algorithm, a trend in the field of high-speed cryptosystems that surpasses its predecessor in cryptographic strength and performance. This change made I2P routers more lightweight and fully usable on small devices like single board computers and smartphones (at least i2pd for sure). The replacement of the Diffie-Hellman key agreement algorithm with new solutions occurs in other parts of the protocol. For viewers who understand cryptography, we especially note that the I2P network is gradually moving to cryptographic protocols of the Noise family, which is also a good solution for performance, anonymity and reliability. I2P routers, like all programs in the world, are prone to shortcomings like bugs and incomplete implementation of some functions, which leads to further development, correction, and new releases. If you are interested in the details, more information can be found through the search engine and in the community chats.

Why use i2pd in C++ instead of router in Java? The answer is simple: because i2pd is architecturally superior to the Java one. I2P is a storehouse of various cryptography, the implementation of which in Java would be terribly slow. Therefore, the Java router uses libraries written in the C language. And everything would be fine, but each call to these libraries is a big overhead. And no matter how hard the developers try, there are brakes. Not as big as they could be, but they are very far from the speed of native (i.e. embedded) cryptography from i2pd. Also, all java router traffic locally passes through the actually superfluous I2CP protocol, which, without going into details, greatly spoils the quality of work, while in i2pd this protocol exists solely for compatibility with applications on java routers. For inquisitive minds, we can say in more detail: The main problem with I2CP is that through it, TCP sessions (which are called streams) cannot control access to tunnels and lissets. I2CP also deprives users of the Java router of normal support for UDP tunnels: their support is provided by a separate streamr application. As an experienced viewer already knows, the UDP protocol is used for fast data streaming, for example, the voice of the interlocutor during an online call. It is difficult to overestimate the quality support of this protocol. In I2Pd, UDP tunnels are supported without any problems and additional software layers. As an experienced viewer already knows, the UDP protocol is used for fast data streaming, for example, the voice of the interlocutor during an online call. It is difficult to overestimate the quality support of this protocol. In I2Pd, UDP tunnels are supported without any problems and additional software layers. As an experienced viewer already knows, the UDP protocol is used for fast data streaming, for example, the voice of the interlocutor during an online call. It is difficult to overestimate the quality support of this protocol. In I2Pd, UDP tunnels are supported without any problems and additional software layers.

In addition to faster i2pd performance, this router also consumes less system resources compared to the java version. a C++ program directly interacts with the system, unlike Java, where everything revolves inside a virtual machine - an additional layer between the operating system and software. Further, only more: exploring the expanses of intranet sites, you will more than once stumble upon a description of various problems with the performance of the I2P network, where the source of the problems will not be the protocol, but its crooked implementation in a popular client. As part of tests with high-speed servers and a network that completely excludes the presence of Java routers, we managed to achieve a speed of slightly less than a megabit per second. Today, such an indicator against the background of an average of several tens of kilobits seems incredible! In video, the text of which this article was compiled, is a screenshot of a recent correspondence between two leading developers: orignal and zzz. While video streams are being streamed through i2pd in test mode, the Java router does not even allow you to listen to online radio. To increase the average speed of the I2P network, you need: firstly, everyone should keep their node turned on for the maximum available time, and secondly, it must be a network node running on i2pd.

Comparison with other networks

If you're familiar with the Tor network and mesh networks like the Yggdrasil Network , after all that's been said about I2P, it doesn't make much sense to say how they differ. These are completely different concepts. However, for novice readers, I will give a few basic points.

Let's start with Tor: Firstly, it is strongly tied to the root servers of the office, to which the initial call is made to build a network pattern. In I2P, these are the reciprocals explicitly indicated in the code, which can be changed to your own, or simply use ready-made address books, based on which the router will continue to work, completely bypassing the start nodes. Secondly, according to competent users, Tor originally and still belongs to the NSA, so you should not build illusions about it. Third, Tor has a simpler tunnel architecture and fewer tunnel configuration options. Fourthly, Tor initially assumes proxying to the regular Internet, and in I2P this is possible only with the additional configuration of the corresponding nodes and tunnels to them. This point, according to the mood, can be attributed to the cons of I2P, but we will not agree.

About Yggdrasil and similar mesh networks: such developments focus on ease of deployment, data transfer speed and self-organization. Traffic inside Yggdrasil is not artificially confused, the network has a simple and intuitive pattern. Users have strong bi-directional encrypted tunnels, and the shorter the better. As you can see, I2P has very little in common with Thor, and even less with common mesh networks. Unless I2P can work freely through Yggdrasil (support in i2pd since version 2.36.0). Through Thor, too, by the way. On this, perhaps, everything.

Afterword

One last thing on I2P and hidden networks in general: is it ethical? The established public opinion is such that any attempts to anonymize are regarded as criminal intent. For example, on hidden networks, people can post things that would be blocked on a censored network. This, of course, infuriates the censors. Let's not keep silent about the crime that can find a haven in I2P, all this is obvious. But what do the developers of I2P, who may also have families, children and a craving for justice, think about this, and how do most crypto-anarchists think? In short: a kitchen knife can cut bread, or it can cause harm, but because of the possible abuse, kitchen knives are not prohibited. It’s the same here: you can’t fight privacy technologies under the pretext of fighting crime, since the most common crime today is a violation of civil rights and freedoms:

If you have been fascinated by “netstalking”, i.e. a romantic study of the contents of hidden networks, we encourage you to go further - to study the mechanics of these networks and contribute to their development. The "darknet" (or "deepweb") is not, at its core, something exotic; it is a modern set of necessary tools for the free dissemination of information and personal communication of people without artificial barriers.

Просмотры: