The Invisible Internet Project

Today we are joined by IDK, who will be sharing with us

about I2P. And I2P is known also as the invisible internet project and has been around since

2003 and I might hear some cat purring in the background and she's telling me to go to sleep

and stop editing this podcast. So with no further ado, let's dive in.

Welcome and thank you for joining us here today, IDK from I2P.

Thank you for having me.

I kind of like was running around looking for you at CCC because I saw on the map that y'all were there

and I have heard about I2P for a few years but when I researched before this podcast episode,

I realized that I2P has actually been around since I saw the earliest research paper was from like

2009 or something. Yeah, yeah, I mean we started even earlier than that. That was the we we

this will be the 25th year we're going to come up on 25 here in more or less October. That is

incredible. Oh my goodness. Okay, immediately there's so many questions and I did like my

master's thesis on like local fur is peer to peer routing agnostic slash delay tolerant networks

and I covered a bit of like the history and some of the earliest ones that I could find back then

were actually like from 2011. So I2P is like way more established than those protocols that I

was studying but before we dive into what I2P is because that's I can think truly what I want to

ask so much about and I assure that other people are quite curious as well. We've heard or I heard

that you introduced this term garlic routing in comparison to like onion routing and tour but

before we dive in there what why did I2P start like what was the kickoff that initiated like the

need for I2P to exist when there already was something like onion routing or tour. Well as a

matter of fact there really wasn't. The thing is that tour and I2P started at Almas exactly the

same time and for almost well for for similar reasons they had slightly different trajectories

however garlic routing was actually coined by a fellow named Mike Friedman who was actually

one of the original authors on the onion routing paper with Paul Seiverson and Nick Bantheson if I

remember correctly. So but what garlic routing was was supposed to be is a way of bundling

multiple of what he would think of as the onion messages together into a single opaque bundle in

order to make the more harder to analyze the traffic by size as it moves through the network

because it's bundled with other stuff that's not necessarily related to it and that's the crude

explanation but the the interesting thing about the history here is that it's actually kind of

evolved down to distinct paths even though the original motivation is largely faded away.

The the tour I2P and FreeNet for a very long time there were considered sort of the big three

of the of the anonymous overlay networks the dark nets if you will and tour of course kind of

openly came out of research at the US Navy Research Lab laboratories and then it had this whole

credibility journey where it was turned over to the EFF and turned into an open source project

and eventually all the US NRL code really kind of just got moved out of it and reused and repurposed

and it's no longer really the the it really no longer shares too much of the the navy roots

anymore whereas I2P was kind of for better or for worse formed in reaction to the Navy's involvement

in tour the idea of building it as a peer-to-peer network where everybody participated in routing

was to eliminate this idea of like national stakeholders and things like that and in this

way it was sort of expressly cyberpunk and crypto anarchist compared to Taurus you know sort of

corporate approach which is not entirely fair to them either I have actually nothing but respect

for what tour does they do a hard job in a difficult environment and they do it very well

I'm just to clarify here crypto anarchist in this sense does not mean crypto bro anarchism

so it does not mean neoliberalism it means like more the crypto punk scene that came early on in

the 90s and has kind of evolved sentence right am I correct to interpret it that way yeah yeah

very much so and and expressly sort of in used in this case in sort of a

mutual aid sort of context like everybody helps everybody in I2P it's it's a very flat network

we don't try to build hierarchies this kind of tells the story a little bit about that values

that I2P stem from and to me intrinsically also ties into the network design of I2P and you

already mentioned it a little bit it's peer-to-peer right and the users also store their data locally

on their devices and share directly in that sense it depends on what you mean so I2P itself is just

a way of transporting data across the internet it's not really different from like h2tp or web

rtc and in that sense so but you know the difference is that we apply this this privacy

preserving procedure to it so you can do really whatever you want with it and as part of this

operation one thing that does happen is you participate in maintaining a table of the

peers that you know about and so that does get written down to the disc but it's the only thing

that intrinsically gets written down to the disc if you're not sharing files then you're not

sharing files for other people you're only sharing files for you're only sharing files if you're

consciously deciding to share files it's not like free net where your information gets sharded across

a bunch of nodes and then somebody gets gets information to to retrieve all the shards and then

put the information together it's not like it's not one of those models where you

where you become the redundant storage for somebody else's material it is just a way of

establishing the connections so it sounds to me almost like I2P is also filling a part of

an ecosystem like a piece of the puzzle yeah okay cool uh okay there's so many questions here

because when I was doing research but maybe that will get things slightly derailed but just

because I encountered so much information when I was doing research about this the videos I was

watching it was like in contrast to tour uh i2p does not let you connect to regular sites on the

internet i2p connects you to a hidden secret encrypted network is that how it works or is i2p

more agnostic to like what it's connecting between and more facilitating the connection in a private

way yeah you we're really just facilitating the connections in a private way um it is it is true

that as far as the the internal operation of the network goes it's not intrinsic to us that we

have egress traffic like it is tour but it's also not impossible to build it to us egress traffic

is just a just another kind of hidden service another kind of hidden service and we call it an

out proxy what's this term you're using here it's new to me egress traffic like traffic that leaves

the hidden service network for the wider internet and then presumably send some kind of response

okay cool and one of the topics that's when reoccurring on this podcast because also like a lot

of projects in the past 10 15 years or so which of course is not as long as i2p is been existing

but in the past 10 to 15 years there's been this kind of shift where like at least scuttlebutt and

hypercore or formerly non-dut they started moving from trying to solve like the entire protocol

being like one entire giant protocol that's supposed to do everything to moving towards being

more modular and this kind of ties back to what you were talking about of i2p fitting like one

part of a larger ecosystem is is that always how it has been fried to pee or has that journey changed

and what other parts do you fit with right now and what other parts do you see yourselves fitting

fitting within the future well um you know i2p stands for the invisible internet and at the time

in the in the sort of the hacker culture there was a it was kind of important to build a distinction

between the internet and the web so i2p kind of distinguished itself by saying no we're going to

host all kinds of services and we're going to make them intrinsic to our network if we can and so

yeah it definitely did have this original idea of building an actual invisible internet with

things that you know at the time like irc and you know SSH servers and arbitrary applications

that you just tunneled over your hidden service network um and to some extent towards capable

of doing this too and and that's fine but that's also uh but it's not really their the raison

depth for like it is for us and i think it shows in our design you know we we've kind of planned

to be scalable to an invisible internet that's amazing and the times are becoming more and more

pressing to do that i was seeing today that like a lot of people are using i2p for torrenting

linux distros that don't use system d slash h verification yeah yeah like that's so weird

you know the world is be like you get into this and you've got this vision of what

oppression looks like or is gonna look like and some it to some extent you're right and then

sometimes it just comes out of the blue and is so weird and out of the way and ill conceived

that you just wonder about the foolishness oh i don't usually like to talk about my my

politics i don't like to burden people with them but gosh it's not a burden cumbersome yeah

yeah it's kind of uh it feels like a curveball that i think an entire movement was uh not quite

seeing but also at the same time that is exactly where oppression is going to start yeah it's in

the movements that are trying to make things more free more liberated more available more egalitarian

yeah well and also i think in my experience as you know growing up in america um in in around

the time uh you know between 1999 and 2001 was pretty pivotal shift for the way america treated

its children um we went from uh we went from walking to school to walking through metal detectors and

we went from being able to get on airplanes to eventually kids having to get you know state

issued ids to get on airplanes and i think there's a certain degree to which the uh the age

verification to me speaks of the way that the surveillance normalizations are being directed

expressly at children so that they don't protest them in their adult life and fortunately in england

it's kind of backfiring right now they're drawing mustaches on themselves with makeup markers and

defeating the verification filter which is just hilarious but also sad yeah i mean the the

verification was never there for actual kids no no it's obviously not there to normalize surveillance

on them it's not going to protect yeah exactly and implemented by the people you know we are

yeah it's okay so this is a solar punk podcast

yeah it's really easy to just continue spiraling into the darkness of what's going on in the world

right now and especially when it starts creeping in on our own communities but that's also something

that i thought was like speaking of lightness or like not lightness but speaking of

solutions to these kind of challenges because we shouldn't face away from the challenges but

rather straight up them and trying to solve them and that's something i2p is doing and i think

you mentioned this earlier but like i2p is used for torrenting and i2p is for distributing

districts of linux without system b um we we kind of went into the topic a little bit just

to dive back in when we talk about tour and when we talk about onion routing and when we talk

about garlic routing you mentioned earlier that there's this whole bundling of messages that happens

in i2p that does not happen and for example tour um and you mentioned that i2p is a peer-to-peer

system that facilitates connections and i was also reading up a little bit online that there's

you can have inbound connection and outbound connections but they never pass through the same

notes it's always like different from an expert to a novice how would you describe onion and how

would you describe garlic routing and what are the use cases now for garlic routing and what are

the future use cases for garlic routing that you see well right now i'd say that their use cases

are fairly similar they're both visual metaphors right you're peeling the layers of an encrypted

structure and peeling corresponds to a decryption and the visual metaphor extends to the visual

similarity between onions and garlic you have an onion bulb which is one sort of single structure

and then you have a garlic bulb that if you break it apart has these multiple onion-like structures

inside of it uh to be uh explicitly honest this is also a a relatively unexplored and

even for us kind of experimental even at this stage uh sort of sort of idea the goal with it uh though

is to combine messages that are not necessarily related in a single bulb and the bulb then gets

transmitted over the wire and that has the effect of obscuring the size of the actual

cloves within the bulb and also changing hypothetically the size of the bulb as it goes across the

network and that is supposed to and in theory may help with uh size-based analysis of data that

we're trying to keep private let's see i try to keep this very simple um or maybe a metaphor will

work so suppose you are trying to figure out who uses the most electricity and an electrical

network you are going to track people's usage right well you can kind of do the same thing

for hidden services in terms of bandwidth and if you have like a high bandwidth hidden service

you can tell oh this residential computer uh served 500 gigabytes of data to the door network

i bet there's a hidden service there right um so so so we uh so by breaking this data apart and

recombining it we try to foil this kind of traffic analysis and turns out it's actually

really hard uh it is probably limited protection but it is protection um and we do study it and we

are trying to uh see where we can apply it more and improve it uh to make this kind of protection

more effective and you know we kind of do this in order to continue to be what they call low latency

at least it used to be the definition of low latency was that you were sending data as fast as you

can get it minus the queue that sent it um now i mean something a little bit different because

at least in the context of places like nim and things like that but that's the definition that

we're using for it and so we don't have to delay things through the network to obfuscate where

they're going yeah because that was another point that i've heard mentioned that with tour if you're

a government or some very large entity that can monitor both the incoming and

outcoming port so to speak or like uh nodes yeah the data flows more or less yeah then you can

kind of locate who is who and de-anonymize data but i took he kind of circuments that issue

to a to an extent for certain things the the difficulty is that even in a situation like

tour uh this kind of attack only work on certain kinds of hidden services they have to sort of

stay in the same place and they have to have a lot of customers so like if you're doing things at

a tremendous scale over either tour or i2p and people are trying to target you with these data

flow analyses i think for right now you're probably still in pretty big trouble uh but

if you are doing something where you can cycle your identity fairly frequently and maybe use a

long-term identity that is blinded and not revealed to the network then you can actually use these

technologies to um to be anonymous long-term because the kinds of attacks that are possible

against these at-scale hidden services are not necessarily going to be possible against your

bittoral client or your chat app i think that's a fair assessment of where the defenses are at

right now and i'm not sure that there's a great way to protect an at-scale hidden service other

than to like send an equivalent amount of cover traffic down a pipe to somebody else's hidden

service uh and that sounds like madness yeah

uh i can't imagine the volumes of data that would require yeah it's uh it's kind of crazy

there are people trying it and we're reading their papers um but it's uh we're skeptical

because that's another aspect i noticed there's a lot of papers written about i2p yeah i didn't

count but there seems to be like a relatively large uh network of researchers who are looking

at i2p and studying i2p yeah i think we owe some of that to a few researchers that we have been

that we worked with in europe um and a couple more who took an interest in us out in Colorado

and then i think there's a professor in japan who's got a thing for us as well oh and then there's

a friend of mine ben who is a t.a. in boston who got a couple of skits to work on the paper at

darthmouth we've been very grateful uh there should be about four more papers that we know about

coming out this year one of which is going to be on machine learnings are you yuri

wait like you're okay let's roll that back a minute

so i2p and machine learning in the same sentence and paper uh why and how i think uh i guess what

they're going to do is try and apply machine learning to that same traffic flow analysis um

and see how granular they can get it uh and maybe make it work for things that are

at smaller scale than the large darknet markets and whatever and we'll have to respond to that

and it might involve changes to how we do darlic encryption or something along those lines as well

it's likely system that it might affect so this is something i'm really curious about because

you mentioned already before our current conversation and it's something we've touched

on a little bit now uh which is like what you're currently developing slash working on and i2p

has changed a bit over the years but the general concept is saying the same it sounds like what

is in the pipelines right now what is where which direction are you heading well a couple of different

directions actually um one very big very important uh project that we're working on right now is

post quantum enable we did post quantum encryption for our tunnel mechanism and now we're working on

post quantum encryption for our transport mechanism switch or distance from the tunnel mechanisms and

then after that that probably projects probably going to take another year possibly a year and a

half then we are going to move on to post quantum signatures and that will sort of complete our

migration to post quantum hybrid cryptography and maybe maybe we might be the first one of our

class of networks to do that successfully that would be pretty cool um the other thing that we're

doing is we're working on using some of the third party or in in one case sponsored implementation

to do things like enablement and other software stacks so uh about two years ago a uh rust developer

named um RO outton and wrote emissary which is a full implementation of an i2p router in rust um

and a few months ago i i completed a an effort to write an i2p router in go and basically what we're

doing now is trying to make the um as transparent as possible to integrate those into other applications

so if we're successful uh you know i'm probably going to try and get i2p into sync thing and you

know an acrylix torrent which is used in a bunch of bit torrent clients and you know if i if i'm

really lucky maybe tail scale or something like that and the goal of this is you know everybody

in right i2p helps everybody right so by enabling more applications and helping people get get the

things that they want working on the network we help ourselves by uh distributing the network to

more people and getting them participated in routing and uh showing them that you know being a part of

this network has uh has benefits that extend to that so there's like two follow up questions or

two questions that i've been like brewing on here while listening to you uh the first one's

related to the quantum encryption and the second one is related to your efforts of collaborating so

i'll just do them in order and you can take them off however you want um but uh the first one is

regarding quantum encryption and i've heard of a few different approaches to quantum encryption

and a PhD i knew was writing a paper and he approached it by having an encryption that changed

every few seconds which seems maybe not sustainable but i'm very curious about what your approach is

there and then the second question is um are you building like an SDK software development kit for

other projects to engage with i2p through or are you doing it more by project to project basis

and how are you engaging but yeah starting with first quantum stuff fortunately for us we don't

have to roll our own uh roll our own thing the researchers have already done at least a significant

uh part of the research work for us our job mostly boils down to the subtleties of our own

implementation because everything that we use for cryptography is ultimately based on some variant

or the noise protocol handshake so for tunnels um it actually kind of depends on the context but

it's going to be noise ik or noise n and then for ntcp and ssu2 for transports they're going to be

noise ik and and that's actually uh that important um in detail except to know that because it's

all noise based we get the benefit of all the research that has been done on post quantum

noise handshakes so ultimately we're just doing the noise handshake from the post quantum noise

paper awesome that's one of the great benefits of working with existing and established ecosystems

that one doesn't have to build one's own wheels every time yeah yeah well then also in

the cryptography is hard like i remember the first time i really got my head around key

compromise interpretation you know they're not going to bother to explain it just if you

want to know why cryptography is hard get your head around key compromise interpretation

it is uh it is magic math that cares what kind of pen you use as the cryptographers say yeah

so the other thing uh the other question you asked was are we building an sdk and yes

yes absolutely we're building an sdk um two of them in fact we're building the uh the go one

works if you compile it from the the tip of the source i'll cut a release here in the next week

or so call it's called on ramp and it's of course sort of geared toward go developers and then the

rest one is a little as far along but i'm gonna circle back and try to influence our

uh toward that when uh when i have time but we uh but yeah we're gonna build sdk's the goal being

to make it as easy to use as whatever library they're over to using whether that's you know

standard go or standard roast or tataio or whatever that would be to pee for the ipf systems or

yeah that's super exciting and i know a lot of people who are protocol developers who are

going to be very glad to hear this and i think here is somewhere where i would also like to clarify

a little bit because i'm sure i'm not the only one who's a little bit confused about what's

compatible with what especially when we enter like the rote local first slash peer-to-peer

realms so would i2p function in a delay tolerant network do you know what i mean when i say that

yeah um and the certain things would i think yes um it did you know i suppose it kind of depends

on the delay certain aspects of the network are uh our time sensitive you have to have like

synchronized clocks to uh to know how old a router info is for instance um but there are certainly

parts of it that could be delay tolerant um yeah and i'm guessing just to call to clarify because

i'm using one of those terms again but uh like yeah the delay tolerant in this sense becomes

very important because if you have internet shutdowns or if you have regions where connectivity is

very poor like the amazon rainforest or something you want to still be able to connect when the

connection is back up again so kind of opportunistically connecting and which is very different from how

mmm server client systems work where you need continuous uptime but does that then mean just

to interpret your answer a bit it doesn't sound like it's ready to go out of the box for delay

tolerant networks but it sounds like there is some sort of compatibility potentially how much

tweaking like let's say i'm a developer and i get access to your sdk can i just implement it in my

protocol so is it do i have to do something um so i can answer the question for a couple of your

cases um in the case of something like an internet shutdown uh your we can handle that to a pretty

well-defined tolerance which i believe if i recall correctly is 72 hours although that might be a

soft delay and what i mean by when i say that is that um you will have enough peers in your network

who are not considered stale by your local router to rejoin the network without reaching out to a

bootstrap server first and this actually has an interesting side effect too which it mean which

is that if you know other people who are behind the shutdown that appears on your network you might

actually stay connected to them depending on this how the shutdown works so you'll end up with a

sort of mini i2p inside the shutdown network it's kind it's called it's a phenomenon of network

segmentation and whether or not it's a good thing or a bad thing sort of depends on your

perspective and your threat model um but it is a sort of side effect of what can happen in these

kinds of situations and then when the shutdown ends you'd re you'd rejoin the larger network um so to

that for that sort of situation then then yes it would be uh it would be tolerant of delays uh but

any deeper than that it gets more subtle um you know you need to if you have to get a message

somewhere then uh you can do that opportunistically or you can store the message somewhere and

storing the message somewhere is more convenient usually and we don't do that so maybe you have to

do that in your application so so so it's a it's a bit subtle there is some out of the box

functionality for this asynchronous phenomenon but it is mostly around our own network resilience

and not really exposed to the applications awesome uh i have two questions that immediately just like

emerge within me and one is you said the local router do you mean local node or do you literally

mean local router like uh that's the kind that's the software we call the i2p node um it's a it is a

router it actually routes traffic for other people so we call it that we call it a router

i was my mind was going to physical hardware routers and i was like oh

okay but great uh that helps clarify that and then the other aspect i was thinking you mentioned

that there's like this uh impromptu like local network that can form when internet connectivity is out

um and that ties into two things uh does does i2p care about

how the data is transferred like is it like is it sneaker not compatible can it like connect

via any sort of means or is it tied to the internet infrastructure as we know it um yeah first part

of the question um for i2p as it exists right now you pretty much need something ip shaped

to run it off there are actually other kinds of darkness like cjdns and igdrasil

um that are non-anonymous that uh we actually do to some extent interact with and you can route

i2p over those but those are still pretty much just ipv6 networks uh that have slightly different

properties than the one that um we have now that being said though there are like the the tricky

bit is to make sure that the things that you change about how the network operates don't affect

how anonymous the users are so like yeah we could probably implement some kind of sneaker net

transport arguably sort of at least at the bootstrap level we do so like i2p relies on this

distributed data structure to find the peers in the network that you need to uh to they need to

talk to and we transmit the information about these distributed data structures over what we call

the transports now um and so if the uh but the transports are just sort of an interface

so if we wanted to we could in theory make a sneaker net transport where you plug a plast drive

into your computer hit the sneaker net transport button it copies something to your flash drive

you know to the next computer any trans any of uh shared some transport information and to some

extent like that kind of exists um for for instance like when you join the network you get a zip file

full of pure seed information and that is possible to transfer over the sneaker net now and that's

exactly the sort of data that would be transferred over the um over the regular transport ports except

it's being transferred involved there another interesting possibility might be to build something

on top of like lower when or mesh mesh tastic to exchange exactly the same routing information

although you know each of those things sort of has different kinds of exposure uh that it gives

you two um sneaker net will be timing sensitive mesh tastic is broadcasting messages encrypted or

not into the air uh around your house so like uh absolutely we could but it is a situation where

more research is required to determine whether or not we should. Last but not least maybe about

of these kind of questions the the there's been a researcher uh who's kind of dubbed this

phenomenon uh grassroots networks and in scuttlebutt we used like that a network didn't have a single

term um and it basically is just different ways of describing if a network enables you to start

one part of a network a circle let's say in one area that later meets another circle in another

area and then they can integrate with each other is that possible with i2p as well yeah absolutely

in fact i think it's probably really one of our defining features yeah the network as long as it

can contact itself eventually converges into a into a global phenomenon yeah well i'm a little

bit lost track of how long this episode is because we've had a lot of coming to the issues

yeah um but uh hopefully that will be entirely not noticeable when i have been finished editing

this podcast um but uh on that note you mentioned that you're building these SDKs and what the

next steps are exciting that they're going to be released so soon and he's mentioned also that you

have a release already next week or in two weeks or something oh i'll have it ready soon um i'm

definitely a week feels like a week feels like plenty in time but a week always feels like plenty

in time yeah so a month yeah exactly i mean to you know patted out like monty scot

nice maybe we'll synchronize the releases of this podcast episode on your release or we'll see how

we go about it but uh people who want to contribute to IDK or sorry no saying your name

but uh people who want to contribute to i2p um how do they go about it well we accept uh

contributions on github and gitlab um and we're also pretty flexible about things like

uh receiving patches to our security and research emails uh which are security at itp.net

and research at git itp or research at itp.net um where we we've taken patches over irc

in the project internal irc that's itprc and it's built into the um both i2p and itpd

so if you can connect to it there then you can connect to us and we will accept patches over irc

uh we've accepted patches via paste bin mostly we just want to be able to review the code

um but the easiest way to get us is probably either github or irc is there anything else that

you're sitting with you're like yes this should be mentioned before we wrap up oh um you know i

think that the the um might be good to point out the the namespaces for the two new router projects

there is uh eepnet emissary it's eepnet slash emissary on github that's the rest implementation

and then go itp slash go itp uh is the go implementation and one last thing is that uh for about 12

13 years we were unable to take donations due to not being a registered nonprofit

we have since partnered with a registered nonprofit uh stormycloud.org so if people want to donate

i2p they can donate via stormycloud now. awesome actually that ties into one of the questions

that i forgot to ask that i usually ask which is how do you fund yourselves? well for a long time

we didn't. yeah nowadays yeah we have a certain degree of we have more flexibility in how we fund

things now and um with with stormycloud being involved and so you know my taxes got easier

that's for sure. congratulations for that happy to hear the more sustainability the better um

well thank you so much for joining idk and i hope to run into you again sometime have a lovely day

yeah you too thank you for having me on your podcast again thank you take care you too

so

so