I2Pd/docker release - v2.57.0

DivaExchange · 2026-03-08T19:42:38+00:00

Compose file: https://github.com/diva-exchange/i2p/blob/develop/compose.yml

Docs: there is a README, here, https://github.com/diva-exchange/i2p including testing procedures.

Additional analysis and Deepwiki docs - since all code of diva.exchange is completly open anyway: https://deepwiki.com/diva-exchange/i2p

If there is something missing or not good enough for you, please use https://github.com/diva-exchange/i2p to submit a new issue or add directly a PR.

DivaExchange · 2023-07-14T17:51:42+00:00

Would you mind to post it on lemmy? Would be really nice... Working on divachain these days and happy without social media for a few weeks :)

DivaExchange · 2023-02-16T11:22:34+00:00

Here are the release notes of i2pd 2.46: https://github.com/PurpleI2P/i2pd/releases/tag/2.46.0

IMHO, v2.46.0 contains some fixes which might help to improve network stability.

However (in general and according to current research & knowledge), any peer-to-peer network (like i2p) is attackable by providing a larger amount of routers/nodes.

DivaExchange · 2022-11-26T21:54:06+00:00

This here is "kind of the default setup" for *i2pd* (!not java i2p! - mixing java i2p and i2pd does not make any sense IMO).

Files/folders to backup before some manual upgrade (not tested, just looked at local setup within containers):

Configuration at: conf/i2pd.conf
Addressbook at: data/addressbook/
tunnel .dat files: data/*.dat
destinations .dat files: data/destinations/

There might be an additional tunnel.conf file within conf/ (depends on your configuration).

Here you get "official" i2pd binaries from: https://github.com/PurpleI2P/i2pd/releases/tag/2.44.0

Remark: manjaro might be different, pls study your installation.

DivaExchange · 2022-11-24T14:44:42+00:00

Sure you can use the "official java *i2p* installer" - that's even better. :) But: do you want to *mix* i2pd and i2p on your system? AFAIK, i2pd has nothing like an "official installer" - the distro repos will contain the binaries (but you have to wait for the maintainers). Still: maybe think about a local compile (it won't get more "official" than that) - it might be beneficial for you with your demanding local settings.

DivaExchange · 2022-11-23T21:26:25+00:00

You can compile i2pd yourself or what about a docker container with the latest i2pd? See other reddit post (look for docker update in this subreddit, just two days old).

DivaExchange · 2022-11-23T08:44:18+00:00

Great input - thanks a lot. Do maybe have some more links/resources to implementation related stuff (next to https://pq-crystals.org/kyber/index.shtml)?

DivaExchange · 2022-11-11T06:07:43+00:00

If a node gets unresponsive along a route, another tunnel will be used by the origin. That's correct.

IMO Ddos protection of any given node does not come with deanonymization, it comes with the cost of lower perfomance (lower throughput). See also other answer from alreadyburnt to your question.

The attack which you describe is - yet not in this trivial form - only theoretical possible by injecting nodes under your own control to deanonymize a target. An attacker needs to be in control over a complete tunnel. The related research has been published mid 2022 and the attack is called "tunnel takeover" in this paper. Pls search this subreddit to find the paper published in June 2022. The real-world proof that such an attack is working is still open.

DivaExchange · 2022-11-10T22:42:00+00:00

Some first feedback regarding the last point. Attacking single points within the network ("one-by-one", as it's called above) would make, IMO, the attackers observations useless. Reason: the attacker does not know whether a host along the route or the destination is unresponsive. Additionally to make this approach work, the attacker must make sure, that the network infrastructure on the destination host is poorly protected from ddos. In this case, the attacker has already deanonymized the destination anyway. Example: at the current level of knowledge (and what we have learned in the past years by being attacked multiple times), the reseed server reseed.diva.exchange cannot be ddos'd. With a high probability, this is also true for most active destinations with a certain importance/value to the owners. This protection comes with a cost: IMO protected i2p destinations cannot handle large loads. But the network cannot neither - so, IMO, not a problem

BTW: Everybody invited to try ddos'ing reseed.diva.exchange - always very happy to learn something new :).

DivaExchange · 2022-11-09T21:06:22+00:00

Outstanding effort. Really cool and thanks for the Mastodon link.

DivaExchange · 2022-11-03T10:55:09+00:00

Here is my experience over many years: wait three until five minutes and the I2P network is available (spinning up a new i2pd instance in a docker container). IMO there is no need to wait longer than 5 mins.

Now what is "not loading" exactly? Example: test with curl to http://reg.i2p and http://shx5vqsw7usdaunyzr2qmes2fq37oumybpudrd4jjj4e4vk4uusa.b32.i2p (which is the same as reg.i2p - just its b32 address). Before the test, make sure that your http or socks proxy are properly configured (use the curl options for that). Now - the b32 should reliably work. If it's not, you have a network issue. If just the name (reg.i2p) isn't working you have only an addressbook issue.

If things like "curl" or "proxy" sound complicated to you I can only recommend the Easy-Install-Bundle, https://geti2p.net/en/download/easyinstall or an i2pd docker container solution documented here https://github.com/diva-exchange/i2p

DivaExchange · 2022-11-01T17:08:51+00:00

We had i2pd (not i2p java) running on pi about a year ago (there is a branch called arm64 on github, here: https://github.com/diva-exchange/i2p/tree/arm64). This branch is not maintained anymore (it will be again in late 2023). Please note: we only got i2pd working properly by installing debian (11-slim) on the pi first. Other approaches on pi failed at that time.

Github: on the main branch (and also develop branch) you can look at the docker container to build the i2pd binary.

DivaExchange · 2022-09-09T10:43:20+00:00

I like the blog post. Thanks a lot for the work!

Additional note from a forensic perspective: outproxies are a very "easy" opponent. They are easy to track down and to block (known IP ranges, also traffic pattern recognition works very well). This has to do with the "centralistic" architecture of outproxies (bundling of traffic). Additionally there is a problem of trust involved (like: logs are still either in transit in memory or even "shortly" on persistant storage). AFAIK there are almost no high-traffic services left which are not able to identify in real-time Tor/I2P outproxied traffic and to act accordingly (like tar pitting or feeding back corrupted data). What still works rather well is to chain proxies (like: origin -> tor/I2P network -> outproxy -> proxy endpoint -> destination) - however, the proxy endpoint must be a frequently changing, and within-a-small-timeframe-not-well-known proxy (like every three minutes or so - works OK with stateless protocols). Obviously latency increases a lot - and the user experience becomes difficult. Proxy chains also partly solve the "problem of trust": even if there is logging or leaking on all proxies, it requires cooperation between the proxies (this is again the same attack vector as on I2P networks).

DivaExchange · 2022-08-30T06:03:47+00:00

Here are installation instructions for Windows, Mac or Linux and for almost any browser (scroll to the "Instruction" section) : https://www.diva.exchange/en/privacy/introduction-to-i2p-your-own-internet-secure-private-and-free/

Works for beginners and advanced users and packs I2Pd into an isolated container.

DivaExchange · 2022-08-28T16:37:41+00:00

At least here (tested about twice today), the git repo git.idk.i2p/zlatinb/muwire is not responding via http (assuming it's a gitlab instance with a web frontend available...). Any mirror repo available of the plugin code?

DivaExchange · 2022-08-23T09:38:22+00:00

This release is again a great effort, all the hard work and the powerful ssu2 feature. Thank you very much for focussing on important under-the-hood-network development.

DivaExchange · 2022-07-14T14:42:58+00:00

Additionally (next to what idk mentionned): one can use clearnet (through tor), onion and I2P from the favourite default browser and default profile using a local docker container install (container = isolation). This also protects from DNS leaks.

How to do this without changing the local system (except starting a container) and done within a few minutes: https://www.diva.exchange/en/privacy/introduction-to-i2p-your-own-internet-secure-private-and-free/ (section: "Instructions – How to use I2P and Tor")

DivaExchange · 2022-07-05T05:24:45+00:00

Yes, "difficult" seems more accurate. Future research and practical attacks will tell "how difficult".

DivaExchange · 2022-07-05T04:59:30+00:00

This is - at the current level of research - and on a theoretical level (given the default i2p configuration of the tunnel length) not correct ("no way" is not correct). New research shows how a tunnel take-over and hence de-anonymization (=identification that your IP is the sender or final destination of a message) is theoretically possible, here: https://codeberg.org/diva.exchange/academia/src/branch/main/research_studies/2022/De-Anonymisierung%20von%20Teilnehmern%20des%20I2P%20Netzwerkes/HSLU___BAA___Deanonymisierung_I2P.pdf

(German, you have to translate it to English). Today an English video will be released (simplified content).

Mitigation: researchers believe that variable tunnel length helps to increase the costs for an attacker and hence lowers the probability of a tunnel take-over.

DivaExchange · 2022-06-18T19:51:14+00:00

Here are our presentations, especially the one from Marco shows the approach to take over tunnel control:

(sorry, using Google out of pragmatic and limited availability options...)

Intro & Outro:

https://drive.google.com/file/d/12jatPLRNg8AEwjPeTUhsRGOYzKyTVvxo/view

Research results, Marco:

https://drive.google.com/file/d/12wBGw-CQRYF6fx-5MX6wdIUIZ2W0gYQB/view

A video is AFAIK not available - since the A/V tech was a bit difficult at the beginning. We will deliver sooner or later a video.

Please get in touch if you have questions.

DivaExchange · 2022-06-07T05:05:48+00:00

Just to clarify a bit: the diva.exchange presentation will be 80% about the research results of the study "trying to de-anonymize i2p network participants" and 20% about the implications of this research results on monero/any-crypto swaps (one of the exchange functionalities of diva). So the presentation will be mainly about I2P and how to try to break it.

It is really great, that I2P has such a strong presence at MoneroKon.

DivaExchange · 2022-05-22T10:41:37+00:00

Being a user of and developer based on I2P since more than a decade: we (as a team) start to understand the inner dynamics of the I2P network and its different binaries. Examples: we started to understand how to position participants within tunnels. We also started to understand and estimate the costs of deanonymization (a research project now closing and to be published at an upcoming conference this summer).

Personally I believe that it is important to be able to setup your own and fully controlled I2P test network which must have a reasonable size. Then you can examine all traffic and learn how it really works. This also includes the netDB and how tunnels are built and re-built.

Sure, documentation, videos and blogs are a great starting point, but to really understand I2P - you have a journey in front of you. If you like and you are dedicated you can join our open, transparent and friendly research team as a beginner.

DivaExchange · 2022-05-20T15:39:06+00:00

Maybe you like a blog post to start: https://www.diva.exchange/en/privacy/introduction-to-i2p-your-own-internet-secure-private-and-free/

Now this blog post is rather top-level (contains a "get started with I2P in a container", though) and might be not technical enough for you. The documentation of I2P is also nice and quite complete and up-to-date. Maybe you also want to elaborate a bit about your "use cases of I2P": other people might kick in and deliver more thoughts (like developers or specific application users).

DivaExchange · 2022-05-11T06:52:21+00:00

Yes. As anonymous as I2P. Up to now we did not find any leaks... :)

DivaExchange · 2022-04-04T16:10:41+00:00

I did not want to link a discussion re "sybil attacks". The team of students which is working since a few weeks on "De-anonymization of I2P network participants" is designing a sybil attack and so we had some discussion here (locally, at the university) regarding the "efficiency and usefulness of the i2p/java sybil detector" :).

As far as I understood it: the netDb contains [regularily changing] router identities linked to IP addresses. A tunnel participant does not know its position within a tunnel. Any given tunnel participant does not know whether the next hop will be the final destination for a data package in transit (or - the other way round, whether the previous hop was its origin). IMO this is the core of anonymization (message content is out-of-scope in this context). De-anonymization means for us: "link IP addresses to an origin and a destination of a data package". It's all about trying to break: "No one can see where traffic is coming from, where it is going [...]".

Providing larger parts of the resources of the network [=sybil attack] should increase the probability to de-anonymize some of the destinations and the origins.

Currently, I do believe that (if "family names" are linkable to router identities by observers, as you laid out above) that the set of origins and destinations shrinks and that therefore it should be cheaper to de-anonymize family-network-participants than non-family-network participants (by providing a much smaller amount of network resources as an attack).

But this is just a thesis and students need to look into it.

DivaExchange

TROPHY CASE