Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Intro #31

Closed
Shoalsteed opened this issue Sep 9, 2021 · 2 comments
Closed

Intro #31

Shoalsteed opened this issue Sep 9, 2021 · 2 comments

Comments

@Shoalsteed
Copy link
Owner

https://geti2p.net/en/about/intro
change:

Is that why I see IP addresses of other I2P nodes in the router console? Does that mean my IP address is visible by others?

Yes, this is how a fully distributed peer-to-peer network works. Every node participates in routing packets for others, so your IP address must be known to establish connections. While the fact that your computer runs I2P is public, nobody can see your activities in it. You can't say if a user behind this IP address is sharing files, hosting a website, doing research or just running a node to contribute bandwidth to the project.

@Shoalsteed
Copy link
Owner Author

Gentle Intro - broken down. I do wonder if we actually need it.

https://geti2p.net/en/docs/how/intro

I2P is a project to build, deploy, and maintain a network supporting secure and anonymous communication. The project also provides software that includes a router, applications, and advanced configuration options.

People using I2P are in control of the tradeoffs between anonymity, reliability, bandwidth usage, and latency. There is no central point in the network on which pressure can be exerted to compromise the integrity, security, or anonymity of the system. The network supports dynamic reconfiguration in response to various attacks, and has been designed to make use of additional resources as they become available.

I2P is designed to allow peers using I2P to communicate with each other anonymously. Both sender and recipient are unidentifiable to each other as well as to third parties.

The network itself is message oriented. It is essentially a secure and anonymous IP layer, where messages are addressed to cryptographic keys (Destinations) and can be significantly larger than IP packets. Some example uses of the network include "I2P Sites" (webservers hosting normal web applications within I2P), a BitTorrent client ("I2PSnark"), or a distributed data store. With the help of the I2PTunnel application, we are able to stream traditional TCP/IP applications over I2P, such as SSH, IRC, a squid proxy, and even streaming audio. Most people will not use I2P directly, or even need to know they're using it. Instead their view will be of one of the I2P enabled applications, or perhaps as a little controller app to turn on and off various proxies to enable the anonymizing functionality.

An essential part of designing, developing, and testing an anonymizing network is to define the threat model. There is no such thing as "true" anonymity, just increasingly expensive costs to identify someone. I2P's intent is to allow people to communicate in environments or situations where protected communication and identity is needed, by providing good anonymity, mixed in with sufficient cover traffic provided by the activity of people who require less anonymity. This way, some users can avoid detection when a personal threat model requires it alongside others with different privacy needs. On the I2P network all of these messages are essentially indistinguishable from the others.

How Does it Work?
The network at a glance is made up of a set of nodes ("routers") with a number of unidirectional inbound and outbound virtual paths. Each router is identified by a cryptographic RouterIdentity. Routers communicate with each other through existing transport mechanisms (TCP, UDP, etc), passing various messages. Client applications have their own cryptographic identifier ("Destination") which enables it to send and receive messages. These clients can connect to any router and authorize the temporary allocation ("lease") of some tunnels that will be used for sending and receiving messages through the network. I2P has its own internal network database for distributing routing and contact information securely.

Network topology example
In the above, Alice, Bob, Charlie, and Dave are all running routers with a single Destination on their local router. They each have a pair of 2-hop inbound tunnels per destination (labeled 1, 2, 3, 4, 5 and 6), and a small subset of each of those router's outbound tunnel pool is shown with 2-hop outbound tunnels. For simplicity, Charlie's inbound tunnels and Dave's outbound tunnels are not shown, nor are the rest of each router's outbound tunnel pool (typically stocked with a few tunnels at a time). When Alice and Bob talk to each other, Alice sends a message out one of her (pink) outbound tunnels targeting one of Bob's (green) inbound tunnels (tunnel 3 or 4). She knows to send to those tunnels on the correct router by querying the network database, which is constantly updated as new leases are authorized and old ones expire.

If Bob wants to reply to Alice, he simply goes through the same process - send a message out one of his outbound tunnels targeting one of Alice's inbound tunnels (tunnel 1 or 2). To make things easier, most messages sent between Alice and Bob are garlic wrapped, bundling the sender's own current lease information so that the recipient can reply immediately without having to look in the network database for the current data.

To deal with a wide range of attacks, I2P is fully distributed with no centralized resources. There are no directory servers keeping statistics regarding the performance and reliability of routers within the network. As such, each router must keep and maintain profiles of various routers.

Content sent over I2P is encrypted through three layers:
Garlic encryption (used to verify the delivery of the message to the recipient)
tunnel encryption (all messages passing through a tunnel is encrypted by the tunnel gateway to the tunnel endpoint), inter router transport layer encryption (e.g. the TCP transport uses AES256 with ephemeral keys).

The two main mechanisms for allowing people who need strong anonymity to use the network are explicitly delayed garlic routed messages and more comprehensive tunnels to include support for pooling and mixing messages.

History
The project started in October 2001 as a “desire for instant communication with other Freenet users to talk about Freenet issues, and exchange Freenet keys while still maintaining anonymity, privacy and security.” It was called IIP — the Invisible IRC Project. To quote the developer who started the project "I believe most people want this technology so they can express themselves freely. It’s a comfortable feeling when you know you can do that. At the same time we can conquer some of the problems seen within the Internet by changing the way security and privacy is viewed, as well as the extent to what it is valued."
More information about the history of the project can be found in the blog post 20 Years of Privacy: A Brief History of I2P

Team
The project is comprised of a small team working to advance different aspects of the project including its protocol application layer, design.usability and outreach. The entire system is open source. The router and most of the SDK (software development kit) are public domain with some BSD and Cryptix licensed code. Some applications like I2PTunnel and I2PSnark are GPL. Almost everything is written in Java (1.5+), though some third party applications are being written in Python and other languages. The code works on Sun Java SE and other Java Virtual Machines.

The current source is available in Gitlab.

For more in-depth information about the network, its protocols and encryption methods, please see the I2P Technical Docs.

@Shoalsteed
Copy link
Owner Author

need to continue to combine the gentle intro and the new intro.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant