Part 1: “Everything you wanted to know and were afraid to ask about I2P”
I used I2P for quite a while and read all the articles about this network available in the Russian-language part of the Internet, but not one of them provides comprehensive knowledge about it. Considering the wishes of people in previous publications about I2P, I started translating an official source.
Due to the large amount of information, I will post the translations in parts.
If someone really cares about it, I ask under the "spoiler".
This is an *literary translation, I apologize if somewhere the meaning has been distorted.
Send corrections and corrections in lichku.
Official source: i2p2.de
Table of contents:
Part 1: “Everything you wanted to know and were afraid to ask about I2P”
Part 2: Tunnel Magic, NetDB, and Protocol Juggling
Part 3: Digital Garlic
')
I2P is a scalable, self-organizing network that distributes packets between anonymous network layers, in which any number of applications can run, while ensuring a high level of security and anonymity. Each of these applications in itself, can be anonymous, have their own capabilities to manage the network, without worrying about the proper implementation of the control work free, distributed and asynchronous routing. I2P allows them to mix their work among a large number of already existing anonymous users working on the network.
Applications can use all the features of regular Internet, while combining anonymous web surfing, web hosting, anonymous chat, file transfer, blogging and other features that will be added later.
Unlike the websites hosted on the Freenet and GNUnet distribution networks, the websites hosted on I2P are completely interactive - there are traditional web services: search engines, bulletin boards, blogs have the opportunity to comment.
With all these anonymous applications, I2P takes on the role of "Charon" (He who carried souls across the river of the dead in Greek mythology) - the applications report that they want to send some data to the address provided by the cryptographic identifier (This is the destination) and I2P makes sure that the data is delivered secretly and anonymously. I2P is able to distribute packets so that information is transmitted as anonymously and reliably through several streams over TCP. At the same time, based on the algorithm, maximum throughput and minimum delays are ensured.
Several simple SOCKS proxy servers are available to associate the existing Internet with I2P, their capabilities have been limited, since many sites usually pose a threat to anonymity and put the user at risk.
The only safe way is full processing of applications to ensure proper operation, we provide a number of API interfaces that can be used to improve interaction with the network (here apparently means working with the Internet in both directions - approx. Lane).
I2P is not a research, academic, commercial or government project. This is a joint effort of engineers to do everything necessary to ensure a sufficient level of anonymity for those who need it. Active development has been carried out since the beginning of 2003 and occupied all the time of developers, there is also a special group consisting of participants from around the world who also participated in the development. The entire I2P source code is open and freely available on the website, most of the code is in the public domain, although several cryptographic procedures are used under a BSD license.
People working on I2P do not control what people do in client applications, and there are several applications available under the GPL license (I2PTunnel, susimail, I2PSnark, I2P-Bote, I2Phex, and others.).
Financing I2P comes exclusively from donations, and is not taxed (oh how bent), since many developers themselves are anonymous.
To understand how the I2P network works, it is important to understand several key concepts:
First, I2P makes a strict separation between the software involved in the network (“router”) and anonymous ends (“targets”) associated with individual applications.
When I2P is used, it can be clearly seen, but what does it hide? It hides information about what the user is doing now (if at all), as well as the fact that the user is connected to a specific router. End users usually have multiple local addresses on the router — for example, one proxy for IRC servers, another to support a custom anonymous web server (“eepsite”), another for I2Phex, for example, the fourth for torrents, etc.
The second important aspect for understanding the work is the concept of a “tunnel”. A tunnel is a directed path through a clearly selected list of routers. Multi-level encryption is used, so each router can decrypt only one layer. The decrypted information contains the IP of the next router, along with the encrypted information that will be redirected. Each tunnel has a starting point (the first router, also known as a “gateway”) and an end point. Messages can only be sent one way. To receive the return message, one more tunnel is required.
There are two types of tunnels: outgoing tunnels send messages from the tunnel creator, while incoming tunnels send a message back to the tunnel creator. The combination of these two tunnels allows users to send each other messages. The sender ("Alice" in the image above) establishes an outgoing tunnel, while the receiver ("Bob" in the picture) creates an incoming tunnel. The gateway in the incoming tunnel can receive messages from other users and forward them to the end point (in this case, “Bob”).
The endpoint of the outgoing tunnel will have to send a message to the gateway to the incoming tunnel. To do this, the sender ("Alice") adds instructions to the encrypted message. As soon as the endpoint of the outgoing tunnel decrypts the message, it will receive instructions to forward the message to the correct incoming gateway (“Bob” gateway).
The third important point to understand is the NetDB network database. Several algorithms designed to exchange network metadata. There are two types of metadata: “routerInfo” and “leaseSets”:
routerInfo provides data about routers needed for the exchange of private router data (their public keys, addresses, etc.), while the leaseSet gives routers the information necessary to connect specific points.
LeaseSet contains the “Lease” information block. Each field defines a tunnel of gateways that allows you to reach the recipient. Full details contained in Lease:
Incoming gateway to the tunnel, which allows you to reach the recipient.
The time when the tunnel is obsolete.
A pair of public keys to be able to encrypt messages (for sending through the tunnel and for the recipient at the destination).
Routers send their routerInfo to netDb directly, and leaseSets go through an outgoing tunnel (leaseSets must be sent anonymously to avoid correlating the router with its leaseSets).
We can combine the above concepts to create a successful network.
To create her own inbound and outbound tunnels, Alice searches netDb to collect routerInfo. Thus, she collects lists of peers, which she can use as Hop (Intermediate points) in her tunnels. She can send a message for the first hop asking for the creation of a tunnel and ask the router to send a request to create a tunnel before the tunnel is built.
When Alice wants to send a message to Bob, she first searches netDb to find Bob’s leaseSet and get information about Bob’s current incoming tunnels. She then selects one of her outbound tunnels and sends a message through it with instructions to the outbound tunnel endpoint to forward the message to one of the gateways to the incoming Bob tunnel.
When the endpoint receives these instructions in the outgoing tunnel, it sends a request message and when the incoming gateway of the Bob tunnel receives the request, it is sent down the tunnel to the Bob router.
If Alice wants Bob to respond to a message, she must pass the instruction explicitly, as part of the message itself. This can be done by creating a higher layer, which is created in the stream library. Alice can also shorten the response time by putting her last leaseSet into the message, so Bob doesn’t need to do a netDb search to be converted when he decides to answer, but this is not necessary.
While the tunnels themselves have multilayered encryption to prevent unauthorized access to the peers within the network (the “transport layer” is encrypted by itself, to prevent unauthorized access to the network participants).
It is also necessary to add an additional layer of encryption to hide the message from the outgoing to the end point of the tunnel and the gateway of the incoming tunnel. This “honest encryption” allows Alice's router to wrap several messages into one “garlic message” (this is the fourth aspect), encrypted with the public key, so that the intermediary cannot determine the number of messages and what they contain.
For a typical connection between Alice and Bob, the message will be encrypted with the public key published in Bob’s lease set, allowing you to read the encrypted message on Bob’s router without issuing the public key
Another important fact. It must be borne in mind that I2P is completely based on messages, and that some messages may be lost along the way.
Applications on the I2P network can use their own interface in a message and take care of their own control of transmission and reliability, but most applications can work adequately using standard libraries for transferring data on an i2p network.
Due to the large amount of information, I will post the translations in parts.
If someone really cares about it, I ask under the "spoiler".
This is an *
Send corrections and corrections in lichku.
Official source: i2p2.de
Table of contents:
Part 1: “Everything you wanted to know and were afraid to ask about I2P”
Part 2: Tunnel Magic, NetDB, and Protocol Juggling
Part 3: Digital Garlic
')
Introduction
I2P is a scalable, self-organizing network that distributes packets between anonymous network layers, in which any number of applications can run, while ensuring a high level of security and anonymity. Each of these applications in itself, can be anonymous, have their own capabilities to manage the network, without worrying about the proper implementation of the control work free, distributed and asynchronous routing. I2P allows them to mix their work among a large number of already existing anonymous users working on the network.
Applications can use all the features of regular Internet, while combining anonymous web surfing, web hosting, anonymous chat, file transfer, blogging and other features that will be added later.
- Web surfing using any browser that supports work through a proxy.
- Chat: IRC, Jabber, I2P-Messenger.
- File sharing:
Torrents: I2PShark, Robert, Imule, PyBit, I2P-bt
Transfer directly between PCs: I2Phex - E-mail: susimail and I2P-Bote.
- Blog: using Syndie.
- Distributed data storage, save your data using cloud-based Tahoe-LAFS over I2P.
- Newsgroups using any proxy-supported reader program.
Unlike the websites hosted on the Freenet and GNUnet distribution networks, the websites hosted on I2P are completely interactive - there are traditional web services: search engines, bulletin boards, blogs have the opportunity to comment.
With all these anonymous applications, I2P takes on the role of "Charon" (He who carried souls across the river of the dead in Greek mythology) - the applications report that they want to send some data to the address provided by the cryptographic identifier (This is the destination) and I2P makes sure that the data is delivered secretly and anonymously. I2P is able to distribute packets so that information is transmitted as anonymously and reliably through several streams over TCP. At the same time, based on the algorithm, maximum throughput and minimum delays are ensured.
Several simple SOCKS proxy servers are available to associate the existing Internet with I2P, their capabilities have been limited, since many sites usually pose a threat to anonymity and put the user at risk.
The only safe way is full processing of applications to ensure proper operation, we provide a number of API interfaces that can be used to improve interaction with the network (here apparently means working with the Internet in both directions - approx. Lane).
I2P is not a research, academic, commercial or government project. This is a joint effort of engineers to do everything necessary to ensure a sufficient level of anonymity for those who need it. Active development has been carried out since the beginning of 2003 and occupied all the time of developers, there is also a special group consisting of participants from around the world who also participated in the development. The entire I2P source code is open and freely available on the website, most of the code is in the public domain, although several cryptographic procedures are used under a BSD license.
People working on I2P do not control what people do in client applications, and there are several applications available under the GPL license (I2PTunnel, susimail, I2PSnark, I2P-Bote, I2Phex, and others.).
Financing I2P comes exclusively from donations, and is not taxed (oh how bent), since many developers themselves are anonymous.
Principle of operation
Overview
To understand how the I2P network works, it is important to understand several key concepts:
First, I2P makes a strict separation between the software involved in the network (“router”) and anonymous ends (“targets”) associated with individual applications.
When I2P is used, it can be clearly seen, but what does it hide? It hides information about what the user is doing now (if at all), as well as the fact that the user is connected to a specific router. End users usually have multiple local addresses on the router — for example, one proxy for IRC servers, another to support a custom anonymous web server (“eepsite”), another for I2Phex, for example, the fourth for torrents, etc.
The second important aspect for understanding the work is the concept of a “tunnel”. A tunnel is a directed path through a clearly selected list of routers. Multi-level encryption is used, so each router can decrypt only one layer. The decrypted information contains the IP of the next router, along with the encrypted information that will be redirected. Each tunnel has a starting point (the first router, also known as a “gateway”) and an end point. Messages can only be sent one way. To receive the return message, one more tunnel is required.
There are two types of tunnels: outgoing tunnels send messages from the tunnel creator, while incoming tunnels send a message back to the tunnel creator. The combination of these two tunnels allows users to send each other messages. The sender ("Alice" in the image above) establishes an outgoing tunnel, while the receiver ("Bob" in the picture) creates an incoming tunnel. The gateway in the incoming tunnel can receive messages from other users and forward them to the end point (in this case, “Bob”).
The endpoint of the outgoing tunnel will have to send a message to the gateway to the incoming tunnel. To do this, the sender ("Alice") adds instructions to the encrypted message. As soon as the endpoint of the outgoing tunnel decrypts the message, it will receive instructions to forward the message to the correct incoming gateway (“Bob” gateway).
The third important point to understand is the NetDB network database. Several algorithms designed to exchange network metadata. There are two types of metadata: “routerInfo” and “leaseSets”:
routerInfo provides data about routers needed for the exchange of private router data (their public keys, addresses, etc.), while the leaseSet gives routers the information necessary to connect specific points.
LeaseSet contains the “Lease” information block. Each field defines a tunnel of gateways that allows you to reach the recipient. Full details contained in Lease:
Incoming gateway to the tunnel, which allows you to reach the recipient.
The time when the tunnel is obsolete.
A pair of public keys to be able to encrypt messages (for sending through the tunnel and for the recipient at the destination).
Routers send their routerInfo to netDb directly, and leaseSets go through an outgoing tunnel (leaseSets must be sent anonymously to avoid correlating the router with its leaseSets).
We can combine the above concepts to create a successful network.
To create her own inbound and outbound tunnels, Alice searches netDb to collect routerInfo. Thus, she collects lists of peers, which she can use as Hop (Intermediate points) in her tunnels. She can send a message for the first hop asking for the creation of a tunnel and ask the router to send a request to create a tunnel before the tunnel is built.
When Alice wants to send a message to Bob, she first searches netDb to find Bob’s leaseSet and get information about Bob’s current incoming tunnels. She then selects one of her outbound tunnels and sends a message through it with instructions to the outbound tunnel endpoint to forward the message to one of the gateways to the incoming Bob tunnel.
When the endpoint receives these instructions in the outgoing tunnel, it sends a request message and when the incoming gateway of the Bob tunnel receives the request, it is sent down the tunnel to the Bob router.
If Alice wants Bob to respond to a message, she must pass the instruction explicitly, as part of the message itself. This can be done by creating a higher layer, which is created in the stream library. Alice can also shorten the response time by putting her last leaseSet into the message, so Bob doesn’t need to do a netDb search to be converted when he decides to answer, but this is not necessary.
While the tunnels themselves have multilayered encryption to prevent unauthorized access to the peers within the network (the “transport layer” is encrypted by itself, to prevent unauthorized access to the network participants).
It is also necessary to add an additional layer of encryption to hide the message from the outgoing to the end point of the tunnel and the gateway of the incoming tunnel. This “honest encryption” allows Alice's router to wrap several messages into one “garlic message” (this is the fourth aspect), encrypted with the public key, so that the intermediary cannot determine the number of messages and what they contain.
For a typical connection between Alice and Bob, the message will be encrypted with the public key published in Bob’s lease set, allowing you to read the encrypted message on Bob’s router without issuing the public key
Another important fact. It must be borne in mind that I2P is completely based on messages, and that some messages may be lost along the way.
Applications on the I2P network can use their own interface in a message and take care of their own control of transmission and reliability, but most applications can work adequately using standard libraries for transferring data on an i2p network.
Source: https://habr.com/ru/post/160825/
All Articles