Giriş

I2P, üzerinde herhangi bir sayıda farklı anonimlik veya güvenlik bilincine sahip uygulamanın çalışabileceği, ölçeklenebilir, kendi kendini düzenleyen, esnek bir paket anahtarlamalı anonim ağ katmanıdır. Bu uygulamaların her biri, özgür bir rota karma ağının uygun şekilde uygulanması konusunda endişelenmeden kendi anonimliklerini, gecikme sürelerini ve verim uzlaşmalarını yapabilir ve etkinliklerini halihazırda I2P üzerinde çalışan daha büyük anonimlik grubuyla harmanlayabilir.

Var olan uygulamalar, anonim web üzerinde gezinme, web sitesi barındırma, sohbet, dosya paylaşımı, e-posta, blog oluşturma ve içerik paylaşımı, haber grupları ile ayrıca geliştirilmekte olan diğer birçok uygulama gibi tipik İnternet etkinliklerinin tamamını karşılamaktadır.

  • Web üzerinde gezinme: Vekil sunucu desteği olan herhangi bir web tarayıcı kullanılabilir.
  • Sohbet: IRC, Jabber, I2P-Messenger.
  • Dosya paylaşımı: I2PSnark, Robert, iMule, I2Phex, PyBit, I2P-bt ve diğerleri.
  • E-posta: susimail ve I2P-Bote.
  • Blog: Pebble uygulama eki ya da Syndie dağıtılmış blog yazılımı.
  • Dağıtılmış veri depolama: Verilerinizi I2P üzerinden Tahoe-LAFS bulutunda yedekli olarak kaydedebilirsiniz.
  • Haber grupları: Vekil sunucu desteği olan herhangi bir haber grubu okuyucusu kullanılabilir.

Unlike web sites hosted within content distribution networks like Freenet or GNUnet, the services hosted on I2P are fully interactive - there are traditional web-style search engines, bulletin boards, blogs you can comment on, database driven sites, and bridges to query static systems like Freenet without needing to install it locally.

Anonimliğin etkin olduğu tüm bu uygulamalarla, I2P ileti odaklı ara yazılım rolünü üstlenir. Uygulamalar bir şifreli belirtece ("hedef") bazı veriler göndermek istediklerini söyler ve I2P verilerin oraya anonim bir şeklikde güvenli olarak ulaşmasını sağlar. Ayrıca, I2P en iyi çabayla anonim iletilerin güvenilir, sıralı akışlar olarak aktarılmasını sağlamak için basit bir akış kitaplığı sağlar ve ağın yüksek bant genişliği gecikme ürünü için ayarlanmış TCP tabanlı bir tıkanıklık kontrol algoritmasını şeffaf bir şekilde sunar. Var olan uygulamaları ağa bağlamak için birkaç basit SOCKS vekil sunucusu bulunsa da, hemen hemen her uygulama, anonim bir bağlamda hassas bilgileri rutin olarak açığa çıkardığından, bunların değeri pek bilinmemiştir. İlerlemenin tek güvenli yolu, düzgün çalışmayı sağlamak için bir uygulamayı tamamen denetlemek ve ağdan en iyi şekilde yararlanmak için kullanılabilecek çeşitli dillerde bir dizi API sağlamamıza yardımcı olmaktır.

I2P, akademik, ticari veya resmi bir araştırma projesi değildir. Gerek duyanlara yeterli düzeyde anonimlik sağlamak için ne gerekiyorsa yapmayı amaçlayan bir mühendislik çalışmasıdır. 2003 yılının başından beri bir tam zamanlı geliştirici ve dünyanın her yerinden özel bir yarı zamanlı katılımcı grubuyla etkin şekilde geliştirilmektedir. I2P üzerinde yapılan tüm çalışmalar açık kaynak kodludur ve web sitesinde ücretsiz olarak sunulmaktadır. Kodun çoğu doğrudan herkese açık olarak yayınlanır. Birkaç şifreleme rutini BSD tarzı lisanslar altında sunulur. I2P üzerine çalışan kişiler, istemci uygulamalarını kimlerin yayınlayacağını kontrol etmez ve GPL lisansı ile birkaç uygulama vardır (I2PTunnel, susimail, I2PSnark, I2P-Bote, I2Phex ve diğerleri.). I2P için Kaynak tamamen bağışlardan sağlanır ve geliştiricilerin çoğu anonim olduğu için şu anda herhangi bir yasal yetki bölgesindeki herhangi bir vergi indiriminden yararlanılmıyor.

İşletme

Özet

I2P işleyişini anlamak için birkaç temel kavramın anlaşılması önemlidir. İlk olarak, I2P, ağa katılan yazılım (bir "yöneltici") ile bireysel uygulamalarla ilişkili anonim uç noktalar ("hedefler") arasında kesin bir ayrım yapar. Birinin I2P çalıştırdığı gerçeği genellikle bir sır değildir. Gizli olan, kullanıcının ne yaptığı, herhangi bir şey yapıyorsa belirli bir hedefin hangi yönelticiye bağlı olduğu hakkında bilgidir. Son kullanıcıların yönelticilerinde tipik olarak birkaç yerel hedefi olacaktır. Örneğin, biri IRC sunucuları için vekil sunucuyu, bir başkası, kullanıcının anonim web sunucusunu ("I2P Sitesi"), diğeri bir I2Phex kopyasını, diğeri torrent kullanımı gibi işlemleri destekler.

Anlaşılması gereken bir diğer kritik kavram da "tünel"dir. Tünel, açıkça seçilmiş bir yöneltrici listesi üzerinden yöneltilen bir yoldur. Katmanlı şifreleme kullanılır, bu nedenle yönelticilerin her biri yalnızca tek bir katmanın şifresini çözebilir. Şifresi çözülen bilgilerde, iletilecek şifreli bilgilerle birlikte bir sonraki yönelticinin IP adresi bulunur. Her tünelin bir başlangıç noktası ("ağ geçidi" olarak da bilinen ilk yöneltrici) ve bir bitiş noktası vardır. İletiler yalnızca bir şekilde gönderilebilir. İletileri geri göndermek için başka bir tünel gereklidir.

Gelen ve giden tünel şemaları

Şekil 1: İki tünel türü: Gelen ve giden.

İki tür tünel vardır: "giden" tünel tünel oluşturucudan dışarı iletiler gönderirken, "gelen" tünel iletileri tünel oluşturucuya getirir. Bu iki tünel bir arada kullanılarak kullanıcıların birbirlerine ileti gönderilmesi sağlanır. Gönderici (yukarıdaki görselde "Alice") bir giden tünel kurarken alıcı (yukarıdaki görselde "Bob") bir gelen tünel oluşturur. Gelen tünelin ağ geçidi, herhangi bir başka kullanıcıdan ileti alabilir ve bunları uç noktaya ("Bob") kadar gönderir. Giden tünelin uç noktasının, gelen tünelin ağ geçidine ileti göndermesi gerekir. Bunu yapmak için gönderici ("Alice") şifreli iletisine yönergeler ekler. Giden tünelin uç noktası iletinin şifresini çözdüğünde, iletiyi doğru gelen ağ geçidine ("Bob" ağ geçidi) iletmek için yönergeleri almış olur.

Anlaşılması gereken üçüncü kritik kavram, ağ üst verilerini paylaşmak için kullanılan bir çift algoritma olan I2P "ağ veritabanı" (veya "netDb") olacak. Taşınan iki üst veri türü "Yöneltici Bilgileri (RouterInfo)" ve "Kiralama Kümeleri) LeaseSets)" - Yöneltici Bilgileri, yönelticilere belirli bir yöneltici ile iletişim kurmak için gerekli verileri (herkese açık anahtarlar, aktarım adresleri, vb.) verirken, Kiralama Kümesi yönelticilere belirli bir hedefle iletişim kurmak için gereken bilgileri verir. Bir Kiralama Kümesi bir dizi "kiralama" içerir. Bu kiralamaların her biri, belirli bir hedefe ulaşmayı sağlayan bir tünel ağ geçidi belirtir. Bir kiralamadaki tüm bilgiler şunlardır:

  • Belirli bir hedefe ulaşmayı sağlayan bir tünelin gelen ağ geçidi.
  • Bir tünelin geçerlilik süresi.
  • İletileri şifreleyebilmek için (tünelden göndermek ve hedefe ulaşmak için) herkese açık anahtar çifti.

Yönelticiler, Yöneltici Bilgilerini doğrudan Ağ Veritabanına gönderirken, Kiralama Kümeleri giden tüneller üzerinden gönderilir (bir yönelticinin kendi Kiralama Kümesi ile ilişkilendirilmesini önlemek için Kiralama Kümelerinin anonim olarak gönderilmesi gerekir).

Ağda başarılı bağlantılar kurmak için yukarıdaki kavramları birleştirebiliriz.

Alice, kendi gelen ve giden tünellerini oluşturmak için Yöneltici Bilgilerini toplamak amacıyla Ağ Veritabanı üzerinde bir arama yapar. Böylece, tünellerinde sıçrama olarak kullanabileceği eşlerin listelerini toplar. Daha sonra ilk sıçramaya bir oluşturma iletisi gönderebilir, bir tünel oluşturulmasını isteyebilir ve yönelticiden tünel oluşturulana kadar oluşturma iletisini göndermesini isteyebilir.

Diğer yönelticiler hakkında bilgi istenir                     Yöneltici bilgileri kullanılarak tünel oluşturulur

Şekil 2: Tünelleri oluşturmak için kullanılan yöneltici bilgileri.

Alice, Bob'a bir ileti göndermek istediğinde, önce Bob'un Kiralama Kümesini bulmak için Ağ Veritabanında bir arama yapar ve ona var olan gelen tünel ağ geçitlerini öğrenir. Ardından, giden tünellerinden birini seçer ve iletiyi Bob'un gelen tünel ağ geçitlerinden birine iletmek için giden tünelin uç noktası için yönergelerle birlikte aşağıya gönderir. Giden tünel uç noktası bu yönergeleri aldığında, iletiyi istendiği gibi iletir ve Bob'un gelen tünel ağ geçidi bunu aldığında, tünelden Bob'un yönelticisine iletilir. Alice, Bob'un iletiyi yanıtlayabilmesini istiyorsa, kendi hedefini iletinin bir parçası olarak açıkça iletmelidir. Bu, streaming kitaplığında yapılan daha yüksek düzeyle bir katman sunularak yapılabilir. Alice ayrıca, Bob'un yanıt vermek istemesi durumunda Ağ Veritabanı araması yapmasına gerek kalmaması için en son Kiralama Kümesini iletiye katarak yanıt süresini kısaltabilir. Ancak bu seçenek isteğe bağlıdır.

Kiralama Kümeleri kullanarak tüneller ile bağlantı kurmak

Şekil 3: Kiralama Kümelerini kullanarak gidiş ve geliş tünellerini bağlamak.

Tünellerin kendileri, ağ içindeki eşlere karşı izinsiz açığa çıkmalarını önlemek için katmanlı şifreleme kullansa da (ağ dışındaki eşlere izin açığa çıkmayı önlemek için taşıma katmanının yaptığı gibi), giden tünel uç noktasından ve gelen tünel ağ geçidinden gelen iletiyi gizlemek için ek bir uçtan uca şifreleme katmanı eklemek gerekir. Bu "garlicf şifrelemesi", Alice'in yönelticisinin birden çok iletiyi tek bir "garlic iletisine" sarmalaması ve belirli bir ortak anahtarla şifrelemesini sağlar. Böylece aracı eşler garlic içinde kaç ileti olduğunu, bu iletilerin ne söylediğini veya bu iletilerin nerede olduğunu ya da bu dişin hangi hedefe gönderildiğini belirleyemez. Alice ve Bob arasında tipik uçtan uca iletişim için, garlic Bob'un Kiralama Kümesinde yayınlanan ortak anahtarla şifrelenir. Böylece herkese açık anahtar Bob'un kendi yönelticisine verilmeden iletinin şifrelenmesi sağlanır.

Akılda tutulması gereken bir diğer önemli durum, I2P uygulamasının tamamen ileti temelli olduğu ve yol boyunca bazı iletilerin kaybolabileceğidir. I2P kullanan uygulamalar, ileti odaklı arayüzleri kullanabilir ve kendi tıkanıklık denetimi ile güvenilirlik gereksinimlerini karşılayabilir. Ancak çoğunun en iyi şekilde hizmet sağlaması için, I2P uygulamasını akış temelli bir ağ olarak görüntülemek için sağlanan akış kitaplığını yeniden kullanması gerekir.

Tüneller

Hem gelen hem de giden tüneller benzer ilkelerle çalışır. Tünel ağ geçidi, bir dizi tünel iletisi biriktirir ve sonunda bunları tünel aktarımı için bir şeye önceden işler. Ardından, ağ geçidi önceden işlenmiş verileri şifreler ve ilk sıçramaya iletir. Bu eş ve sonraki tünel katılımcıları, bir sonraki eşe iletmeden önce kopya olmadığını doğruladıktan sonra bir şifreleme katmanı ekler. Sonunda ileti, iletilerin yeniden bölündüğü ve istendiği gibi iletildiği uç noktaya ulaşır. Fark, tüneli oluşturanın yaptığı işte ortaya çıkar. Gelen tünellerde, oluşturucu uç noktadır ve eklenen tüm katmanların şifresini çözer. Giden tünellerde oluşturucu ağ geçididir ve tüm katmanların şifresini önceden çözer. Her sıçrama için şifrelemenin tüm katmanları eklendikten sonra, ileti tünel uç noktasına net bir şekilde ulaşır.

İletileri iletmek için belirli eşlerin seçilmesi ve bunların özel sıralaması, hem I2P anonimliğini hem de başarım özelliklerini anlamak için önemlidir. Ağ veritabanının (aşağıda) hangi eşlerin sorgulanıp kayıtları depolayacağını seçmek için kendi ölçütleri olsa da, tünel oluşturucular ağdaki herhangi bir eşi herhangi bir sırayla (ve hatta herhangi bir sayıda) tek bir tünelde kullanabilir. Mükemmel gecikme ve kapasite verileri küresel olarak biliniyor olsaydı, seçim ve sıralama, istemci tehdit modelleri ve belirli gereksinimleri tarafından yönlendirilirdi. Ne yazık ki, gecikme ve kapasite verilerinin anonim olarak toplanması önemsiz değildir ve bu bilgileri sağlamak için güvenilmeyen eşlere bağlı olmanın anonimlik üzerinde ciddi etkileri vardır.

Anonimlik açısından en basit yöntem, tüm ağdan rastgele eşler seçmek, bunları rastgele sıralamak ve bu eşleri sonsuza kadar bu sırayla kullanmak olur. Başarım açısından bakıldığında, en basit yöntem, gerekli yedek kapasiteye sahip en hızlı eşleri seçmek, yükü şeffaf olarak devretmek için yükü farklı eşler arasında dağıtmak ve kapasite bilgileri değiştiğinde tüneli yeniden oluşturmak olur. İlki hem kırılgan hem de verimsiz iken, ikincisi için erişilemez bilgiler gerekir ve yetersiz anonimlik sunar. Bunun yerine I2P, eşleri profillerine göre düzenlemek için anonimlik farkında ölçüm koduyla birleştirilmiş bir dizi eş seçim stratejisi sunmaya çalışır.

Temel olarak, I2P etkileşimde bulunduğu eşlerin dolaylı davranışlarını sürekli olarak ölçerek profillerini oluşturur. Örneğin, bir eş 1,3 saniyede bir ağ veritabanı aramasına yanıt verdiğinde, bu gidiş dönüş gecikmesi tüm yönelticilerin profillerine kaydedilerek, İstek ve yanıtın geçtiği iki tünelde (gelen ve giden) ve sorgulanan eşin profilinde yer alır. Taşıma katmanı gecikmesi veya tıkanıklık gibi doğrudan ölçümler, manipüle edilebildiği ve ölçüm yönelticisi ile ilişkilendirilebileceğinden ve onları önemsiz saldırılara açık bırakabileceğinden profilin bir parçası olarak kullanılmaz. Bu profiller toplanırken, başarımını, gecikmesini, çok sayıda etkinliği işleme kapasitesini, şu anda aşırı yüklü olup olmadığını ve ağ ile ne kadar bütünleşmiş olduğunu özetlemek için her biri üzerinde bir dizi hesaplama yapılır. Daha sonra bu hesaplamalar, yönelticileri hızlı ve yüksek kapasiteli, yüksek kapasiteli, sorunsuz ve sorunlu olmak üzere dört düzeyde gruplamak için etkin eşleri karşılaştırmakta kullanılır. Bu düzeylerin eşikleri devingen olarak belirlenir ve şu anda oldukça basit algoritmalar kullanır. Ancak alternatifleri de vardır.

Bu profil verileri kullanılarak, en basit uygun eş seçimi stratejisi, eşleri üst düzeyden (hızlı ve yüksek kapasiteli) rastgele seçmektir. Şu anda istemci tünelleri bu şekilde dağıtılmaktadır. Keşif tünelleri (ağ veritabanı ve tünel yönetimi için kullanılır) "sorunsuz" düzeyinden ('daha iyi" katmanlardaki yönelticileri de içerir) rastgele eşler seçer. Eşler arası yönelticileri daha geniş bir şekilde örnekleme olanağı sağlar ve aslında rastgele tepe tırmanışı ile eş seçimini iyileştirir. Ancak bu stratejiler, öncül ve ağ veritabanı hasat saldırıları ile yönelticinin en üst düzeyindeki eşler hakkında bilgi sızdırır. Buna karşılık, yükü eşit olarak dengelememekle birlikte, belirli düşman sınıfları tarafından düzenlenen saldırılara karşı koyacak çeşitli alternatifler vardır.

Rastgele bir anahtar seçerek ve eşleri ondan XOR uzaklıklarına göre sıralayarak, eşlerin başarısızlık oranına ve düzeyin karıştırılmasına göre öncül ve hasat saldırılarında sızdırılan bilgiler azaltılır. Ağ veritabanı hasat saldırılarıyla başa çıkmak için başka bir basit strateji, gelen tünel ağ geçitlerini düzeltmek ve aynı zamanda tünellerdeki eşleri daha da rastgele hale getirmektir. İstemcinin bağlantı kurduğu düşmanlara yönelik önceki saldırılarla başa çıkmak için giden tünel uç noktaları da sabit kalır. En çok maruz kalan noktada hangi eşin düzeltileceğinin seçiminin elbette bir süre sınırı olmalıdır. Çünkü sonunda tüm eşler başarısız olur. Böylece diğer yönelticilerin sorunları arasında ölçülen ortalama süreyi taklit etmek için tepkisel olarak ayarlanabilir ya da etkisel olarak önlenebilir. Bu iki strateji, sırayla, sabit bir açık eş ve tüneller arasında bir XOR tabanlı sıralama kullanılarak birleştirilebilir. Daha katı bir strateji, tam eşleri ve olası bir tünelin sıralamasını düzeltir. Yalnızca her biri aynı şekilde katılmayı kabul ederse tek tek eşler kullanılır. Bu yöntem, XOR tabanlı sıralamadan farklıdır, çünkü her bir eşin öncülü ve ardılı her zaman aynıdır. XOR ise yalnızca sıralarının değişmediğinden emin olur.

Daha önce belirtildiği gibi, I2P şu anda (sürüm 0.8), XOR tabanlı sıralama ile yukarıdaki düzeyli rastgele stratejiyi kullanıyor. Tünel işletimi, yönetimi ve eş seçimi ile ilgili mekanizmalar hakkında ayrıntılı bir tartışma tunnel teknik özelliklerinde bulunabilir.

Ağ Veritabanı

Daha önce belirtildiği gibi, I2P ağ veritabanı ağın üst verilerini paylaşmak için çalışır. Bu konu, ağ veritabanı sayfasında ayrıntılı olarak açıklanmıştır. Bununla birlikte basit bir açıklamayı aşağıda bulabilirsiniz.

I2P kullanıcılarının belirli bir yüzdesi 'otomatik doldurma eşleri' olarak atanır. Şu anda, çok fazla bant genişliği olan ve yeterince hızlı I2P kurulumları, var olan otomatik doldurma yönelticilerinin sayısı çok azaldığında kendilerini otomatik doldurma yönelticisi olarak atar.

Diğer I2P yönelticileri, otomatik doldurma yönelticilerine basit 'depolama' ve 'arama' sorguları göndererek verilerini ve arama bilgilerini depolar. Bir otomatik doldurma yönelticisi bir 'depolama' sorgusu alırsa, bilgileri Kademlia algoritmasını kullanarak diğer otomatik doldurma yönelticilerine yayar. 'Arama' sorguları, şu anda önemli bir güvenlik sorununu önlemek için farklı şekilde çalışıyor. Bir arama yapıldığında, otomatik doldurma yönelticisi aramayı diğer eşlere iletmez. Ancak her zaman kendi kendine yanıt verir (istenilen verilere sahipse).

Ağ veritabanında iki türde bilgi depolanır.

  • Yöneltici bilgileri belirli bir I2P yönelticisi ve nasıl bağlantı kurulacağı hakkında bilgileri tutar.
  • Kiralama kümesi belirli bir hedefin bilgilerini tutar (I2P web sitesi, e-posta sunucusu gibi)

Tüm bu bilgiler, yayınlayan tarafça imzalanır ve bilgileri kullanan veya depolayan herhangi bir I2P yönelticisi tarafından doğrulanır. Ek olarak, eski kayıtların tutulmasını ve olası saldırıları önlemek için verilerde süre bilgisi bulunur. Bu aynı zamanda I2P tarafından doğru zamanı korumak, ara sıra bazı SNTP sunucularını sorgulamak (varsayılan olarak pool.ntp.org round robin) ve aktarım katmanındaki yönelticiler arasındaki sapmayı algılamak için gerekli kodu bir araya getirmekte kullanılır.

Bazı ek açıklamalar da önemlidir.

  • Yayınlanmamış ve şifrelenmiş Kiralama Kümeleri:

    Bir kişi yalnızca belirli kişilerin bir hedefe ulaşabilmesini isteyebilir. Bu, hedef Ağ Veritabanında yayınlanabilir. Ancak hedefi başka yollarla iletmeniz gerekir. Bir alternatif, 'Şifreli Kiralama Kümeleri'dir. Bu Kiralama Kümeleri yalnızca şifre çözme anahtarına erişimi olan kişiler tarafından çözülebilir.

  • Ön yükleme:

    Ağ Veritabanının ön yüklenemsi oldukça basittir. Bir yöneltici, erişilebilir bir eşten tek bir Yöneltici Bilgisi almayı başardığında, ağdaki diğer yöneltici referansları için bu yönelticiyi sorgulayabilir. Şu anda, birkaç kullanıcı, bu bilgileri kullanılabilir hale getirmek için Yöneltici Bilgileri dosyalarını bir web sitesine gönderiyor. I2P, Yöneltici Bilgileri dosyalarını ve ön yüklemeyi almak için otomatik olarak bu web sitelerinden birine bağlanır.

  • Arama ölçeklenebilirliği:

    I2P ağındaki aramalar diğer ağ veritabanı yönelticilerine iletilmez. Şu anda, ağ çok büyük olmadığı için bu büyük bir sorun oluşturmaz. Ancak ağ büyüdükçe, her ağ veritabanı yönelticisinde yöneltici bilgileri ve kiralama kümesi dosyalarının tümü bulunmaz ve başarılı arama oranı düşer. Bu nedenle, sonraki sürümlerde ağ veritabanında iyileştirmeler yapılacaktır.

Taşıyıcı iletişim kuralları

Yönelticiler arasındaki iletişimde, iletişim kurulan yönelticinin belirli bir iletiyi alması gereken yöneltici olduğunu doğrulanırken, dış düşmanlara karşı gizlilik ve bütünlük sağlanması gerekir. Yönelticilerin diğer yönelticilerle nasıl iletişim kurduğunun ayrıntıları kritik değildir. Temel gereksinimleri karşılamak için farklı noktalarda üç ayrı iletişim kuralı kullanılmıştır.

I2P, o zamandan beri devre dışı bırakılan TCP tabanlı bir iletişim kuralı ile başladı. Daha sonra, yüksek düzeyli iletişim gereksinimini karşılamak için (birkaç yöneltici diğerleriyle konuşacağından), I2P, TCP tabanlı bir taşıyıcıdan UDP tabanlı bir taşıyıcıya - "Güvenli yarı güvenilir UDP" ya da "SSU" kullanmaya geçti.

SSU teknik özelliklerinde belirtildiği şekilde:

Bu iletişim kuralının amacı, güvenli, kimliği doğrulanmış, yarı güvenilir ve sıralanmamış ileti aktarımını sağlamak ve üçüncü tarafların kolayca fark edemeyeceği kadar az miktarda veri ortaya çıkarmaktır. TCP dostu tıkanıklık denetiminin yanında yüksek düzeyli iletişimi desteklerken PMTU algılamasını da içerebilir. Ev kullanıcıları için toplu verileri yeterli hızlarda verimli bir şekilde aktarabilmelidir. Ayrıca, NAT veya güvenlik duvarı gibi yaygın kullanılan ağ engellerini ele alan teknikleri desteklemelidir.

SSU duyurulduktan sonra ve tıkanıklık çökmesi sorunlarının ortaya çıkmasıyla, NTCP adlı yeni bir NIO tabanlı TCP aktarımı uygulandı. Yalnızca giden bağlantılar için varsayılan olarak etkindir. NAT/güvenlik duvarlarını gelen bağlantılara izin verecek şekilde yapılandıranlar ve /config.jsp üzerinde dış sunucu ve kapı numarası (dyndns/etc tamam olan) belirtenler gelen bağlantıları alabilir. NTCP NIO tabanlı olduğundan, eski TCP aktarımındaki her bağlantı için 1 işlem sorunu yaşanmaz.

I2P, aynı anda birden fazla taşıyıcı kullanılmasını destekler. Giden bağlantı için belirli bir taşıyıcı "teklifler" yoluyla seçilir. Bağlantı için her taşıyıcı teklifi ve bu tekliflerin göreli değeri önceliği belirler. Taşıyıcılar, eş ile daha önce kurulmuş bir bağlantı olup olmadığına bağlı olarak farklı tekliflerle yanıt verebilir.

Geçerli uygulama, çoğu durumda giden bağlantılar için en yüksek öncelikli taşıyıcı olarak NTCP değerlendirmesi yapar. SSU, hem giden hem de gelen bağlantılar için etkinleştirilir. Güvenlik duvarınız ve I2P yönelticiniz, gelen NTCP bağlantılarına izin verecek şekilde yapılandırılmalıdır. Ayrıntılı bilgi almak için NTCP sayfasına bakabilirsiniz.

Şifreleme

I2P üzerinde çeşitli düşmanlara karşı katmanlı savunma sağlamak için en düşük düzeyde şifreleme öncülleri bir araya getirilir. En düşük düzeyde, yönelticiler arası iletişim, aktarım katmanı güvenliği tarafından korunur - SSU, 2048 bitlik bir Diffie aracılığıyla kısa ömürlü bir oturum anahtarı üzerinde anlaştıktan sonra her paketi hem açık IV hem de MAC (HMAC-MD5-128) ile AES256/CBC ile şifreler. Hellman değişimi, diğer yönelticinin DSA anahtarıyla istasyondan istasyona kimliği doğrular ve ayrıca her ağ iletisinin yerel bütünlük denetimi için kendi karması vardır. Aktarımlar üzerinden geçirilen Tünel iletileri, açık bir IV ile kendi katmanlı AES256/CBC şifrelemesini kullanır ve tünel uç noktasında ek bir SHA256 karması ile doğrulanır. ElGamal/AES+SessionTags (aşağıda açıklanmıştır) ile şifrelenmiş "garlic iletileri" içinde çeşitli diğer iletiler aktarılır.

Garlic iletileri

Garlic iletileri, "onion" katmanlı şifrelemenin bir uzantısıdır ve tek bir iletinin içeriğinin birden fazla "diş" içermesini sağlar - kendi aktarım yönergelerinin yanında tam olarak biçimlendirilmiş iletiler. İleriler aksi durumda bilgiye erişimi olmaması gereken bir eşten açık metin olarak geçtiğinde, iletiler bir garlic iletisine samalanır. Örneğin, bir yöneltici başka bir yönelticiden bir tünele katılmasını istediğinde, istek bir garlic içine samalanır. Bu garlic alıcı yönelticinin 2048bit ElGamal ortak anahtarına şifrelenir ve bir tünelden iletilir. Başka bir örnek, bir istemci bir hedefe ileti göndermek istediğinde - göndericinin yönelticisi bu veri iletisini (diğer bazı iletilerin yanında bir garlic içine sarmalar. Bu garlic alıcının kiralama kümesinde yayınlanan 2048 bit ElGamal ortak anahtarı ile şifrelenir ve uygun tünellerden geçirilir.

Şifreleme katmanının içindeki her bir dişe eklenmiş "yönergeler", dişin yerel olarak, uzak bir yönelticiye ya da uzak bir yönelticideki uzak bir tünele aktarılmasını isteme yeteneğini bulundurur. Bu yönergelerde, bir eşin aktarımın belirli bir zaman veya koşul karşılanana kadar ertelenmesini istemesini sağlayan alanlar vardır. Ancak bunlar önemsiz gecikmeler dağıtılana kadar kabul edilmez. Garlic iletilerini tünel oluşturmadan herhangi bir sayıda sıçrama ile açıkta yöneltmek ya da tünel iletilerini garlic iletilerine sararak ve tüneldeki bir sonraki sekmeye iletmeden önce birkaç sıçramadan geçirerek yönlendirilebilir. Ancak bu teknikler şu andaki uygulama kullanılmıyor

Oturum etiketleri

Güvenilmez, sıralı olmayan ileti tabanlı bir sistem olan I2P, garlic iletilerinin veri gizliliği ve bütünlüğü sağlamak için asimetrik ve simetrik şifreleme algoritmalarının basit bir kombinasyonunu kullanır. Bir bütün olarak, kombinasyon ElGamal/AES+Oturum etiketi olarak anılır. Ancak bu, basit 2048 bit ElGamal, AES256, SHA256 ve 32 bayt nonce kullanımını açıklamak için aşırı derecede ayrıntılı bir yoldur.

Bir yöneltici ilk kez başka bir yönelticiye göndereceği bir garlic iletisini şifrelemek istediğinde, bir AES256 oturum anahtarı için anahtarlama materyalini ElGamal ile şifreler ve bu şifrelenmiş ElGamal bloğunun ardından AES256/CBC ile şifrelenmiş yükü ekler. Şifrelenmiş yüke ek olarak, AES ile şifrelenmiş bölümü yük uzunluğu, şifrelenmemiş yükün SHA256 karması ve ayrıca bir dizi "oturum etiketi" - rastgele 32 baytlık olmayanlar - bulunur. Gönderici bir dahaki sefere bir garlic iletisini başka bir yönlendiriciye şifrelemek istediğinde, ElGamal yeni bir oturum anahtarını şifrelemek yerine, daha önce teslim edilmiş oturum etiketlerinden birini seçer ve AES, daha önce olduğu gibi, o oturum etiketiyle kullanılan oturum anahtarını kullanarak yükü şifreler. Bu bilgi oturum etiketinin başına eklenir. Bir yöneltici bir garlic şifrelenmiş iletisi aldığında, uygun bir oturum etiketiyle eşleşip eşleşmediğini görmek için ilk 32 baytı kontrol eder. Eşleşme bulunursa yalnızca AES iletisinin şifresini çözer. Bulunmazsa ElGamal ilk bloğun şifresini çözer.

Her oturum etiketi, iç izleyicilerin aynı yönelticiler arasında olduğu gibi farklı iletileri gereksiz yere ilişkilendirmesini önlemek için yalnızca bir kez kullanılabilir. ElGamal/AES+Oturum etiketi şifrelemiş iletisinin göndericisi, ne zaman ve kaç etiketin teslim edileceğini seçer ve alıcıya bir sürü iletiyi kapsayacak kadar yeterli etiket hazırlar. Garlic iletileri küçük bir ek iletiyi bir diş ("teslim durumu iletisi") olarak paketleyerek etiket tesliminin başarılı olduğunu algılayabilir - garlic iletisi hedeflenen alıcıya ulaştığında ve şifresi başarıyla çözüldüğünde, bu küçük teslim durumu dişlerden biridir. Açığa çıkar ve alıcının dişi özgün göndericiye geri göndermesi için yönergeler içerir (elbette bir geliş tüneli üzeirnden). Özgün gönderici bu teslim durumu iletisini aldığında, garlic iletisinde gruplanan oturum etiketlerinin başarıyla iletildiğini bilir.

Oturum etiketlerinin ömürleri kısadır. bu sürenin sonunda kullanılmazlarsa atılır. Ek olarak, her bir anahtar için depolanan miktar ve anahtarların sayısı sınırlıdır. Çok fazla gelirse, yeni veya eski iletiler kaybolabilir Gönderici, oturum etiketlerini kullanan iletilerin geçip geçmediğini izler ve yeterli iletişim yoksa, daha önce düzgün bir şekilde iletildiği varsayılanları bırakarak en pahalı ElGamal şifrelemesine geri dönebilir.

Bir alternatif, yalnızca tek bir oturum etiketi iletmek ve bundan, hangi etiketlerin kullanılacağını veya bekleneceğini belirlemek için belirleyici bir PRNG tohumlanmasıdır. Bu PRNG verisini gönderici ve alıcı arasında kabaca eşitlenmiş olarak tutularak (alıcı örneğin sonraki 50 etiketin bir penceresini önceden hesaplar), çok sayıda etiketi düzenli olarak gruplamanın yükü ortadan kaldırır ve ek seçenekler ile alan/zaman değiş tokuşu ve belki de gerekli ElGamal şifrelemelerinin sayısını daha fazla azaltılması sağlanır. Bununla birlikte, iç düşmanlara karşı gerekli korumayı sağlamak PRNG gücüne bağlı olacaktır. Ancak belki de her bir PRNG kullanım sürelerini sınırlayarak, herhangi bir zayıflık en aza indirilebilir. Şu anda, eşitlenen PRNG yöntemine doğru ilerlemek için acil bir plan yok.

Gelecek

I2P şu anda birçok senaryo için işlevsel ve yeterli olsa da, daha güçlü rakiplerle karşılaşanların gereksinimleri için daha fazla iyileştirme ve önemli kullanıcı deneyimi iyileştirmesi gereken birkaç alan var.

Kısıtlanmış yöneltme işlemi

I2P is an overlay network designed to be run on top of a functional packet switched network, exploiting the end to end principle to offer anonymity and security. While the Internet no longer fully embraces the end to end principle (due to the usage of NAT), I2P does require a substantial portion of the network to be reachable - there may be a number of peers along the edges running using restricted routes, but I2P does not include an appropriate routing algorithm for the degenerate case where most peers are unreachable. It would, however work on top of a network employing such an algorithm.

Restricted route operation, where there are limits to what peers are reachable directly, has several different functional and anonymity implications, dependent upon how the restricted routes are handled. At the most basic level, restricted routes exist when a peer is behind a NAT or firewall which does not allow inbound connections. This was largely addressed in I2P 0.6.0.6 by integrating distributed hole punching into the transport layer, allowing people behind most NATs and firewalls to receive unsolicited connections without any configuration. However, this does not limit the exposure of the peer's IP address to routers inside the network, as they can simply get introduced to the peer through the published introducer.

Beyond the functional handling of restricted routes, there are two levels of restricted operation that can be used to limit the exposure of one's IP address - using router-specific tunnels for communication, and offering 'client routers'. For the former, routers can either build a new pool of tunnels or reuse their exploratory pool, publishing the inbound gateways to some of them as part of their routerInfo in place of their transport addresses. When a peer wants to get in touch with them, they see those tunnel gateways in the netDb and simply send the relevant message to them through one of the published tunnels. If the peer behind the restricted route wants to reply, it may do so either directly (if they are willing to expose their IP to the peer) or indirectly through their outbound tunnels. When the routers that the peer has direct connections to want to reach it (to forward tunnel messages, for instance), they simply prioritize their direct connection over the published tunnel gateway. The concept of 'client routers' simply extends the restricted route by not publishing any router addresses. Such a router would not even need to publish their routerInfo in the netDb, merely providing their self signed routerInfo to the peers that it contacts (necessary to pass the router's public keys). Both levels of restricted route operation are planned for I2P 2.0.

There are tradeoffs for those behind restricted routes, as they would likely participate in other people's tunnels less frequently, and the routers which they are connected to would be able to infer traffic patterns that would not otherwise be exposed. On the other hand, if the cost of that exposure is less than the cost of an IP being made available, it may be worthwhile. This, of course, assumes that the peers that the router behind a restricted route contacts are not hostile - either the network is large enough that the probability of using a hostile peer to get connected is small enough, or trusted (and perhaps temporary) peers are used instead.

Değişken gecikme

Even though the bulk of I2P's initial efforts have been on low latency communication, it was designed with variable latency services in mind from the beginning. At the most basic level, applications running on top of I2P can offer the anonymity of medium and high latency communication while still blending their traffic patterns in with low latency traffic. Internally though, I2P can offer its own medium and high latency communication through the garlic encryption - specifying that the message should be sent after a certain delay, at a certain time, after a certain number of messages have passed, or another mix strategy. With the layered encryption, only the router that the clove exposed the delay request would know that the message requires high latency, allowing the traffic to blend in further with the low latency traffic. Once the transmission precondition is met, the router holding on to the clove (which itself would likely be a garlic message) simply forwards it as requested - to a router, to a tunnel, or, most likely, to a remote client destination.

There are a substantial number of ways to exploit this capacity for high latency comm in I2P, but for the moment, doing so has been scheduled for the I2P 3.0 release. In the meantime, those requiring the anonymity that high latency comm can offer should look towards the application layer to provide it.

Açık sorular

  • Zamanlama kısıtlamasından nasıl kurtulunur?
  • Daha etkin bir sessionTags işlemesi sağlayabilir miyiz?
  • Tüneller için herhangi bir toplu işlem ya da karma stratejisi oluşturmalı mıyız?
  • Başka tünel eş seçimi ve sıralama stratejileri neler olabilir?

Benzer sistemler

I2P's architecture builds on the concepts of message oriented middleware, the topology of DHTs, the anonymity and cryptography of free route mixnets, and the adaptability of packet switched networking. The value comes not from novel concepts of algorithms though, but from careful engineering combining the research results of existing systems and papers. While there are a few similar efforts worth reviewing, both for technical and functional comparisons, two in particular are pulled out here - Tor and Freenet.

See also the Network Comparisons Page.

Tor

web sitesi

At first glance, Tor and I2P have many functional and anonymity related similarities. While I2P's development began before we were aware of the early stage efforts on Tor, many of the lessons of the original onion routing and ZKS efforts were integrated into I2P's design. Rather than building an essentially trusted, centralized system with directory servers, I2P has a self organizing network database with each peer taking on the responsibility of profiling other routers to determine how best to exploit available resources. Another key difference is that while both I2P and Tor use layered and ordered paths (tunnels and circuits/streams), I2P is fundamentally a packet switched network, while Tor is fundamentally a circuit switched one, allowing I2P to transparently route around congestion or other network failures, operate redundant pathways, and load balance the data across available resources. While Tor offers the useful outproxy functionality by offering integrated outproxy discovery and selection, I2P leaves such application layer decisions up to applications running on top of I2P - in fact, I2P has even externalized the TCP-like streaming library itself to the application layer, allowing developers to experiment with different strategies, exploiting their domain specific knowledge to offer better performance.

From an anonymity perspective, there is much similarity when the core networks are compared. However, there are a few key differences. When dealing with an internal adversary or most external adversaries, I2P's simplex tunnels expose half as much traffic data than would be exposed with Tor's duplex circuits by simply looking at the flows themselves - an HTTP request and response would follow the same path in Tor, while in I2P the packets making up the request would go out through one or more outbound tunnels and the packets making up the response would come back through one or more different inbound tunnels. While I2P's peer selection and ordering strategies should sufficiently address predecessor attacks, should a switch to bidirectional tunnels be necessary, we could simply build an inbound and outbound tunnel along the same routers.

Another anonymity issue comes up in Tor's use of telescopic tunnel creation, as simple packet counting and timing measurements as the cells in a circuit pass through an adversary's node exposes statistical information regarding where the adversary is within the circuit. I2P's unidirectional tunnel creation with a single message so that this data is not exposed. Protecting the position in a tunnel is important, as an adversary would otherwise be able to mount a series of powerful predecessor, intersection, and traffic confirmation attacks.

Tor's support for a second tier of "onion proxies" does offer a non-trivial degree of anonymity while requiring a low cost of entry, while I2P will not offer this topology until 2.0.

On the whole, Tor and I2P complement each other in their focus - Tor works towards offering high speed anonymous Internet outproxying, while I2P works towards offering a decentralized resilient network in itself. In theory, both can be used to achieve both purposes, but given limited development resources, they both have their strengths and weaknesses. The I2P developers have considered the steps necessary to modify Tor to take advantage of I2P's design, but concerns of Tor's viability under resource scarcity suggest that I2P's packet switching architecture will be able to exploit scarce resources more effectively.

Freenet

web sitesi

Freenet played a large part in the initial stages of I2P's design - giving proof to the viability of a vibrant pseudonymous community completely contained within the network, demonstrating that the dangers inherent in outproxies could be avoided. The first seed of I2P began as a replacement communication layer for Freenet, attempting to factor out the complexities of a scalable, anonymous and secure point to point communication from the complexities of a censorship resistant distributed data store. Over time however, some of the anonymity and scalability issues inherent in Freenet's algorithms made it clear that I2P's focus should stay strictly on providing a generic anonymous communication layer, rather than as a component of Freenet. Over the years, the Freenet developers have come to see the weaknesses in the older design, prompting them to suggest that they will require a "premix" layer to offer substantial anonymity. In other words, Freenet needs to run on top of a mixnet such as I2P or Tor, with "client nodes" requesting and publishing data through the mixnet to the "server nodes" which then fetch and store the data according to Freenet's heuristic distributed data storage algorithms.

Freenet's functionality is very complementary to I2P's, as Freenet natively provides many of the tools for operating medium and high latency systems, while I2P natively provides the low latency mix network suitable for offering adequate anonymity. The logic of separating the mixnet from the censorship- resistant distributed data store still seems self-evident from an engineering, anonymity, security, and resource allocation perspective, so hopefully the Freenet team will pursue efforts in that direction, if not simply reusing (or helping to improve, as necessary) existing mixnets like I2P or Tor.

It is worth mentioning that there has recently been discussion and work by the Freenet developers on a "globally scalable darknet" using restricted routes between peers of various trust. While insufficient information has been made publicly available regarding how such a system would operate for a full review, from what has been said the anonymity and scalability claims seem highly dubious. In particular, the appropriateness for use in hostile regimes against state level adversaries has been tremendously overstated, and any analysis on the implications of resource scarcity upon the scalability of the network has seemingly been avoided. Further questions regarding susceptibility to traffic analysis, trust and other topics do exist, but a more in-depth review of this "globally scalable darknet" will have to wait until the Freenet team makes more information available.

Appendix A: Application layer

I2P itself doesn't really do much - it simply sends messages to remote destinations and receives messages targeting local destinations - most of the interesting work goes on at the layers above it. By itself, I2P could be seen as an anonymous and secure IP layer, and the bundled streaming library as an implementation of an anonymous and secure TCP layer on top of it. Beyond that, I2PTunnel exposes a generic TCP proxying system for either getting into or out of the I2P network, plus a variety of network applications provide further functionality for end users.

Akış kitaplığı

The I2P streaming library can be viewed as a generic streaming interface (mirroring TCP sockets), and the implementation supports a sliding window protocol with several optimizations, to take into account the high delay over I2P. Individual streams may adjust the maximum packet size and other options, though the default of 4KB compressed seems a reasonable tradeoff between the bandwidth costs of retransmitting lost messages and the latency of multiple messages.

In addition, in consideration of the relatively high cost of subsequent messages, the streaming library's protocol for scheduling and delivering messages has been optimized to allow individual messages passed to contain as much information as is available. For instance, a small HTTP transaction proxied through the streaming library can be completed in a single round trip - the first message bundles a SYN, FIN and the small payload (an HTTP request typically fits) and the reply bundles the SYN, FIN, ACK and the small payload (many HTTP responses fit). While an additional ACK must be transmitted to tell the HTTP server that the SYN/FIN/ACK has been received, the local HTTP proxy can deliver the full response to the browser immediately.

On the whole, however, the streaming library bears much resemblance to an abstraction of TCP, with its sliding windows, congestion control algorithms (both slow start and congestion avoidance), and general packet behavior (ACK, SYN, FIN, RST, etc).

Adlandırma kitaplığı ve adres defteri

For more information see the Naming and Address Book page.

Geliştiren: mihi, Ragnarok

Naming within I2P has been an oft-debated topic since the very beginning with advocates across the spectrum of possibilities. However, given I2P's inherent demand for secure communication and decentralized operation, the traditional DNS-style naming system is clearly out, as are "majority rules" voting systems. Instead, I2P ships with a generic naming library and a base implementation designed to work off a local name to destination mapping, as well as an optional add-on application called the "Address Book". The address book is a web-of-trust-driven secure, distributed, and human readable naming system, sacrificing only the call for all human readable names to be globally unique by mandating only local uniqueness. While all messages in I2P are cryptographically addressed by their destination, different people can have local address book entries for "Alice" which refer to different destinations. People can still discover new names by importing published address books of peers specified in their web of trust, by adding in the entries provided through a third party, or (if some people organize a series of published address books using a first come first serve registration system) people can choose to treat these address books as name servers, emulating traditional DNS.

I2P does not promote the use of DNS-like services though, as the damage done by hijacking a site can be tremendous - and insecure destinations have no value. DNSsec itself still falls back on registrars and certificate authorities, while with I2P, requests sent to a destination cannot be intercepted or the reply spoofed, as they are encrypted to the destination's public keys, and a destination itself is just a pair of public keys and a certificate. DNS-style systems on the other hand allow any of the name servers on the lookup path to mount simple denial of service and spoofing attacks. Adding on a certificate authenticating the responses as signed by some centralized certificate authority would address many of the hostile nameserver issues but would leave open replay attacks as well as hostile certificate authority attacks.

Voting style naming is dangerous as well, especially given the effectiveness of Sybil attacks in anonymous systems - the attacker can simply create an arbitrarily high number of peers and "vote" with each to take over a given name. Proof-of-work methods can be used to make identity non-free, but as the network grows the load required to contact everyone to conduct online voting is implausible, or if the full network is not queried, different sets of answers may be reachable.

As with the Internet however, I2P is keeping the design and operation of a naming system out of the (IP-like) communication layer. The bundled naming library includes a simple service provider interface which alternate naming systems can plug into, allowing end users to drive what sort of naming tradeoffs they prefer.

Syndie

The old Syndie bundled with I2P has been replaced by the new Syndie which is distributed separately. For more information see the Syndie pages.

Syndie is a safe, anonymous blogging / content publication / content aggregation system. It lets you create information, share it with others, and read posts from those you're interested in, all while taking into consideration your needs for security and anonymity. Rather than building its own content distribution network, Syndie is designed to run on top of existing networks, syndicating content through I2P Sites, Tor hidden services, Freenet freesites, normal websites, usenet newsgroups, email lists, RSS feeds, etc. Data published with Syndie is done so as to offer pseudonymous authentication to anyone reading or archiving it.

I2PTunnel

Geliştiren: mihi

I2PTunnel is probably I2P's most popular and versatile client application, allowing generic proxying both into and out of the I2P network. I2PTunnel can be viewed as four separate proxying applications - a "client" which receives inbound TCP connections and forwards them to a given I2P destination, an "httpclient" (aka "eepproxy") which acts like an HTTP proxy and forwards the requests to the appropriate I2P destination (after querying the naming service if necessary), a "server" which receives inbound I2P streaming connections on a destination and forwards them to a given TCP host+port, and an "httpserver" which extends the "server" by parsing the HTTP request and responses to allow safer operation. There is an additional "socksclient" application, but its use is not encouraged for reasons previously mentioned.

I2P itself is not an outproxy network - the anonymity and security concerns inherent in a mix net which forwards data into and out of the mix have kept I2P's design focused on providing an anonymous network which capable of meeting the user's needs without requiring external resources. However, the I2PTunnel "httpclient" application offers a hook for outproxying - if the hostname requested doesn't end in ".i2p", it picks a random destination from a user-provided set of outproxies and forwards the request to them. These destinations are simply I2PTunnel "server" instances run by volunteers who have explicitly chosen to run outproxies - no one is an outproxy by default, and running an outproxy doesn't automatically tell other people to proxy through you. While outproxies do have inherent weaknesses, they offer a simple proof of concept for using I2P and provide some functionality under a threat model which may be sufficient for some users.

I2PTunnel enables most of the applications in use. An "httpserver" pointing at a webserver lets anyone run their own anonymous website (or "I2P Site") - a webserver is bundled with I2P for this purpose, but any webserver can be used. Anyone may run a "client" pointing at one of the anonymously hosted IRC servers, each of which are running a "server" pointing at their local IRCd and communicating between IRCds over their own "client" tunnels. End users also have "client" tunnels pointing at I2Pmail's POP3 and SMTP destinations (which in turn are simply "server" instances pointing at POP3 and SMTP servers), as well as "client" tunnels pointing at I2P's CVS server, allowing anonymous development. At times people have even run "client" proxies to access the "server" instances pointing at an NNTP server.

i2p-bt

Geliştiren: duck, et al

i2p-bt is a port of the mainline python BitTorrent client to run both the tracker and peer communication over I2P. Tracker requests are forwarded through the eepproxy to I2P Sites specified in the torrent file while tracker responses refer to peers by their destination explicitly, allowing i2p-bt to open up a streaming lib connection to query them for blocks.

In addition to i2p-bt, a port of bytemonsoon has been made to I2P, making a few modifications as necessary to strip any anonymity-compromising information from the application and to take into consideration the fact that IPs cannot be used for identifying peers.

I2PSnark

I2PSnark developed: jrandom, et al, ported from mjw's Snark client

Bundled with the I2P install, I2PSnark offers a simple anonymous BitTorrent client with multitorrent capabilities, exposing all of the functionality through a plain HTML web interface.

Robert

Geliştiren: sponge

Robert is a Bittorrent client written in Python. It is hosted on http://bob.i2p.xyz/Robert.html

PyBit

Geliştiren: Blub

PyBit is a Bittorrent client written in Python. It is hosted on http://echelon.i2p.xyz/pybit/

I2Phex

Geliştiren: sirup

I2Phex is a fairly direct port of the Phex Gnutella filesharing client to run entirely on top of I2P. While it has disabled some of Phex's functionality, such as integration with Gnutella webcaches, the basic file sharing and chatting system is fully functional.

iMule

Geliştiren: mkvore

iMule is a fairly direct port of the aMule filesharing client running entirely inside I2P.

I2Pmail/susimail

Geliştiren: postman, susi23, mastiejaner

I2Pmail is more a service than an application - postman offers both internal and external email with POP3 and SMTP service through I2PTunnel instances accessing a series of components developed with mastiejaner, allowing people to use their preferred mail clients to send and receive mail pseudonymously. However, as most mail clients expose substantial identifying information, I2P bundles susi23's web based susimail client which has been built specifically with I2P's anonymity needs in mind. The I2Pmail/mail.i2p service offers transparent virus filtering as well as denial of service prevention with hashcash augmented quotas. In addition, each user has control of their batching strategy prior to delivery through the mail.i2p outproxies, which are separate from the mail.i2p SMTP and POP3 servers - both the outproxies and inproxies communicate with the mail.i2p SMTP and POP3 servers through I2P itself, so compromising those non-anonymous locations does not give access to the mail accounts or activity patterns of the user. At the moment the developers work on a decentralized mailsystem, called "v2mail". More information can be found on the I2P Site hq.postman.i2p.xyz.

I2P-Bote

Geliştiren: HungryHobo

I2P-Bote is a distributed e-mail application. It does not use the traditional e-mail concept of sending an e-mail to a server and retrieving it from a server. Instead, it uses a Kademlia Distributed Hash Table to store mails. One user can push a mail into the DHT, while another can request the e-mail from the DHT. And all the mails sent within the I2P-Bote network are automatically encrypted end-to-end.
Furthermore, I2P-Bote offers a remailer function on top of I2P, for increased high-latency anonymity.

I2P-Messenger

I2P-Messenger is an end-to-end encrypted serverless communication application. For communication between two users, they need to give each other their destination keys, to allow the other to connect. It supports file transfer and has a search for other users, based on Seedless.