Návrhy I2P on I2P - Projekt neviditelného internetu

'Šifrovaná' Streamovací Vlajka

Mon, 01 Jan 0001 00:00:00 +0000

Přehled

Tento návrh je o přidání vlajky ke streamování, která specifikuje typ end-to-end šifrování, které je používané.

Motivace

Aplikace s vysokou zátěží mohou narazit na nedostatek tagů ElGamal/AES+SessionTags.

Návrh

Přidat novou vlajku někam do streamovacího protokolu. Pokud paket přijde s touto vlajkou, znamená to, že užitečné zatížení je zašifrováno pomocí AES klíče z privátního klíče a veřejného klíče vrstevníka. To by umožnilo eliminovat česnekové (ElGamal/AES) šifrování a problém s nedostatkem tagů.

Adresář služeb

Mon, 01 Jan 0001 00:00:00 +0000

Přehled

Tento návrh je pro protokol, který by aplikace mohly používat k registraci a vyhledávání služeb v adresáři.

Motivace

Nejjednodušší způsob, jak podporovat onioncat, je pomocí adresáře služeb.

Toto je podobné návrhu, který měl Sponge před časem na IRC. Nemyslím, že by ho napsal, ale jeho myšlenka byla umístit to do netDb. Nejsem zastánce toho, ale diskusi o nejlepším způsobu přístupu k adresáři (vyhledávání v netDb, DNS přes i2p, HTTP, hosts.txt atd.) nechám na jiný den.

Adresářové příkazy pro odběrový kanál

Mon, 01 Jan 0001 00:00:00 +0000

Poznámka

Nasazení v síti dokončeno. Viz SPEC pro oficiální specifikaci.

Přehled

Tento návrh se týká rozšíření odběrového kanálu adres o příkazy, aby bylo umožněno jmenným serverům vysílat aktualizace záznamů od držitelů hostname. Implementováno ve verzi 0.9.26.

Motivace

V současnosti servery pro odběr hosts.txt jednoduše posílají data ve formátu hosts.txt, který je následující:

example.i2p=b64destination

Existuje několik problémů s tímto:

Držitelé hostnamů nemohou aktualizovat Cílové místo (Destination) spojené s jejich hostnamy (aby například aktualizovali podpisový klíč na silnější typ).
Držitelé hostnamů nemohou libovolně vzdát svých hostnamů; musí předat odpovídající soukromé klíče Cílového místa přímo novému držiteli.
Neexistuje způsob, jak ověřit, že subdoména je řízena odpovídajícím základním jménem hostitele; to je aktuálně vymáháno individuálně některými jmennými servery.

Návrh

Tento návrh přidává několik příkazových řádků do formátu hosts.txt. Prostřednictvím těchto příkazů mohou jmenné servery rozšířit své služby na poskytování řady dalších funkcí. Klienti, kteří implementují tento návrh, budou schopni poslouchat tyto funkce prostřednictvím běžného odběrového procesu.

Aktualizace Streamování

Mon, 01 Jan 0001 00:00:00 +0000

Přehled

Java I2P a i2pd routery starší než API 0.9.58 (uvolněné v březnu 2023) jsou zranitelné útokem opakovaného přehrání SYN paketů. Toto je problém návrhu protokolu, nikoli chyba implementace.

SYN pakety jsou podepsány, ale podpis počátečního SYN paketu odeslaného od Alice k Bobovi není vázán na Bobovu identitu, takže Bob může tento paket uložit a přehrát, posílající jej oběti Charliemu. Charlie si bude myslet, že paket přišel od Alice a odpoví jí. Ve většině případů je to neškodné, ale SYN paket může obsahovat počáteční data (například GET nebo POST), která Charlie okamžitě zpracuje.

API 2 I2PControl

Mon, 01 Jan 0001 00:00:00 +0000

Přehled

Tento návrh popisuje API2 pro I2PControl.

Tento návrh byl zamítnut a nebude implementován, protože narušuje zpětnou kompatibilitu. Podrobnosti naleznete v odkazu na diskuzní vlákno.

Pozor vývojáři!

Všechny parametry RPC budou nyní psány malými písmeny. To přeruší zpětnou kompatibilitu s implementacemi API1. Důvodem je poskytování uživatelům >=API2 co nejjednodušší a nejkoherentnější možné API.

Specifikace API 2

{
 "id": "id",
 "method": "method_name",
 "params": {
 "token": "auth_token",
 "method_param": "method_parameter_value",
 },
 "jsonrpc": "2.0"
 }

 {
 "id": "id",
 "result": "result_value",
 "jsonrpc": "2.0"
 }

Parametry

"id"

B32 pro šifrované LS2

Mon, 01 Jan 0001 00:00:00 +0000

Poznámka

Probíhá nasazení a testování v síti. Předmět drobných revizí. Viz SPEC pro oficiální specifikaci.

Přehled

Standardní adresa Base 32 (“b32”) obsahuje hash cíle. To nebude fungovat pro šifrované ls2 (návrh 123).

Nemůžete použít tradiční adresu base 32 pro šifrované LS2 (návrh 123), protože obsahuje pouze hash cíle. Neposkytuje nezastřený veřejný klíč. Klienti musí znát veřejný klíč cíle, typ podpisu,
typ zakrytého podpisu a volitelný tajný nebo privátní klíč pro načtení a dešifrování leasesetu. Proto je samotná adresa base 32 nedostatečná. Klient potřebuje buď celý cíl (který obsahuje veřejný klíč), nebo veřejný klíč sám o sobě. Pokud má klient plný cíl v adresáři a adresář podporuje zpětné vyhledávání podle hashe, pak může být veřejný klíč získán.

BEP9 Obnova Informací

Mon, 01 Jan 0001 00:00:00 +0000

Přehled

Tento návrh je o přidání plné obnovy informací do implementace BEP9 v I2P.

Motivace

BEP9 neposílá celý torrent soubor, čímž ztrácí několik důležitých položek ve slovníku a mění celkový SHA1 torrent souboru. To je špatné pro odkazy na tok Torrent, a to proto, že se ztrácí důležité informace. Seznamy trackerů, komentáře a jakékoli dodatečné údaje jsou pryč. Je důležité mít způsob, jak tyto informace obnovit, a je potřeba přidat k torrent souboru co nejméně. Také to nesmí být kruhově závislé. Obnova informací by neměla žádným způsobem ovlivňovat současné klienty. Torrenty, které nemají tracker (URL trackeru je doslova ’trackerless’), neobsahují dodatečné pole, protože jsou specifické pro použití maggot protokolu pro objevování a stahování, což nevede ke ztrátě informací.

Dávkování Více Datových Stroužků v Česneku

Mon, 01 Jan 0001 00:00:00 +0000

Přehled

Tento návrh se týká odesílání více datových stroužků uvnitř koncového česnekového zprávy, místo pouze jednoho.

Motivace

Není jasné.

Potřebné Změny

Změny by byly v OCMOSJ a příslušných pomocných třídách, a v ClientMessagePool. Jelikož nyní neexistuje žádná fronta, byla by nutná nová fronta a nějaké zpoždění. Jakékoliv dávkování by muselo respektovat maximální velikost česneku, aby se minimalizovalo riziko ztráty. Možná 3KB? Nejdříve by bylo vhodné věci instrumentovat, aby se změřilo, jak často by se to využívalo.

Dodání OBEP do 1-z-N nebo N-z-N tunelů

Mon, 01 Jan 0001 00:00:00 +0000

Přehled

Tento návrh zahrnuje dvě vylepšení pro zlepšení výkonu sítě:

Předání výběru IBGW do rukou OBEPu tím, že mu poskytne seznam alternativ namísto jediné možnosti.
Povolení směrování multicastových paketů na straně OBEPu.

Motivace

V případě přímého spojení jde o snížení zahlcení spojení tím, že OBEPu dáme větší volnost, jak se připojuje k IBGW. Schopnost zadat více tunelů nám také umožňuje implementovat multicast na straně OBEPu (tím, že zpráva bude doručena do všech zadaných tunelů).

ECIES Routery

Mon, 01 Jan 0001 00:00:00 +0000

Poznámka

Síťové nasazení a testování probíhá. Podléhá revizi. Stav:

ECIES Routery implementovány od verze 0.9.48, viz Common .
Vytváření tunelů implementováno od verze 0.9.48, viz Tunnel-Creation-ECIES .
Šifrované zprávy pro ECIES routery implementovány od verze 0.9.49, viz ECIES-ROUTERS .
Nové zprávy pro stavbu tunelů implementovány od verze 0.9.51.

Přehled

Shrnutí

Identifikátory routerů aktuálně obsahují šifrovací klíč ElGamal. Toto je standard od počátků I2P. ElGamal je pomalý a je potřeba jej nahradit ve všech místech, kde je používán.

ECIES tunely

Mon, 01 Jan 0001 00:00:00 +0000

Poznámka

Nasazení sítě a testování probíhá. Podléhá drobným revizím. Viz SPEC pro oficiální specifikaci.

Přehled

Tento dokument navrhuje změny šifrování zpráv Tunnel Build pomocí kryptografických primitiv zavedených v ECIES-X25519 . Je součástí celkového návrhu Proposal 156 pro převod routerů z ElGamal na ECIES-X25519 klíče.

Pro účely přechodu sítě z ElGamal + AES256 na ECIES + ChaCha20 jsou nezbytné tunnely se smíšenými ElGamal a ECIES routery. Jsou poskytnuty specifikace pro zpracování smíšených tunnel hopů. Nebudou provedeny žádné změny ve formátu, zpracování nebo šifrování ElGamal hopů.

ECIES-P256

Mon, 01 Jan 0001 00:00:00 +0000

Motivace

ECIES-P256 je mnohem rychlejší než ElGamal. Existuje několik eepsites i2pd s typem šifrování ECIES-P256 a Java by s nimi měla být schopna komunikovat a naopak. i2pd jej podporuje od verze 2.16.0 (0.9.32 Java).

Přehled

Tento návrh zavádí nový typ šifrování ECIES-P256, který se může objevit v části certifikátu identity, nebo jako samostatný typ šifrování v LeaseSet2. Lze použít v RouterInfo, LeaseSet1 a LeaseSet2.

Umístění klíčů ElGamal

Pro zopakování, veřejné klíče ElGamal o délce 256 bajtů lze nalézt v následujících datových strukturách. Odkaz na specifikaci společných struktur.

ECIES-X25519-AEAD-Ratchet

Mon, 01 Jan 0001 00:00:00 +0000

Poznámka

Nasazení sítě a testování probíhají. Předmět menších revizí. Viz SPEC pro oficiální specifikaci.

Následující funkce nejsou implementovány ve verzi 0.9.46:

Bloky MessageNumbers, Options a Termination
Odpovědi na úrovni protokolu
Nulový statický klíč
Multicast

Přehled

Toto je návrh prvního nového typu end-to-end šifrování od počátku I2P, který nahradí ElGamal/AES+SessionTags Elg-AES .

Spoléhá na předchozí práci následovně:

Společné struktury spec Common Structures
I2NP spec včetně LS2
ElGamal/AES+Session Tags Elg-AES
http://zzz.i2p/topics/1768 přehled nové asymetrické kryptografie
Přehled nízkoúrovňové kryptografie CRYPTO-ELG
ECIES http://zzz.i2p/topics/2418
NTCP2 Proposal 111
123 Nové záznamy v netDB
142 Nová šablona kryptografie
Noise protokol
Signal algoritmus dvojitého klikačky

Cílem je podpora nového šifrování pro end-to-end, komunikaci z cíle do cíle.

GOST Sig Type

Mon, 01 Jan 0001 00:00:00 +0000

Přehled

Podpis eliptické křivky GOST R 34.10 používaný úřady a podniky v Rusku. Podpora by mohla zjednodušit integraci existujících aplikací (obvykle založených na CryptoPro). Hash funkce je GOST R 34.11 o 32 nebo 64 bajtech. V zásadě funguje stejným způsobem jako EcDSA, podpis a velikost veřejného klíče je 64 nebo 128 bajtů.

Motivace

Kryptografie eliptických křivek nikdy nebyla zcela důvěryhodná a vyvolává mnoho spekulací o možných zadních vrátkách. Proto neexistuje žádný ultimátní typ podpisu, kterému by všichni věřili. Přidání dalšího typu podpisu poskytne lidem více možností, kterým více důvěřují.

I2P návrh č. 166: Identity/Host Aware Tunnel Types

Mon, 01 Jan 0001 00:00:00 +0000

Návrh hostitelem-vědomého typu HTTP proxy tunelu

Toto je návrh řešení „Problému sdílené identity“ při běžném použití HTTP přes I2P, který zavádí nový typ HTTP proxy tunelu. Tento typ tunelu má doplňkové chování, jehož cílem je zabránit nebo omezit užitečnost sledování prováděného potenciálně nepřátelskými operátory skrytých služeb vůči cíleným uživatelským agentům (prohlížečům) a samotné I2P klientské aplikaci.

Co je „Problém sdílené identity“?

„Problém sdílené identity“ nastává, když uživatelský agent na kryptograficky adresované překryvné síti sdílí kryptografickou identitu s jiným uživatelským agentem. K tomu dochází například, když jsou Firefox a GNU Wget nakonfigurovány tak, aby používaly stejnou HTTP proxy.

Kontrola ID dopravní sítě

Mon, 01 Jan 0001 00:00:00 +0000

Přehled

NTCP2 (návrh 111) neodmítá spojení s různými ID sítí ve fázi žádosti o spojení. Spojení musí být v současné době odmítnuto ve fázi potvrzení spojení, když Bob zkontroluje Alicein RI.

Podobně SSU neodmítá spojení s různými ID sítí ve fázi žádosti o spojení. Spojení musí být v současné době odmítnuto po fázi potvrzení spojení, když Bob zkontroluje Alicein RI.

Tento návrh mění fázi žádosti o spojení obou protokolů tak, aby zahrnoval ID sítě, způsobem kompatibilním s předchozími verzemi.

LeaseSet 2

Mon, 01 Jan 0001 00:00:00 +0000

Přehled

Tento návrh se zabývá novým formátem LeaseSet s podporou novějších typů šifrování.

Motivace

Kryptografie typu end-to-end, která je používána v tunelech I2P, má oddělené šifrovací a podepisovací klíče. Podepisovací klíče jsou součástí destinace tunelu, která již byla rozšířena certifikáty klíčů na podporu novějších typů podpisů. Šifrovací klíče jsou však součástí LeaseSet, která neobsahuje žádné certifikáty. Z tohoto důvodu je nutné implementovat nový formát LeaseSet a přidat podporu pro jeho ukládání v netDb.

Limity Zácpy

Mon, 01 Jan 0001 00:00:00 +0000

Přehled

Přidejte indikátory zácpy do publikovaných informací o směrovači (RI).

Motivace

Šířkové “limity” (schopnosti) indikují sdílené limity šířky pásma a dosažitelnost, ale ne stav zácpy. Indikátor zácpy pomůže směrovačům vyhnout se pokusům o budování přes ucpaný směrovač, což přispívá k větší zácpě a snížené úspěšnosti budování tunelu.

Návrh

Definujte nové limity pro indikaci různých úrovní zácpy nebo problémů s kapacitou. Tyto limity budou umístěny v nejvyšší úrovni RI, ne v adresových limitech.

Menší zprávy o stavbě tunelu

Mon, 01 Jan 0001 00:00:00 +0000

Poznámka

Implementováno od verze API 0.9.51. Probíhá testování a nasazení v síti. Předmět drobných úprav. Pro konečnou specifikaci vizte I2NP a Tunnel-Creation-ECIES .

Přehled

Shrnutí

Aktuální velikost zašifrovaných záznamů požadavků a odpovědí na konstrukci tunelu je 528. U typických zpráv proměnných konstrukcí tunelu a odpovědí na proměnné konstrukce tunelu je celková velikost 2113 bajtů. Tato zpráva je rozdělena na tři 1KB tunelové zprávy pro zpětnou cestu.

Změny formátu 528-bajtového záznamu pro směrovače ECIES-X25519 jsou specifikovány v Prop152 a Tunnel-Creation-ECIES . Pro směs směrovačů ElGamal a ECIES-X25519 v tunelu musí velikost záznamu zůstat 528 bajtů. Avšak pokud jsou všechny směrovače v tunelu ECIES-X25519, je možné vytvořit nový, menší záznam konstrukce, protože šifrování ECIES-X25519 má mnohem menší režii než ElGamal.

Meta-LeaseSet pro multihoming

Mon, 01 Jan 0001 00:00:00 +0000

Přehled

Tento návrh se týká implementace správné podpory multihomingu v I2P, která může škálovat až na velké weby.

Motivace

Multihoming je hack a pravděpodobně nebude fungovat pro např. facebook.i2p v měřítku. Řekněme, že bychom měli 100 multihomů, každý se 16 tunely, to by bylo 1600 publikací LS každých 10 minut, nebo téměř 3 za sekundu. Floodfill servery by byly přetíženy a spuštěny omezení. A to jsme ještě nezmínili vyhledávací provoz.

Možnosti Zprávy o Výstavbě Tunelu

Mon, 01 Jan 0001 00:00:00 +0000

Poznámka

Tento návrh nebyl implementován tak, jak bylo specifikováno, nicméně dlouhé a krátké zprávy o výstavbě ECIES (návrhy 152 a 157) byly navrženy s rozšiřitelnými poli možností. Viz specifikace Tunnel Creation ECIES pro oficiální specifikaci.

Přehled

Přidat flexibilní a rozšiřitelný mechanismus pro volby v I2NP Záznamech o Výstavbě Tunelu, které jsou obsaženy ve Zprávách o Výstavbě Tunelu a Odpovědích na Výstavbu Tunelu.

Motivace

Existuje několik předběžných, nezveřejněných návrhů na nastavení možností nebo konfigurace ve Zprávě o Výstavbě Tunelu, takže tvůrce tunelu může předat některé parametry každému skoku tunelu.

Multicast

Mon, 01 Jan 0001 00:00:00 +0000

Přehled

Základní myšlenka: Odeslat jednu kopii přes váš odchozí tunel, odchozí koncový bod distribuuje ke všem vstupním branám. Konec-konec šifrování vyloučeno.

Návrh

Nový typ multicast tunelové zprávy (typ doručení = 0x03)
Odchozí koncový bod multicast distribuce
Nový typ I2NP Multicast Zprávy?
Nový typ I2CP Multicast SendMessageMessage Zprávy
Nešifrovat router-router v OutNetMessageOneShotJob (česnek?)

Aplikace:

RTSP Proxy?

Streamr:

Nastavit MTU? Nebo to udělat jen v aplikaci?
Přijem a přenos na požádání

Multipath TCP pro streaming

Mon, 01 Jan 0001 00:00:00 +0000

Přehled

Tento návrh se zabývá rozšířením streamování, které využívá více tunelů na připojení, podobně jako multipath TCP.

Motivace

Klientské tunely jsou používány streamovací knihovnou způsobem podobným standardnímu TCP.

Bylo by vhodnější umožnit řešení podobné multipath TCP, kde jsou klientské tunely využívány na základě individuálních charakteristik, jako jsou:

Latence
Kapacita
Dostupnost

Návrh

TBD

Návrh I2P č. 165: Oprava SSU2

Mon, 01 Jan 0001 00:00:00 +0000

Návrh od weko, orignal, the Anonymous a zzz.

Přehled

Tento dokument navrhuje změny v SSU2 po útoku na I2P, který využil zranitelnosti v SSU2. Hlavním cílem je zvýšit bezpečnost a zabránit útokům typu Distributed Denial of Service (DDoS) a pokusům o de-anonymizaci.

Model hrozby

Útočník vytváří nové falešné routerové informace (RI) (router neexistuje): je to běžná RI, ale vloží adresu, port, klíče s a i z opravdového Bobova routeru, a poté zaplaví síť. Když se snažíme připojit k tomuto (jak si myslíme opravdovému) routeru, jako Alice se můžeme připojit k této adrese, ale nemůžeme si být jisti, co se stalo s opravdovou Bobovou RI. To je možné a bylo použito pro útok typu Distributed Denial of Service (vytvořit velké množství takových RIs a zaplavit síť), také to může usnadnit de-anonymizační útoky tím, že budou “nasazeny” dobré routery a útočníkovy routery nebudou napadány, pokud zakážeme IP s mnoha RIs (místo toho, abychom lépe rozprostřeli stavbu tunelu k těmto RI jako k jednomu routeru).

Neviditelný Multihoming

Mon, 01 Jan 0001 00:00:00 +0000

Přehled

Tento návrh popisuje návrh protokolu umožňujícího klientovi I2P, službě nebo externímu procesu vyrovnávání zatížení spravovat více směrovačů transparentně hostujících jedinou Destination .

Návrh aktuálně nespecifikuje konkrétní implementaci. Může být implementován jako rozšíření I2CP , nebo jako nový protokol.

Motivace

Multihoming znamená použití více směrovačů k hostování stejné Destination. Současný způsob multihomingu s I2P spočívá v běhu stejné Destination na každém směrovači nezávisle; směrovač, který je v daném okamžiku používán klienty, je ten, který naposledy publikoval LeaseSet.

Nová šablona návrhu šifrování

Mon, 01 Jan 0001 00:00:00 +0000

Přehled

Tento dokument popisuje důležité otázky, které je třeba zvážit při navrhování náhrady nebo doplnění naší asymetrické šifry ElGamal.

Toto je dokument informačního charakteru.

Motivace

ElGamal je starý a pomalý, a existují lepší alternativy. Existuje však několik problémů, které je nutné vyřešit, než budeme moci přidat nebo přejít na jakýkoli nový algoritmus. Tento dokument tyto nevyřešené otázky zdůrazňuje.

Předběžný výzkum

Každý, kdo navrhuje novou kryptografii, musí být nejprve obeznámen s následujícími dokumenty:

Nové záznamy netDB

Mon, 01 Jan 0001 00:00:00 +0000

Stav

Části tohoto návrhu jsou dokončeny a implementovány ve verzích 0.9.38 a 0.9.39.
Společné struktury, I2CP, I2NP a další specifikace
jsou nyní aktualizovány, aby odrážely změny, které jsou nyní podporovány.

Dokončené části jsou stále předmětem drobných revizí.
Další části tohoto návrhu jsou stále ve vývoji
a podléhají významným revizím.

Vyhledávání služeb (typy 9 a 11) má nízkou prioritu,
není naplánováno a může být přesunuto do samostatného návrhu.

Přehled

Toto je aktualizace a agregace následujících 4 návrhů:

NTCP 2

Mon, 01 Jan 0001 00:00:00 +0000

Poznámka

Fáze návrhu je uzavřena. Viz SPEC pro oficiální specifikaci. Tento návrh může být stále odkazován pro informace o pozadí.

Přehled

Tento návrh popisuje autentizovaný protokol pro výměnu klíčů, který zlepšuje odolnost NTCP proti různým formám automatizované identifikace a útokům.

Návrh je organizován následovně: jsou představeny bezpečnostní cíle, následuje diskuse o základním protokolu. Dále je uveden kompletní specifikaci všech protokolových zpráv. Nakonec jsou diskutovány adresy routerů a identifikace verze. Je také připojena příloha, která diskutuje o generickém útoku na běžné schéma paddingu, a další příloha, která obsahuje několik kandidátů na autentizovaný šifrovací algoritmus.

NTCP Zatemnění

Mon, 01 Jan 0001 00:00:00 +0000

Přehled

Tento návrh se týká přepracování transportu NTCP za účelem zlepšení jeho odolnosti vůči automatizované identifikaci.

Motivace

NTCP data jsou šifrována po prvním zprávě (a první zpráva se jeví jako náhodná data), což zabraňuje identifikaci protokolu přes “analýzu obsahu”. Stále je však náchylný k identifikaci protokolu prostřednictvím “analýzy toku”. To proto, že první 4 zprávy (tj. handshake) mají pevnou délku (288, 304, 448 a 48 bajtů).

Přidáním náhodného množství náhodných dat ke každé ze zpráv můžeme situaci značně ztížit.

Obousměrné tunely

Mon, 01 Jan 0001 00:00:00 +0000

Přehled

Tento návrh se týká implementace obousměrných tunelů v I2P.

Motivace

i2pd hodlá zavést obousměrné tunely, které budou prozatím budovány pouze přes jiné směrovače i2pd. Pro síť se budou jevit jako běžné vstupní a výstupní tunely.

Návrh

Cíle

Snížit využití sítě a CPU snížením počtu zpráv TunnelBuild
Schopnost okamžitě zjistit, zda účastník odešel.
Přesnější profilování a statistiky
Použití jiných darknetů jako mezilehlých peerů

Úpravy tunelů

TunnelBuild

Tunely jsou budovány stejným způsobem jako vstupní tunely. Není vyžadována žádná odpověď. Existuje speciální typ účastníka nazývaný "entrance" označený vlajkou, který slouží jako IBGW a OBEP současně. Zpráva má stejný formát jako VaribaleTunnelBuild, ale ClearText obsahuje různá pole::

 in_tunnel_id
 out_tunnel_id
 in_next_tunnel_id
 out_next_tunnel_id
 in_next_ident
 out_next_ident
 layer_key, iv_key

Bude také obsahovat pole zmiňující, k jakému darknetu patří další peer, a nějaké dodatečné informace, pokud to není I2P.

TunnelTermination

Pokud chce peer odejít, vytvoří zprávy TunnelTermination, zašifruje je s pomocí klíče vrstvy a odešle ve směru “in”. Pokud účastník obdrží takovou zprávu, znovu ji zašifruje svým klíčem vrstvy a odešle dalšímu peerovi. Jakmile zpráva dosáhne majitele tunelu, začne ji dešifrovat peer po peeru, dokud se nedostane k nezašifrované zprávě. Zjistí, který peer odešel, a ukončí tunel.

Omezené Trasy

Mon, 01 Jan 0001 00:00:00 +0000

Úvod

Myšlenky

Přidat nový transport “IND” (nepřímý), který zveřejní hash leaseSet ve struktuře RouterAddress: “IND: [key=aababababababababb]”. Tento transport nabízí nejnižší prioritu, když cílový směrovač jej zveřejní. Chcete-li poslat peerovi přes tento transport, získejte leaseset z ff peer jako obvykle a pošlete jej přímo na lease.
Peer, který inzeruje IND, musí vytvořit a udržovat sadu tunelů k jinému peerovi. Nejedná se o průzkumné tunely ani o tunely klienta, ale o druhou sadu směrovačových tunelů.

Parametry šířky pásma tunelu

Mon, 01 Jan 0001 00:00:00 +0000

POZNÁMKA

Tento návrh byl schválen a je nyní součástí Tunnel Creation ECIES specification od API 0.9.65. Zatím nejsou známy žádné implementace; data implementace / verze API jsou TBD.

Přehled

Jak jsme během posledních několika let zvýšili výkon sítě s novými protokoly, typy šifrování a vylepšeními řízení přetížení, rychlejší aplikace jako streamování videa se stávají možnými. Tyto aplikace vyžadují vysokou šířku pásma na každém kroku ve svých tunelích klienta.

Účastnické routery však nemají žádné informace o tom, kolik šířky pásma tunel použije, když obdrží požadavek na vytvoření tunelu. Mohou pouze přijmout nebo odmítnout tunel na základě aktuálního celkového využití šířky pásma všemi účastnickými tunely a celkového limitu šířky pásma pro účastnické tunely.

Podpora Floodfill pro Experimentální Typy Podpisů

Mon, 01 Jan 0001 00:00:00 +0000

Přehled

Pro typy podpisů v experimentálním rozmezí (65280-65534), by měly floodfills akceptovat úložiště netdb bez kontroly podpisu.

Tím se podpoří testování nových typů podpisů.

Motivace

Návrh GOST 134 odhalil dva problémy s dříve nepoužívaným experimentálním rozsahem typů podpisů.

Za prvé, protože typy podpisů v experimentálním rozmezí nemohou být rezervovány, mohou být použity pro více typů podpisů najednou.

Za druhé, pokud nemůže být router info nebo lease set s experimentálním typem podpisu uložen v floodfill, je nový typ podpisu obtížné plně otestovat nebo použít na zkušební bázi.

Podpora Floodfill pro Volitelné Typy Podpisů

Mon, 01 Jan 0001 00:00:00 +0000

Přehled

Přidat možnost, aby floodfilly inzerovaly podporu pro volitelné typy podpisů. To poskytne způsob, jak podporovat nové typy podpisů z dlouhodobého hlediska, i když je nebudou podporovat všechny implementace.

Motivace

Návrh GOST 134 odhalil několik problémů s dříve nepoužívaným experimentálním rozsahem typů podpisů.

Za prvé, protože typy podpisů v experimentálním rozsahu nelze rezervovat, mohou být použity pro více typů podpisů současně.

Za druhé, pokud router info nebo lease set s experimentálním typem podpisu nemůže být uložen na floodfill, nový typ podpisu je obtížné plně otestovat nebo použít jako zkušební verzi.

Pomocníci pro ověřené adresy

Mon, 01 Jan 0001 00:00:00 +0000

Přehled

Tento návrh přidává autentizační mechanismus k URL adresních pomocníků.

Motivace

URL adresních pomocníků jsou inherentně nezabezpečené. Kdokoli může vložit parametr adresního pomocníka do odkazu, dokonce i do obrázku, a může vložit libovolný cíl do parametru URL “i2paddresshelper”. V závislosti na implementaci uživatelského HTTP proxy, toto mapování hostname/cíl, pokud momentálně není v adresáři, může být přijato, buď s nebo bez mezistupňové obrazovky pro uživatele k přijetí.

Návrh

Důvěryhodné přeskakovací servery a služby registrace do adresáře by poskytovaly nové odkazy adresního pomocníka, které přidávají autentizační parametry. Dva nové parametry by byly základní 64 podpis a řetězec podepsáno kym.

Poplatek za neaktivitu pro položky v adresáři

Mon, 01 Jan 0001 00:00:00 +0000

Přehled

Pokud je adresa offline po dlouhou dobu, měla by být odstraněna z adresáře a jméno by se mělo stát dostupným pro novou registraci. Tak to aktuálně funguje v inr.

Co když však majitel už nemá zájem tuto službu provozovat, ale chce si adresu uchovat, aby se vyhnul podvodům atd.? Měli bychom zavést roční poplatek. Adresa by zůstala v adresáři, dokud by byl poplatek zaplacen. Pokud je zpět online, už žádný poplatek není potřeba. V případě služby stats.i2p by peníze měly jít do rozpočtu I2P.

Post-kvantové kryptografické protokoly

Mon, 01 Jan 0001 00:00:00 +0000

Stav

Protokol / Vlastnost	Stav
Ratchet	Dokončeno v Java I2P a i2pd
NTCP2	Beta Q1 2026
SSU2	Implementace začíná brzy, Beta Q23 2026
MLDSA SigTypes	Nízká priorita, pravděpodobně 2027+

Přehled

Zatímco výzkum a soutěž o vhodnou post-kvantovou (PQ) kryptografii probíhají již deset let, volby se staly jasnými teprve nedávno.

Začali jsme zkoumat důsledky PQ kryptografie v roce 2022 zzz.i2p .

TLS standardy přidaly podporu pro hybridní šifrování v posledních dvou letech a nyní se používá pro významnou část šifrovaného provozu na internetu díky podpoře v Chrome a Firefox Cloudflare .

Preferovat blízké směrovače v keyspace

Mon, 01 Jan 0001 00:00:00 +0000

Přehled

Toto je návrh na organizaci peerů tak, aby upřednostňovali připojení k jiným peerům, kteří jsou k nim blízko v keyspace.

Motivace

Myšlenkou je zlepšit úspěšnost vytváření tunelů tím, že se zvýší pravděpodobnost, že směrovač je již připojen k jinému.

Návrh

Požadované změny

Tato změna by vyžadovala:

Aby každý směrovač upřednostňoval připojení, která jsou blízko v keyspace.
Aby si každý směrovač byl vědom toho, že každý preferuje připojení blízko v keyspace.

Výhody pro vytváření tunelů

Pokud vytvoříte tunel::

Proces návrhov I2P

Mon, 01 Jan 0001 00:00:00 +0000

Přehled

Tento dokument popisuje, jak změnit specifikace I2P, jak fungují návrhy I2P a vztah mezi návrhy I2P a specifikacemi.

Tento dokument je adaptován z procesu návrhů Tor a většina obsahu níže byla původně napsána Nickem Mathewsonem.

Tento je informativní dokument.

Motivace

Předtím byl náš proces aktualizace specifikací I2P relativně neformální: navrhovali jsme návrh na vývojovém fóru a diskutovali o změnách, poté jsme dosáhli konsensu a opravili specifikaci s návrhy změn (ne nutně v tomto pořadí), a nakonec jsme provedli změny.

Protokol Datagram2

Mon, 01 Jan 0001 00:00:00 +0000

Stav

Schváleno při přezkumu 2025-04-15. Změny začleněny do specifikací. Implementováno v Java I2P od API 0.9.66. Pro stav zkontrolujte implementační dokumentaci.

Přehled

Vyjmuto z Prop123 jako samostatný návrh.

Offline podpisy nelze ověřit při zpracování odpověditelných datagramů. Je třeba příznak pro označení offline podpisu, ale není místo pro umístění příznaku.

Bude vyžadovat zcela nové číslo a formát protokolu I2CP, který bude přidán do specifikace DATAGRAMS . Nazvěme to “Datagram2”.

Cíle

Přidat podporu offline podpisů
Přidat ochranu proti replay útokům
Přidat variantu bez podpisů
Přidat příznaky a pole možností pro rozšiřitelnost

Necíle

Úplná podpora end-to-end protokolu pro řízení přetížení atd. To bude build nad nebo alternativou k Datagram2, který je protokolem na nižší úrovni. Nebylo by rozumné navrhovat vysoce výkonný protokol pouze na vrcholu Datagram2 kvůli poli “from” a režii podpisu. Jakýkoli takový protokol by měl provést počáteční handshake s Datagram2 a poté přepnout na nebalené datagramy (RAW).

Protokol Garlic Farm

Mon, 01 Jan 0001 00:00:00 +0000

Přehled

Toto je specifikace protokolu Garlic Farm pro přenos po drátě, založená na JRaft, jeho kódu „exts“ pro implementaci přes TCP a ukázkové aplikaci „dmprinter“ JRAFT .

Nepodařilo se nám nalézt žádnou implementaci s dokumentovaným protokolem pro přenos po drátě. Implementace JRaft je však dostatečně jednoduchá, abychom mohli prozkoumat kód a následně dokumentovat jeho protokol. Tento návrh je výsledkem tohoto úsilí.

Tato specifikace bude sloužit jako backend pro koordinaci směrovačů publikujících záznamy v Meta LeaseSet. Viz návrh 123.

Překlad Jména pro GarliCat

Mon, 01 Jan 0001 00:00:00 +0000

Přehled

Tento návrh se týká přidání podpory pro reverzní DNS dotazy do I2P.

Současný Mechanismus Překladu

GarliCat (GC) provádí překlad jmen pro navazování spojení s ostatními uzly GC. Tento překlad jmen je pouze překódování binární reprezentace adresy do Base32 kódovaného tvaru. Překlad tedy funguje obousměrně.

Tyto adresy jsou zvoleny jako 80bitové. Důvodem je, že Tor používá 80bitové hodnoty pro adresování svých skrytých služeb. Takže OnionCat (což je GC pro Tor) funguje s Tor bez dalšího zásahu.

Přiřadit OBEPs k IBGWs

Mon, 01 Jan 0001 00:00:00 +0000

Přehled

Tento návrh přidává možnost I2CP pro odchozí tunely, která způsobuje, že tunely jsou vybrány nebo postaveny při odeslání zprávy tak, že OBEP odpovídá jednomu z IBGW z LeaseSet pro cílovou Destinaci.

Motivace

Většina I2P směrovačů používá formu zahazování paketů pro řízení přetížení. Referenční implementace používá strategii WRED, která bere v úvahu jak velikost zprávy, tak cestovní vzdálenost (viz dokumentace tunnel throttling ). Díky této strategii je primárním zdrojem ztráty paketů OBEP.

Příznak I2CP pro přepínání odchozích tunelů

Mon, 01 Jan 0001 00:00:00 +0000

Přehled

Připojení streamovacího klienta se mohou zaseknout, pokud jsou potvrzení doručení ztracena beze zbytku. Odesílatel znovu přenáší data, dokud nedostane potvrzení nebo dokud není připojení ukončeno, přičemž neexistuje spolehlivý způsob, jak ověřit, že potvrzení dosahují druhé strany. Tento návrh přidává jeden nový příznakový bit do pole příznaků SendMessageExpiresMessage , aby klient mohl směrovači přikázat, aby pro následující zprávy na stejný cíl zvolil jiný odchozí tunel. Streamovací protokol tento bit využívá k aktivaci přepnutí tunelu při detekci zaseklého připojení.

PT Transport

Mon, 01 Jan 0001 00:00:00 +0000

Přehled

Tento návrh je určen pro vytvoření I2P transportu, který se připojuje k dalším routerům prostřednictvím připojitelných přenosů.

Motivace

Připojitelné přenosy (PTs) byly vyvinuty projektem Tor jako způsob, jak modulárně přidávat obfuskační přenosy k Tor bridge.

I2P již má modulární transportní systém, který snižuje bariéru k přidání alternativních přenosů. Přidání podpory pro PTs by poskytlo I2P snadný způsob, jak experimentovat s alternativními protokoly a připravit se na odolnost vůči blokování.

Quasi DNS

Mon, 01 Jan 0001 00:00:00 +0000

Přehled

Tento návrh spočívá v použití DNS přes datagramy pro subdomény.

Motivace

TBD

Návrh

TBD

Specifikace

TBD

Migrace

TBD

Red25519 podpisová schéma

Mon, 01 Jan 0001 00:00:00 +0000

Poznámka

Probíhá nasazení a testování v síti. Podléhá drobným úpravám. Viz specification pro oficiální specifikace.

Přehled

Tento návrh popisuje přesměrovatelnou podpisovou schéma vhodnou pro vytváření Destinací, které mohou být oslepeny. Navíc může být použita k oslepení existujících Ed25519 Destinací, s mírným snížením efektivity.

Motivace

Proposal 123 definuje šifrovaný formát LeaseSet2, který ztělesňuje Princip minima autorit: každému účastníkovi sítě je poskytnuta pouze informace nezbytná pro jejich roli. Zejména šifrovaný LeaseSet2 publikovaný na floodfill neodhaluje Destinaci, pro kterou je, a Leases mohou být viděny pouze někým s předchozí znalostí Destinace. Nicméně, floodfills stále potřebují být schopny autentizovat šifrované LeaseSet2, když jsou publikovány, a klienti musí mít navíc jistotu, že autentizace byla provedena samotnou Destinací.

RedDSA-BLAKE2b-Ed25519

Mon, 01 Jan 0001 00:00:00 +0000

Přehled

Tento návrh přidává nový typ podpisu používající BLAKE2b-512 s personalizačními řetězci a soli, aby nahradil SHA-512. Toto eliminuje tři třídy možných útoků.

Motivace

Během diskusí a návrhu NTCP2 (návrh 111) a LS2 (návrh 123) jsme krátce zvažovali různé možné útoky a způsoby, jak jim zabránit. Tři z těchto útoků jsou útoky rozšíření délky (Length Extension Attacks), útoky mezi protokoly (Cross-Protocol Attacks) a identifikace duplicitních zpráv (Duplicate Message Identification).

Pro NTCP2 i LS2 jsme se rozhodli, že tyto útoky nebyly přímo relevantní pro dané návrhy a jakákoli řešení by byla v rozporu s cílem minimalizovat nové primitiva. Také jsme zjistili, že rychlost hashovacích funkcí v těchto protokolech nebyla důležitým faktorem v našich rozhodnutích. Proto jsme řešení většinou odložili na samostatný návrh. Ačkoli jsme do specifikace LS2 přidali některé personalizační funkce, nevyžadovali jsme žádné nové hashovací funkce.

Resetovací zpráva pro ElGamal/AES+SessionTags

Mon, 01 Jan 0001 00:00:00 +0000

Přehled

Tento návrh je pro zprávu I2NP, kterou lze použít k resetování relace tagů mezi dvěma destinacemi.

Motivace

Představte si, že nějaká destinace má spoustu potvrzených tagů k jiné destinaci. Ale tato destinace byla restartována nebo ztratila tyto tagy nějakým jiným způsobem. První destinace stále posílá zprávy s tagy a druhá destinace nemůže dešifrovat. Druhá destinace by měla mít možnost říct první destinaci, aby resetovala (začala od začátku) prostřednictvím dalšího garlic clove stejně, jako posílá aktualizovaný LeaseSet.

RI a výplň cíle

Mon, 01 Jan 0001 00:00:00 +0000

Stav

Implementováno ve verzi 0.9.57.
Ponecháváme tuto navrženou změnu otevřenou, abychom mohli rozvíjet a diskutovat nápady v části „Plánování do budoucna“.

Přehled

Shrnutí

Veřejný klíč ElGamal v Destinacích se nepoužívá od verze 0.6 (2005).
I když naše specifikace uvádějí, že se nevyužívá, NEuvádějí, že implementace mohou vynechat generování dvojice klíčů ElGamal a pole jednoduše naplnit náhodnými daty.

Navrhujeme změnit specifikace tak, aby bylo uvedeno, že pole je ignorováno a implementace MOHOU pole naplnit náhodnými daty.
Tato změna je zpětně kompatibilní. Neznáme žádnou implementaci, která by ověřovala veřejný klíč ElGamal.

Rozsah portů v Routerinfo

Mon, 01 Jan 0001 00:00:00 +0000

Přehled

Nebo místo toho uvést jeden port.

Klient se může připojit k jakémukoli z nich a měl by si vybrat náhodně. To učiní vzor provozu méně rozpoznatelným, pomůže obejít DPI a některé antiddos filtry.

Také může být použit pro rovnoměrné rozložení zátěže pro velmi vytížené uzly v budoucnosti.

Motivace

TBD

Návrh

TBD

Specifikace

TBD

Migrace

TBD

Rozšíření I2PControl

Mon, 01 Jan 0001 00:00:00 +0000

Přehled

Tento návrh zpřístupňuje nové informace přes API i2pcontrol, čímž umožňuje větší flexibilitu. Tyto informace zahrnují: přidávání, mazání, načítání a úpravu addressbooků (adresářů) a skrytých služeb. Návrh také zpřístupňuje další informace o vašem routeru, jako jsou peerové, novinky, netDb a další.

Motivace

Případ použití pro tento návrh spočívá vytvoření sjednoceného a zjednodušeného konzolového rozhraní směrovače, které lze sdílet napříč všemi implementacemi směrovače s běžnou sadou i2p tunelů. Tento návrh v podstatě umožňuje intuitivnější a uživatelsky přívětivější zkušenost pro uživatele po celé síti I2P.

Sbírání statistik s možností přihlášení

Mon, 01 Jan 0001 00:00:00 +0000

Přehled

Tento návrh se týká systému automatizovaného reportování statistik s možností dobrovolného přihlášení.

Motivace

V současné době je několik síťových parametrů určeno na základě kvalifikovaných odhadů. Existuje podezření, že některé z nich lze upravit, aby se zlepšil celkový výkon sítě, pokud jde o rychlost, spolehlivost a podobně. Nicméně, měnit je bez řádného výzkumu je velmi riskantní.

Návrh

Router podporuje rozsáhlou sbírku statistik, které lze použít k analýze vlastností celé sítě. Co potřebujeme, je automatizovaný systém reportování, který sbírá tyto statistiky na centralizovaném místě. Samozřejmě by to bylo s možností dobrovolného přihlášení, protože to do značné míry ničí anonymitu. (Na statistiky přátelské k ochraně soukromí již slouží stats.i2p) Jako odhad lze říci, že pro síť o velikosti 30 000 by vzorek 300 reportujících routerů měl být dostatečně reprezentativní.

Seznam blokací ve Zpravodajském kanálu

Mon, 01 Jan 0001 00:00:00 +0000

Přehled

Tento návrh je určen k distribuci aktualizací seznamu blokací v souboru zpráv, který je distribuován ve formátu podepsaného su3. Implementováno ve verzi 0.9.28.

Motivace

Bez toho je seznam blokací aktualizován pouze v rámci vydání. Využívá stávající odběr zpráv. Tento formát by mohl být použit v různých implementacích routerů, ale pouze Java router nyní používá odběr zpráv.

Návrh

Přidat novou sekci do souboru news.xml. Umožnit blokování podle IP nebo hashe routeru. Sekce bude mít své vlastní časové razítko. Umožnit odblokování dříve blokovaných položek.

Seznam blokovaných ve formátu SU3

Mon, 01 Jan 0001 00:00:00 +0000

Přehled

Tento návrh je určen k distribuci aktualizací seznamu blokovaných v samostatném souboru su3.

Motivace

Bez tohoto opatření je seznam blokovaných aktualizován pouze při vydání. Tento formát by mohl být použit v různých implementacích routeru.

Návrh

Definujte formát, který má být zabalen do souboru su3. Umožňuje blokování podle IP adresy nebo hash routeru. Routery se mohou přihlásit k odběru URL, nebo importovat soubor získaný jinými prostředky. Soubor su3 obsahuje podpis, který musí být při importu ověřen.

SSU2

Mon, 01 Jan 0001 00:00:00 +0000

Stav

Plán nasazení:

Funkce	Testování (není výchozí)	Povoleno ve výchozím nastavení
Lokální testovací kód	2022-02
Společný testovací kód	2022-03
Společný test v síti	0.9.54 2022-05
Zmrazení základního protokolu	0.9.54 2022-05
Základní relace	0.9.55 2022-08	0.9.56 2022-11
Ověření adresy (opakování)	0.9.55 2022-08	0.9.56 2022-11
Fragmentované RI v handshake	0.9.55 2022-08	0.9.56 2022-11
Nový token	0.9.55 2022-08	0.9.57 2022-11
Zmrazení rozšířeného protokolu	0.9.55 2022-08
Relé	0.9.55 2022-08	0.9.56 2022-11
Test protějšku	0.9.55 2022-08	0.9.56 2022-11
Povoleno pro náhodných 2 %	0.9.55 2022-08
Ověření cesty	0.9.55+ dev	0.9.56 2022-11
Migrace připojení	0.9.55+ dev	0.9.56 2022-11
Příznak okamžitého potvrzení	0.9.55+ dev	0.9.56 2022-11
Rotace klíčů	0.9.57 2023-02	0.9.58 2023-05
Zakázání SSU 1 (i2pd)	0.9.56 2022-11
Zakázání SSU 1 (Java I2P)	0.9.58 2023-05	0.9.61 2023-12

Základní relace zahrnuje handshake a datovou fázi. Rozšířený protokol zahrnuje relé a test protějšku.

Streamované MTU pro cíle ECIES

Mon, 01 Jan 0001 00:00:00 +0000

Poznámka

Nasazení a testování sítě probíhá. Předmět malých revizí.

Přehled

Shrnutí

ECIES snižuje režii existujících relačních (ES) zpráv o přibližně 90 bajtů. Proto můžeme zvýšit MTU o přibližně 90 bajtů pro ECIES spojení. Viz specifikace ECIES , specifikace Streaming a dokumentace Streaming API .

Bez zvýšení MTU nejsou úspory režie v mnoha případech skutečně „uloženy“, protože zprávy budou stejně doplněny na dvě plné tunelové zprávy.

Tento návrh nevyžaduje žádné změny specifikací. Je publikován pouze jako návrh, aby usnadnil diskuzi a dosažení konsensu ohledně doporučené hodnoty a detailů implementace.

Šifrování ChaCha pro vrstvy v tunelech

Mon, 01 Jan 0001 00:00:00 +0000

Přehled

Tento návrh navazuje na a vyžaduje změny z návrhu 152: ECIES Tunnels.

Pouze tunely postavené přes uzly podporující formát BuildRequestRecord pro ECIES-X25519 tunely mohou implementovat tuto specifikaci.

Tato specifikace vyžaduje formát Tunnel Build Options pro indikaci typu šifrování tunelové vrstvy a přenášení klíčů pro vrstvy AEAD.

Cíle

Cíle tohoto návrhu jsou:

Nahradit AES256/ECB+CBC ChaCha20 pro zavedené IV tunelu a šifrování vrstev
Použít ChaCha20-Poly1305 pro meziuzlovou AEAD ochranu
Být neodhalitelný stávajícími účastníky tunelové vrstvy
Neměnit celkovou délku tunelové zprávy

Zpracování Zavedené Tunelové Zprávy

Tato sekce popisuje změny pro:

Šifrovaný LeaseSet

Mon, 01 Jan 0001 00:00:00 +0000

Přehled

Tato návrh se zabývá přepracováním mechanismu pro šifrování LeaseSets.

Motivace

Současné šifrované LS jsou hrozné a nebezpečné. Mohu to říct, protože jsem je navrhl a implementoval.

Důvody:

Šifrováno pomocí AES CBC
Jeden AES klíč pro všechny
Časové expirace Lease jsou stále přístupné
Šifrovací pubkey jsou stále přístupné

Návrh

Cíle

Zcela zakrýt celý proces
Klíče pro každého příjemce

Strategie

Postupujme stejně jako GPG/OpenPGP. Asymetricky šifrujeme symetrický klíč pro každého příjemce. Data jsou dešifrována pomocí toho asymetrického klíče. Viz např. RFC-4880-S5.1 Pokud můžeme najít algoritmus, který je malý a rychlý.

Testování IPv6 Peer

Mon, 01 Jan 0001 00:00:00 +0000

Přehled

Tento dokument navrhuje implementaci SSU Peer Testování pro IPv6. Implementováno v 0.9.27.

Motivace

Nemůžeme spolehlivě určit a sledovat, zda je naše IPv6 adresa za firewallem.

Když jsme před lety přidali podporu IPv6, předpokládali jsme, že IPv6 nikdy není za firewallem.

Nedávno, v 0.9.20 (květen 2015), jsme interně rozdělili status dostupnosti v4/v6 (ticket #1458). Viz tento ticket pro rozsáhlé informace a odkazy.

Pokud máte jak v4, tak v6 za firewallem, můžete jednoduše vynutit stav za firewallem v sekci konfigurace TCP na /confignet.

TLS Transport

Mon, 01 Jan 0001 00:00:00 +0000

Přehled

Tento návrh se týká implementace transportu založeného na TLS.

Motivace

Často se navrhuje, abychom měli transport odolný proti odposlechu, abychom byli odolní proti fingerprintingu a blokování ze strany ISP a státních protivníků, jak má Tor (tj. snaží se vypadat jako relace Firefox HTTPS).

Návrh

Bude doplněno

Trvalost klíčů LeaseSet

Mon, 01 Jan 0001 00:00:00 +0000

Přehled

Tento návrh se týká uchovávání dodatečných dat v LeaseSet, která jsou aktuálně nestálá. Implementováno ve verzi 0.9.18.

Motivace

V 0.9.17 byla přidána trvalost pro netDb slicing klíč, uložený v i2ptunnel.config. To pomáhá předcházet některým útokům tím, že se při restartu routeru udržuje stejný slice, a také to zabraňuje možné korelaci s restartem routeru.

Existují další dvě věci, které se dají ještě snadněji korelovat s restartem routeru: klíče pro šifrování a podepisování leasesetu. Tyto aktuálně nejsou uchovávány.

Typy MIME I2P

Mon, 01 Jan 0001 00:00:00 +0000

Přehled

Definice typů MIME pro běžné formáty souborů I2P. Zahrňte definice do balíčků pro Debian. Poskytněte obsluhu pro typ .su3 a případně další.

Motivace

Aby bylo jednodušší osévat a instalovat pluginy při stahování s prohlížečem, potřebujeme typ MIME a obsluhu pro soubory .su3.

Zatímco jsme u toho, po naučení se, jak psát soubory definice MIME podle standardu freedesktop.org, můžeme přidat definice pro další běžné typy souborů I2P. I když jsou méně užitečné pro soubory, které se obvykle nestahují, jako je databáze blokovaných adresářů (hostsdb.blockfile), tyto definice umožní soubory lépe identifikovat a ikony zobrazit při použití grafického prohlížeče adresářů, jako je “nautilus” na Ubuntu.

UDP Trackery

Mon, 01 Jan 0001 00:00:00 +0000

Stav

Schváleno při kontrole 2025-06-24. Specifikace je na UDP specification . Implementováno v zzzot 0.20.0-beta2. Implementováno v i2psnark od API 0.9.67. Zkontrolujte dokumentaci dalších implementací pro stav.

Přehled

Tento návrh je pro implementaci UDP trackerů v I2P.

Change History

Předběžný návrh pro UDP trackery v I2P byl zveřejněn na naší stránce specifikace bittorrent v květnu 2014; tento návrh předcházel našemu formálnímu procesu návrhů a nikdy nebyl implementován. Tento návrh byl vytvořen začátkem roku 2022 a zjednodušuje verzi z roku 2014.

Větší I2NP Zprávy

Mon, 01 Jan 0001 00:00:00 +0000

Přehled

Tento návrh se týká zvýšení limitu velikosti I2NP zpráv.

Motivace

Použití 12KB datagramů v iMule odhalilo mnoho problémů. Skutečný limit je dnes spíše kolem 10KB.

Návrh

Je potřeba udělat:

Zvýšit limit NTCP - není tak snadné?
Více úprav množství značek relací. Může to poškodit maximální velikost okna? Existují statistiky pro náhled? Udělat číslo proměnlivé na základě toho, kolik si myslíme, že potřebují? Mohou žádat o více? žádat o množství?

Vyhledávání v databázi z cílů ECIES

Mon, 01 Jan 0001 00:00:00 +0000

Poznámka

ECIES to ElG je implementováno v 0.9.46 a fáze návrhu je uzavřena. Viz I2NP pro oficiální specifikaci. Tento návrh může být stále používán jako pozadí pro informace. ECIES to ECIES s přiloženými klíči je implementováno od verze 0.9.48. Sekce ECIES-to-ECIES (odvozené klíče) může být znovu otevřena nebo začleněna do budoucího návrhu.

Přehled

Definice

AEAD: ChaCha20/Poly1305
DLM: I2NP Database Lookup Message
DSM: I2NP Database Store Message
DSRM: I2NP Database Search Reply Message
ECIES: ECIES-X25519-AEAD-Ratchet (návrh 144)
ElG: ElGamal
ENCRYPT(k, n, payload, ad): Jak je definováno v ECIES
LS: Leaseset
lookup: I2NP DLM
reply: I2NP DSM nebo DSRM

Shrnutí

Při odesílání DLM pro LS do floodfill, DLM obvykle specifikuje, že odpověď musí být označena, zašifrována AES a odeslána tunelem do cíle. Podpora pro AES-zašifrované odpovědi byla přidána v 0.9.7.

Vylepšení přenosu IPv6

Mon, 01 Jan 0001 00:00:00 +0000

Poznámka

Nasazení sítě a testování probíhá. Předmět malých revizí.

Přehled

Tento návrh má za cíl implementovat vylepšení přenosů SSU a NTCP2 pro IPv6.

Motivace

Jak roste využití IPv6 po celém světě a nastavení pouze s IPv6 (zejména na mobilních zařízeních) se stávají běžnějšími, musíme zlepšit podporu IPv6 a odstranit předpoklady, že všechny směrovače jsou schopné IPv4.

Kontrola připojení

Při výběru peerů pro tunely nebo při výběru cest OBEP/IBGW pro směrování zpráv je užitečné zjistit, zda směrovač A dokáže navázat spojení se směrovačem B. Obecně to znamená určit, zda A má výstupní schopnost pro přenos a typ adresy (IPv4/v6), který odpovídá jedné z příchozích adres inzerovaných B.

Vypršení platnosti zaváděče

Mon, 01 Jan 0001 00:00:00 +0000

Přehled

Tento návrh se týká zlepšení úspěšnosti úvodů.

Motivace

Úvodci po určité době vyprší, ale tato informace není zveřejněna v informacích o směrovači (Router Info). Směrovače aktuálně musí používat heuristiku k odhadu, kdy již úvodce není platný.

Návrh

Ve směrovačové adrese SSU obsahující úvodce může vydavatel volitelně uvést čas vypršení platnosti pro každého úvodce.

Specifikace

iexp{X}={nnnnnnnnnn}

X :: Číslo úvodce (0-2)

nnnnnnnnnn :: Čas v sekundách (nikoli ms) od počátku epochy.

Poznámky

Každé vypršení musí být větší než datum publikování informací o směrovači (Router Info) a menší než 6 hodin po datu publikování informací o směrovači.

Zaslepení klíče ECDSA

Mon, 01 Jan 0001 00:00:00 +0000

Motivace

Někteří lidé nemají rádi EdDSA nebo RedDSA. Měli bychom nabídnout nějaké alternativy a umožnit jim zaslepení podpisů ECDSA.

Přehled

Tento návrh popisuje zaslepení klíčů pro typy podpisů ECDSA 1, 2, 3.

Návrh

Funguje stejně jako RedDSA, ale vše je ve formátu Big Endian. Jsou povoleny pouze stejné typy podpisů, např. 1->1, 2->2, 3->3.

Definice

B Základní bod křivky

L Řád skupiny eliptické křivky. Vlastnost křivky.

DERIVE_PUBLIC(a) Převod soukromého klíče na veřejný, násobením B na eliptické křivce

Záznamy služeb v LS2

Mon, 01 Jan 0001 00:00:00 +0000

Stav

Schváleno při druhém přezkoumání dne 2025-04-01; specifikace byly aktualizovány; zatím neimplementováno.

Přehled

I2P nemá centralizovaný systém DNS.
Nicméně, adresář spolu se systémem doménových jmen b32 umožňuje směrovači vyhledat úplné cíle a stáhnout lease sety, které obsahují seznam bran a klíčů, aby se klienti mohli k tomuto cíli připojit.

Lease sety jsou tedy něčím podobné záznamům DNS. V současnosti však neexistuje žádný způsob, jak zjistit, zda daný hostitel podporuje nějaké služby, a to buď na tomto cíli, nebo na jiném, podobně jako záznamy DNS SRV definované v RFC 2782 .

Zjišťování služby

Mon, 01 Jan 0001 00:00:00 +0000

Přehled

Toto je bombastická absolutní návrh v rámci netDB. AKA anycast. Toto by byl 4. navržený podtyp LS2.

Motivace

Řekněme, že byste chtěli inzerovat svůj cíl jako outproxy, nebo GNS node, nebo Tor gateway, nebo Bittorrent DHT nebo imule nebo i2phex nebo Seedless bootstrap, atd. Můžete uložit tyto informace v netDB namísto použití samostatné bootstrapping vrstvy nebo informační vrstvy.

Nikdo není za to zodpovědný, takže na rozdíl od masivního multihomingu nemůžete mít podepsaný autoritativní seznam. Takže byste jen publikovali svůj záznam do floodfill. Floodfill by tyto záznamy shromažďoval a odesílal je jako odpověď na dotazy.

Zrušení používání hostitelů v adresách routeru

Mon, 01 Jan 0001 00:00:00 +0000

Přehled

Od verze 0.9.32 aktualizace specifikace netdb ruší používání hostitelů v informacích o routeru, přesněji v jednotlivých adresách routeru. Ve všech implementacích I2P by publikující routery konfigurované s hostiteli měly před publikováním nahradit hostitele IP adresami, a ostatní routery by měly ignorovat adresy s hostiteli. Routery by neměly provádět DNS dotazy na publikované hostitele.

Motivace

Hostitelé byli v adresách routeru povoleni od začátku I2P. Ovšem, velmi málo routerů hostitele publikuje, protože to vyžaduje veřejného hostitele (kterého má jen málo uživatelů) a manuální nastavení (o které se málo uživatelů stará). Nedávný vzorek ukázal, že 0.7 % routerů hostitele publikovalo.

Zvýšení IPv6 MTU

Mon, 01 Jan 0001 00:00:00 +0000

Přehled

Tento návrh je na zvýšení max SSU IPv6 MTU z 1472 na 1488. Implementováno v 0.9.28.

Motivace

IPv4 MTU musí být násobkem 16, + 12. IPv6 MTU musí být násobkem 16.

Když byla podpora IPv6 poprvé přidána před lety, nastavili jsme max IPv6 MTU na 1472, méně než IPv4 MTU 1484. Toto bylo, aby věci zůstaly jednoduché a aby bylo zajištěno, že IPv6 MTU bylo menší než stávající IPv4 MTU. Nyní, když je podpora IPv6 stabilní, bychom měli být schopni nastavit IPv6 MTU vyšší než IPv4 MTU.