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