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.
Stejně jako u ostatních I2P transportů je NTCP2 definován výhradně pro bod-to-bod (router-to-router) transport zpráv I2NP. Není to obecný datový potrubí.
Motivace
NTCP data jsou šifrována po první zprávě (a první zpráva vypadá jako náhodná data), což brání identifikaci protokolu pomocí “analýzy payloadu”. Je stále zranitelný vůči identifikaci protokolu pomocí “analýzy toku”. To je způsobeno tím, že první 4 zprávy (tj. handshake) mají pevnou délku (288, 304, 448 a 48 byte).
Přidáním náhodného množství náhodných dat do každé zprávy můžeme učinit identifikaci protokolu mnohem obtížnější.
Autoři uznávají, že standardní bezpečnostní postupy by naznačovaly použití existujícího protokolu, jako je TLS, ale toto je Prop104 a má své vlastní problémy. Tam, kde je to vhodné, byly přidány odstavce “budoucí práce”, aby označily chybějící funkce nebo předměty diskuse.
Cíle návrhu
Podpora NTCP 1 a 2 na jednom portu, automatické zjištění a publikace jako jeden “transport” (tj. RouterAddress) v NetDB .
Publikace podpory pro verzi 1 pouze, 2 pouze nebo 1+2 v NetDB v samostatném poli a výchozí hodnota je verze 1 pouze (nepřipojujte podporu verze k určité verzi routeru)
Ujistěte se, že všechny implementace (Java/i2pd/Kovri/go) mohou přidat podporu verze 2 (nebo ne) podle svého vlastního plánu
Přidejte náhodné padding do všech NTCP zpráv, včetně handshake a datových zpráv (tj. obfuskace délky, aby všechny zprávy nebyly násobkem 16 byte)
Poskytněte mechanismus pro obě strany, aby požadovaly minimální a maximální padding a/nebo distribuci paddingu. Specifika distribuce paddingu jsou závislé na implementaci a mohou nebo nemusí být specifikovány v protokolu samotném.
Obfuskuje obsah zpráv, které nejsou šifrovány (1 a 2), dostatečně, aby DPI krabičky a AV signatury nemohly snadno klasifikovat. Ujistěte se také, že zprávy směrované na jednoho peer nebo sadu peerů nemají podobný vzorec bitů.
Opravte ztrátu bitů v DH kvůli Java formátu Ticket1112 , možná (pravděpodobně?) přepnutím na X25519.
Přepněte na skutečnou funkci derivace klíče (KDF) místo použití výsledku DH jako takového?
Přidejte “odolnost vůči sondování” (jak ji nazývá Tor); to zahrnuje odolnost vůči opakovanému přehrání.
Zachovejte 2-cestnou autentizovanou výměnu klíčů (2W-AKE). 1W-AKE není dostatečné pro naše aplikace.
Pokračujte v použití proměnného typu, proměnné délky signatur (z publikovaného RouterIdentity signing klíče) jako části autentizace. Spoléhejte se na statický veřejný klíč publikovaný v RouterInfo jako další část autentizace.
Přidejte možnosti/verzi do handshake pro budoucí rozšiřitelnost.
Přidejte odolnost vůči škodlivému MitM TCP segmentaci, pokud je to možné.
Nezvyšujte významně CPU požadavky pro nastavení připojení; pokud je to možné, snížte je významně.
Přidejte autentizaci zpráv (MAC), možná HMAC-SHA256 a Poly1305, a odeberte Adler checksum.
Zkratěte a zjednodušte I2NP hlavičku: Zkratěte expiraci na 4 byte, jako v SSU. Odeberte jeden byte zkrácený SHA256 checksum.
Pokud je to možné, zkratěte 4-zprávu, dvoukolový handshake na 3-zprávu, jednokolový handshake, jako v SSU . To by vyžadovalo přesunutí Bobovy signatury ve zprávě 4 do zprávy 2. Prozkoumejte důvod pro 4 zprávy v deset let starém emailu/status/meeting archive.
Minimalizujte protokolový overhead před paddingem. Zatímco padding bude přidán, a možná hodně, overhead před paddingem je stále overhead. Nízkopásmové uzly musí být schopny používat NTCP2.
Zachovejte časové razítko pro detekci opakovaného přehrání a odchylky.
Vyhněte se problémům s rokem 2038 v časových razítcích, musí fungovat alespoň do roku 2106.
Zvyšte maximální velikost zprávy z 16K na 32K nebo 64K.
Jakékoli nové kryptografické primitivy by měly být snadno dostupné v knihovnách pro použití v Java (1.7), C++ a Go router implementacích.
Zahrňte zástupce Java, C++ a Go router vývojářů do návrhu.
Minimalizujte změny (ale budou stále hodně).
Podporujte obě verze v společném kódu (to nemusí být možné a je závislé na implementaci v každém případě).
Není cílem
Bezpečnost proti DPI… to by byly vkládané transporty, Prop109 .
TLS-based (nebo HTTPS-lookalike) transport… to by byl Prop104 .
Je v pořádku změnit symetrickou proudovou kryptografii.
Časově založená odolnost proti DPI (mezi-zprámové časování/zpoždění může být závislé na implementaci; intra-zprámové zpoždění může být přidáno v libovolném bodě, včetně před odesláním náhodného paddingu, například). Umělé zpoždění (co obfs4 nazývá IAT nebo inter-arrival time) jsou nezávislé na protokolu samotném.
Odepření účasti na relaci (existují signatury v nich).
Není cílem, který může být částečně přehodnocen nebo diskutován:
Stupeň ochrany proti Deep Packet Inspection (DPI)
Post-Quantum (PQ) bezpečnost
Odepření
Související cíle
- Implementujte testovací nastavení NTCP 1/2
Bezpečnostní cíle
Zvažujeme tři strany:
- Alice, která chce navázat novou relaci.
- Bob, se kterým Alice chce navázat relaci.
- Mallory, “člověk uprostřed” mezi Alicí a Bobem.
Nejvýše dvě strany mohou se účastnit aktivních útoků.
Alice a Bob jsou oba v držení statického klíčového páru, který je obsažen v jejich RouterIdentity.
Navrhovaný protokol se snaží umožnit Alici a Bobovi dohodnout se na sdíleném tajném klíči (K) za následujících požadavků:
Bezpečnost soukromého klíče: ani Bob ani Mallory se nic nedozví o Alicině statickém soukromém klíči. Symetricky, Alice se nic nedozví o Bobově statickém soukromém klíči.
Relační klíč K je známý pouze Alicí a Bobem.
Dokonalá forward sekrece: dohodnutý relační klíč zůstává tajný v budoucnosti, i když jsou statické soukromé klíče Alici a/nebo Boba odhaleny po dohodnutí klíče.
Dvoucestná autentizace: Alice je jistá, že navázala relaci s Bobem, a naopak.
Ochrana proti online DPI: Ujistěte se, že není triviální detekovat, že Alice a Bob jsou zapojeni do protokolu pomocí pouze přímé techniky DPI. Viz níže.
Omezené odepření: ani Alice ani Bob nemohou popřít účast v protokolu, ale pokud některá ze stran prozradí sdílený klíč, druhá strana může popřít autenticitu obsahu přenesených dat.
Tento návrh se snaží poskytnout všechny pět požadavků na základě protokolu Station-To-Station (STS). Poznámka: Tento protokol je také základem pro SSU protokol.
Další diskuse o DPI
Zvažujeme dva DPI komponenty:
1) Online DPI
Online DPI inspektor všech toků v reálném čase. Připojení mohou být blokována nebo jinak poškozena. Data nebo metadata připojení mohou být identifikována a uložena pro offline analýzu. Online DPI nemá přístup k I2P síťové databázi. Online DPI má pouze omezenou reálnou výpočetní schopnost, včetně délky výpočtu, inspekce polí a jednoduchých výpočtů, jako je XOR. Online DPI má schopnost rychlých reálných kryptografických funkcí, jako je AES, AEAD a hašování, ale tyto by byly příliš nákladné na to, aby se aplikovaly na většinu nebo všechna připojení. Jakékoli použití těchto kryptografických operací by se aplikovalo pouze na připojení na IP/Port kombinacích, které byly dříve identifikovány offline analýzou. Online DPI nemá schopnost nákladných kryptografických funkcí, jako je DH nebo elligator2. Online DPI není navržen speciálně pro detekci I2P, i když může mít omezená klasifikační pravidla pro tento účel.
Je cílem zabránit identifikaci protokolu online DPI.
Pojem online nebo “přímé” DPI je zde chápán jako zahrnující následující schopnosti útočníka:
Schopnost inspektorovat všechna data odesílaná nebo přijímaná cílem.
Schopnost provádět operace na pozorovaných datech, jako je aplikování blokových šifer nebo hašovacích funkcí.
Schopnost ukládat a porovnávat s předchozími zprávami.
Schopnost modifikovat, zpožďovat nebo fragmentovat pakety.
Nicméně, online DPI je předpokládán mít následující omezení:
Neschopnost mapovat IP adresy na router haše. Zatímco to je triviální s reálným přístupem k síťové databázi, to by vyžadovalo DPI systém speciálně navržený pro cílení I2P.
Neschopnost použít časové informace k detekci protokolu.
Obecně řečeno, online DPI nástrojová skříňka neobsahuje žádné vestavěné nástroje, které jsou speciálně navrženy pro detekci I2P. To zahrnuje vytváření “honeypotů”, které by například zahrnovaly nenáhodné padding v svých zprávách. Poznámka: To nevylučuje strojové učící systémy nebo vysoce konfigurovatelné DPI nástroje, pokud splňují ostatní požadavky.
Abychom se vyhnuli analýze payloadu, je zajištěno, že všechny zprávy jsou nerozlišitelné od náhodných. To také vyžaduje, aby jejich délka byla náhodná, což je složitější než jen přidání náhodného paddingu. Ve skutečnosti, v Příloze A, autoři argumentují, že naivní (tj. uniformní) padding schéma nevyřeší problém. Příloha A proto navrhuje zahrnout buď náhodné zpoždění nebo vyvinout alternativní padding schéma, které může poskytnout rozumnou ochranu proti navrhovanému útoku.
Abychom se ochránili proti šestému vstupu výše, implementace by měly zahrnovat náhodné zpoždění v protokolu. Tyto techniky nejsou pokryty tímto návrhem, ale mohly by také vyřešit problémy s délkou paddingu. Shrnutí: Návrh poskytuje dobrou ochranu proti analýze payloadu (když jsou vzaty v úvahu úvahy v Příloze A), ale pouze omezenou ochranu proti analýze toku.
2) Offline DPI
Offline DPI inspektor dat uložených online DPI pro pozdější analýzu. Offline DPI může být navržen speciálně pro detekci I2P. Offline DPI má reálný přístup k I2P síťové databázi. Offline DPI má přístup k tomuto a jiným I2P specifikacím. Offline DPI má neomezenou výpočetní schopnost, včetně všech kryptografických funkcí definovaných v této specifikaci.
Offline DPI nemá schopnost blokovat existující připojení. Offline DPI má schopnost near-reálného (v rámci několika minut od nastavení) odesílání na host/port stran, například TCP RST. Offline DPI má schopnost near-reálného (v rámci několika minut od nastavení) opakovaného přehrání předchozích zpráv (modifikovaných nebo ne) pro “sondování” nebo jiné účely.
Není cílem zabránit identifikaci protokolu offline DPI. Všechny dekódování obfuskovaných dat v prvních dvou zprávách, které jsou implementovány I2P routery, mohou být také implementovány offline DPI.
Je cílem odmítnout pokusy o navázání připojení pomocí opakovaného přehrání předchozích zpráv.
Budoucí práce
Zvažte chování protokolu, když pakety jsou ztraceny nebo přeřazeny útočníkem. Nedávná zajímavá práce v této oblasti lze nalézt v IACR-1150 .
Poskytněte více přesnou klasifikaci DPI systémů, s přihlédnutím k existující literatuře související s tímto předmětem.
Diskutujte formální bezpečnost navrhovaného protokolu, ideálně s přihlédnutím k DPI útočníkovi modelu.
Rámec Noise Protocol
Tento návrh poskytuje požadavky na základě Rámce Noise Protocol NOISE (Revize 33, 2017-10-04). Noise má podobné vlastnosti jako protokol Station-To-Station, který je základem pro SSU protokol. V Noise terminologii, Alice je iniciátor, a Bob je responder.
NTCP2 je založen na Noise protokolu Noise_XK_25519_ChaChaPoly_SHA256. (Skutečný identifikátor pro počáteční funkci derivace klíče je “Noise_XKaesobfse+hs2+hs3_25519_ChaChaPoly_SHA256” pro označení I2P rozšíření - viz sekce KDF 1 níže) Tento Noise protokol používá následující primitivy:
Handshake Pattern: XK Alice odesílá svůj klíč Bobovi (X) Alice již zná Bobův statický klíč (K)
DH Function: X25519 X25519 DH s délkou klíče 32 byte, jak je specifikováno v RFC-7748 .
Cipher Function: ChaChaPoly AEAD_CHACHA20_POLY1305, jak je specifikováno v RFC-7539 sekce 2.8. 12 byte nonce, s prvními 4 byte nastavenými na nulu.
Hash Function: SHA256 Standardní 32-byte haš, již široce používaný v I2P.
Přidání do Rámce
Tento návrh definuje následující rozšíření Rámce Noise_XK_25519_ChaChaPoly_SHA256. Tyto obecně následují pokyny v NOISE sekce 13.
Čistý textový ephemerální klíč je obfuskován pomocí AES šifrování s známým klíčem a IV. To je rychlejší než elligator2.
Náhodné čistý textové padding je přidáno do zpráv 1 a 2. Čistý textový padding je zahrnut do handshake hašovacího výpočtu (MixHash). Viz sekce KDF pro zprávu 2 a zprávu 3 část 1. Náhodné AEAD padding je přidáno do zprávy 3 a datových fází zpráv.
Dvoubyte pole délky rámce je přidáno, jak je vyžadováno pro Noise nad TCP, a jako v obfs4. To se používá v datových fázích zpráv pouze. Zprávy 1 a 2 AEAD rámce jsou pevné délky. Zpráva 3 část 1 AEAD rámec je pevné délky. Zpráva 3 část 2 AEAD rámec délka je specifikována v zprávě 1.
Dvoubyte pole délky rámce je obfuskováno pomocí SipHash-2-4, jako v obfs4.
Formát payloadu je definován pro zprávy 1, 2, 3 a datovou fázi. Samozřejmě, to není definováno v Noise.
Nové kryptografické primitivy pro I2P
Existující I2P router implementace budou vyžadovat implementace pro následující standardní kryptografické primitivy, které nejsou vyžadovány pro současné I2P protokoly:
X25519 klíč generace a DH
AEAD_ChaCha20_Poly1305 (zkráceně jako ChaChaPoly níže)
SipHash-2-4
Odhad zpracování overheadu
Velikost zpráv pro 3 zprávy:
- 64 byte + padding (NTCP bylo 288 byte)
- 64 byte + padding (NTCP bylo 304 byte)
- přibližně 64 byte + Alice router info + padding Průměrná velikost router info je asi 750 byte Celková průměrná velikost 814 byte před paddingem (NTCP bylo 448 byte)
- není vyžadováno v NTCP2 (NTCP bylo 48 byte)
Celková velikost před paddingem: NTCP2: 942 byte NTCP: 1088 byte Poznámka: Pokud Alice naváže spojení s Bobem za účelem odeslání DatabaseStore Message své RouterInfo, tato zpráva není vyžadována, šetrí asi 800 byte.
Následující kryptografické operace jsou vyžadovány každou stranou pro dokončení handshake a zahájení datové fáze:
- AES: 2
- SHA256: 7 (Alice), 6 (Bob) (ne včetně 1 Alice, 2 Bob prekalkulovaných pro všechna připojení) (ne včetně HMAC-SHA256)
- HMAC-SHA256: 19
- ChaChaPoly: 4
- X25519 klíč generace: 1
- X25519 DH: 3
- Verifikace signatury: 1 (Bob) (Alice dříve podepsala při generování své RI) Předpokládá se Ed25519 (závisí na typu signatury RI)
Následující kryptografické operace jsou vyžadovány každou stranou pro každou datovou fázi zprávu:
- SipHash: 1
- ChaChaPoly: 1
Zprávy
Všechny NTCP2 zprávy jsou menší nebo rovné 65537 byte v délce. Formát zprávy je založen na Noise zprávách, s modifikacemi pro framing a nerozlišitelnost. Implementace pomocí standardních Noise knihoven mohou potřebovat předzpracovat přijaté zprávy z/do formátu Noise zprávy. Všechna šifrovaná pole jsou AEAD ciphertexty.
Sequencia nastavení je následující:
Alice Bob
SessionRequest ------------------->
<------------------- SessionCreated
SessionConfirmed ----------------->
Používající Noise terminologii, nastavení a datová fáze sequencia je následující: (Bezpečnostní vlastnosti payloadu)
XK(s, rs): Autentizace Důvěrnost
<- s
...
-> e, es 0 2
<- e, ee 2 1
-> s, se 2 5
<- 2 5
Jakmile je relace nastavena, Alice a Bob mohou vyměňovat datové zprávy.
Všechny typy zpráv (SessionRequest, SessionCreated, SessionConfirmed, Data a TimeSync) jsou specifikovány v této sekci.
Několik poznámek:
- RH_A = Router Haš pro Alici (32 byte)
- RH_B = Router Haš pro Boba (32 byte)
Autentizovaná šifra
Existují tři samostatné instance autentizované šifry (CipherStates). Jedna během handshake fáze a dvě (přenos a příjem) pro datovou fázi. Každá má svůj vlastní klíč z KDF.
Šifrovaná/autentizovaná data budou reprezentována jako
+----+----+----+----+----+----+----+----+
| |
+ +
| Šifrovaná a autentizovaná data |
~ . . . ~
| |
+----+----+----+----+----+----+----+----+
ChaCha20/Poly1305
Formát šifrovaných a autentizovaných dat.
Vstupy do funkcí šifrování/dešifrování:
k :: 32 byte šifrovací klíč, generovaný z KDF
nonce :: Counter-based nonce, 12 byte.
Začíná na 0 a inkrementuje pro každou zprávu.
První čtyři byte jsou vždy nula.
Poslední osm byte je counter, little-endian kódovaný.
Maximální hodnota je 2**64 - 2.
Připojení musí být ukončeno a restartováno po dosažení této hodnoty.
Hodnota 2**64 - 1 nesmí být nikdy odeslána.
ad :: V handshake fázi:
Asociativní data, 32 byte.
SHA256 haš všech předchozích dat.
V datové fázi:
Nulové byte
data :: Čistý textový data, 0 nebo více byte
Výstup funkce šifrování, vstup do funkce dešifrování:
+----+----+----+----+----+----+----+----+
|Obfs Len | |
+----+----+ +
| ChaCha20 šifrovaná data |
~ . . . ~
| |
+----+----+----+----+----+----+----+----+
| Poly1305 Message Authentication Code |
+ (MAC) +
| 16 byte |
+----+----+----+----+----+----+----+----+
Obfs Len :: Délka (šifrovaná data + MAC) k následování, 16 - 65535
Obfuskace pomocí SipHash (viz níže)
Není použita ve zprávě 1 nebo 2, nebo ve zprávě 3 část 1, kde je délka pevná
Není použita ve zprávě 3 část 1, protože délka je specifikována ve zprávě 1
šifrovaná data :: Stejná velikost jako čistý textový data, 0 - 65519 byte
MAC :: Poly1305 message authentication code, 16 byte
Pro ChaCha20, co je zde popsáno odpovídá RFC-7539 , které je také použito podobně v TLS RFC-7905 .
Poznámky
Protože ChaCha20 je proudová šifra, čistý textový data nemusí být padnuty. Další keystream byte jsou zahozeny.
Klíč pro šifru (256 bitů) je dohodnut pomocí SHA256 KDF. Podrobnosti KDF pro každou zprávu jsou v samostatných sekcích níže.
ChaChaPoly rámce pro zprávy 1, 2 a první část zprávy 3, jsou známé velikosti. Začínající od druhé části zprávy 3, rámce jsou proměnné velikosti. Velikost zprávy 3 část 1 je specifikována ve zprávě 1. Začínající od datové fáze, rámce jsou předřazeny dvoubyte obfuskovanou délkou pomocí SipHash, jako v obfs4.
Padding je vně autentizovaného datového rámce pro zprávy 1 a 2. Padding je použito v KDF pro následující zprávu, takže jakýkoli úprava bude detekována. Začínající od zprávy 3, padding je uvnitř autentizovaného datového rámce.
AEAD Chyba zpracování
Ve zprávách 1, 2 a zprávě 3 části 1 a 2 je AEAD zpráva velikost známa předem. Při AEAD autentizační chybě, příjemce musí zastavit další zpracování zprávy a ukončit připojení bez odpovědi. To by mělo být abnormální ukončení (TCP RST).
Pro odolnost vůči sondování, ve zprávě 1, po AEAD chybě, Bob by měl nastavit náhodné zpoždění (rozsah TBD) a poté přečíst náhodné množství byte (rozsah TBD) před ukončením socketu. Bob by měl udržovat blacklist IP adres se opakovanými selháními.
V datové fázi, AEAD zpráva velikost je “šifrovaná” (obfuskovaná) pomocí SipHash. Je třeba dbát na to, aby nebyl vytvořen dešifrovací oracle. Při AEAD autentizační chybě v datové fázi, příjemce by měl nastavit náhodné zpoždění (rozsah TBD) a poté přečíst náhodné množství byte (rozsah TBD). Po přečtení, nebo na přečtení timeout, příjemce by měl odeslat payload s ukončovacím blokem obsahujícím “AEAD chyba” důvodový kód, a ukončit připojení.
Vezměte stejné chybové akce pro neplatnou délku pole hodnotu v datové fázi.
Funkce derivace klíče (KDF) (pro handshake zprávu 1)
KDF generuje handshake fáze šifrovací klíč k z DH výsledku, používající HMAC-SHA256(key, data) jako definováno v RFC-2104 . Tyto jsou InitializeSymmetric(), MixHash(), a MixKey() funkce, přesně jako definovány v Noise specifikaci.
Toto je "e" zpráva vzor:
// Definujte protocol_name.
Nastavte protocol_name = "Noise_XKaesobfse+hs2+hs3_25519_ChaChaPoly_SHA256"
(48 byte, US-ASCII kódování, žádné NULL ukončení).
// Definujte Hash h = 32 byte
h = SHA256(protocol_name);
Definujte ck = 32 byte chaining klíč. Zkopírujte h data do ck.
Nastavte ck = h
Definujte rs = Bobův 32-byte statický klíč jako publikovaný v RouterInfo
// MixHash(null prologue)
h = SHA256(h);
// až sem, může být vše prekalkulováno Alicí pro všechna odchozí připojení
// Alice musí ověřit, že Bobův statický klíč je platný bod na křivce zde.
// Bob statický klíč
// MixHash(rs)
// || níže znamená připojit
h = SHA256(h || rs);
// až sem, může být vše prekalkulováno Bobem pro všechna příchozí připojení
Toto je "e" zpráva vzor:
Alice generuje svůj ephemerální DH klíč pár e.
// Alice ephemerální klíč X
// MixHash(e.pubkey)
// || níže znamená připojit
h = SHA256(h || e.pubkey);
// h je použito jako asociativní data pro AEAD ve zprávě 1
// Zachovejte Hash h pro zprávu 2 KDF
Konec "e" zpráva vzor.
Toto je "es" zpráva vzor:
// DH(e, rs) == DH(s, re)
Definujte input_key_material = 32 byte DH výsledek Alicina ephemerálního klíče a Bobova statického klíče
Nastavte input_key_material = X25519 DH výsledek
// MixKey(DH())
Definujte temp_key = 32 byte
Definujte HMAC-SHA256(key, data) jako v [RFC-2104](https://tools.ietf.org/html/rfc2104)
// Generujte dočasný klíč z chaining klíče a DH výsledku
// ck je chaining klíč, definován výše
temp_key = HMAC-SHA256(ck, input_key_material)
// přepsat DH výsledek v paměti, již není potřeba
input_key_material = (všechny nuly)
// Výstup 1
// Nastavte nový chaining klíč z dočasného klíče
// byte() níže znamená jeden byte
ck = HMAC-SHA256(temp_key, byte(0x01)).
// Výstup 2
// Generujte šifrovací klíč k
Definujte k = 32 byte
// || níže znamená připojit
// byte() níže znamená jeden byte
k = HMAC-SHA256(temp_key, ck || byte(0x02)).
// přepsat dočasný klíč v paměti, již není potřeba
temp_key = (všechny nuly)
// Zachovejte chaining klíč ck pro zprávu 2 KDF
Konec "es" zpráva vzor.
1) SessionRequest
Alice odesílá Bobovi.
Noise obsah: Alicina ephemerální klíč X Noise payload: 16 byte options blok Non-noise payload: Náhodné padding
(Bezpečnostní vlastnosti payloadu)
XK(s, rs): Autentizace Důvěrnost
-> e, es 0 2
Autentizace: Žádná (0).
Tato payload mohla být odeslána jakoukoli stranou, včetně aktivního útočníka.
Důvěrnost: 2.
Šifrování pro známého příjemce, forward sekrece pro odesílatelův kompromit.
Tato payload je šifrována na základě DHs
zahrnujících příjemcův statický klíč pár. Pokud příjemcův statický soukromý
klíč je kompromitován, i v pozdější době, tato payload může být dešifrována.
Tato zpráva může být také opakovaně přehrána, protože zde není ephemerální
příspěvek od příjemce.
"e": Alice generuje nový ephemerální klíč pár a ukládá jej do e proměnné,
zapisuje ephemerální veřejný klíč jako čistý text do zprávy bufferu,
a hašuje veřejný klíč spolu se starým h pro odvození nového h.
"es": DH je proveden mezi Aliciným ephemerálním klíčem párem a Bobovým statickým klíčem párem.
Výsledek je hašen spolu se starým ck pro odvození nového ck a k, a n je nastaven na nulu.
Hodnota X je šifrována pro zajištění payload nerozlišitelnosti a jedinečnosti, které jsou nezbytné DPI protiopatření. Používáme AES šifrování k dosažení tohoto, místo složitějších a pomalejších alternativ, jako je elligator2. Asymetrické šifrování do Bobova router veřejného klíče by bylo příliš pomalé. AES šifrování používá Bobův router haš jako klíč a Bobův IV, jak je publikován v síťové databázi.
AES šifrování je pro DPI odolnost pouze. Jakákoli strana znající Bobův router haš a IV, které jsou publikovány v síťové databázi, mohou dešifrovat hodnotu X v této zprávě.
Raw obsah:
+----+----+----+----+----+----+----+----+
| |
+ obfuscated with RH_B +
| AES-CBC-256 encrypted X |
+ (32 bytes) +
| |
+ +
| |
+----+----+----+----+----+----+----+----+
| ChaChaPoly frame |
+ (32 bytes) +
| k defined in KDF for message 1 |
+ n = 0 +
| see KDF for associated data |
+----+----+----+----+----+----+----+----+
| unencrypted authenticated |
~ padding (optional) ~
| length defined in options block |
+----+----+----+----+----+----+----+----+
X :: 32 bytes, AES-256-CBC encrypted X25519 ephemerální klíč, little-endian
klíč: RH_B
iv: As published in Bobs network database entry
padding :: Náhodná data, 0 nebo více byte.
Celková zpráva délka musí být 65535 byte nebo méně.
Celková zpráva délka musí být 287 byte nebo méně, pokud
Bob publikuje svou adresu jako "NTCP"
(viz sekce Verze detekce níže).
Alice a Bob budou používat padding data v KDF pro zprávu 2.
Je autentizováno, takže jakýkoli úprava způsobí, že následující zpráva selže.
Nešifrovaná data (Poly1305 autentizační tag není zobrazen):
+----+----+----+----+----+----+----+----+
| |
+ +
| X |
+ (32 bytes) +
| |
+ +
| |
+----+----+----+----+----+----+----+----+
| options |
+ (16 bytes) +
| |
+----+----+----+----+----+----+----+----+
| unencrypted authenticated |
+ padding (optional) +
| length defined in options block |
~ . . . ~
| |
+----+----+----+----+----+----+----+----+
X :: 32 bytes, X25519 ephemerální klíč, little-endian
options :: options blok, 16 byte, viz níže
padding :: Náhodná data, 0 nebo více byte.
Celková zpráva délka musí být 65535 byte nebo méně.
Celková zpráva délka musí být 287 byte nebo méně, pokud
Bob publikuje svou adresu jako "NTCP"
(viz sekce Verze detekce níže)
Alice a Bob budou používat padding data v KDF pro zprávu 2.
Je autentizováno, takže jakýkoli úprava způsobí, že následující zpráva selže.
Options blok: Poznámka: Všechna pole jsou big-endian.
+----+----+----+----+----+----+----+----+
| id | ver| padLen | m3p2len | Rsvd(0) |
+----+----+----+----+----+----+----+----+
| tsA | Reserved (0) |
+----+----+----+----+----+----+----+----+
id :: 1 byte, síťový ID (aktuálně 2, kromě testovacích sítí)
Od 0.9.42. Viz návrh 147.
ver :: 1 byte, protokol verze (aktuálně 2)
padLen :: 2 byte, délka paddingu, 0 nebo více
Min/max pokyny TBD. Náhodná velikost od 0 do 31 byte minimum?
(Distribuce bude určena, viz Příloha A.)
m3p2Len :: 2 byte, délka druhého AEAD rámce v SessionConfirmed
(zpráva 3 část 2) Viz poznámky níže
Rsvd :: 2 byte, nastaveno na 0 pro kompatibilitu s budoucími možnostmi
tsA :: 4 byte, Unix timestamp, unsigned sekundy.
Přeteče v roce 2106
Reserved :: 4 byte, nastaveno na 0 pro kompatibilitu s budoucími možnostmi
Poznámky
Když je publikovaná adresa “NTCP”, Bob podporuje NTCP a NTCP2 na stejném portu. Pro kompatibilitu, když se iniciuje připojení k adrese publikované jako “NTCP”, Alice musí omezit maximální velikost této zprávy, včetně paddingu, na 287 byte nebo méně. To usnadňuje automatickou verzi detekci Bobem. Když je publikována jako “NTCP2”, není žádná velikostní omezení. Viz sekci Publikované adresy a Verze detekce níže.
Jedinečná hodnota X ve prvním AES bloku zajišťuje, že ciphertext je odlišný pro každou relaci.
Bob musí odmítnout připojení, kde je timestamp hodnota příliš daleko od aktuálního času. Nazvěme maximální časový rozdíl “D”. Bob musí udržovat místní cache dříve použitých handshake hodnot a odmítnout duplicity, aby se zabránilo opakovanému přehrání. Hodnoty v cache jsou závislé na implementaci, nicméně 32-byte hodnota X (nebo její ekvivalentní šifrovaná hodnota) může být použita.
Diffie-Hellman ephemerální klíče nesmí být nikdy opakovaně použity, aby se zabránilo kryptografickým útokům, a opakované použití bude odmítnuto jako opakované přehrání.
“KE” a “auth” možnosti musí být kompatibilní, tj. sdílený tajný klíč K musí být vhodné velikosti. Pokud jsou přidány další “auth” možnosti, to by mohlo implicitně změnit význam “KE” flagu na použití jiné KDF nebo jiné zkrácení velikosti.
Bob musí ověřit, že Alicina ephemerální klíč je platný bod na křivce zde.
Padding by měl být omezen na rozumné množství. Bob může odmítnout připojení s nadměrným paddingem. Bob bude specifikovat své padding možnosti ve zprávě 2. Min/max pokyny TBD. Náhodná velikost od 0 do 31 byte minimum? (Distribuce bude určena, viz Příloha A.)
Při jakékoli chybě, včetně AEAD, DH, timestamp, zdánlivém opakovaném přehrání nebo klíč ověření selhání, Bob musí zastavit další zpracování zprávy a ukončit připojení bez odpovědi. To by mělo být abnormální ukončení (TCP RST). Pro odolnost vůči sondování, po AEAD chybě, Bob by měl nastavit náhodné zpoždění (rozsah TBD) a poté přečíst náhodné množství byte (rozsah TBD), před ukončením socketu.
DoS Mitigace: DH je relativně nákladná operace. Jako v předchozím NTCP protokolu, routery by měly učinit všechny nezbytné kroky, aby zabránily CPU nebo připojení vyčerpání. Nastavte limity na maximální aktivní připojení a maximální připojení v průběhu. Vynutěte read timeoutes (jak na jeden read, tak na celkový “slowloris”). Omezte opakovaná nebo současná připojení ze stejného zdroje. Udržujte blacklisty pro zdroje, které opakovaně selhávají. Neodpovídejte na AEAD chybu.
Pro rychlou verzi detekci a handshake, implementace musí zajistit, aby Alice bufferovala a poté vyprázdnila celý obsah první zprávy najednou, včetně paddingu. To zvyšuje pravděpodobnost, že data budou obsažena v jednom TCP paketu (pokud nejsou segmentovány operačním systémem nebo middleboxy), a přijata najednou Bobem. To je také pro efektivitu a pro zajištění efektivity náhodného paddingu.
“ver” pole: Celý Noise protokol, rozšíření a NTCP protokol, včetně payload specifikací, indikující NTCP2. Toto pole může být použito pro indikaci podpory budoucích změn.
Zpráva 3 část 2 délka: Toto je velikost druhého AEAD rámce (včetně 16-byte MAC) obsahující Alicinu RouterInfo a optional padding, které budou odeslány ve SessionConfirmed zprávě. Jak routery pravidelně regenerují a republishují svou RouterInfo, velikost aktuální RouterInfo může změnit se před odesláním zprávy 3. Implementace musí zvolit jednu ze dvou strategií: a) uložit aktuální RouterInfo k odeslání ve zprávě 3, takže velikost je známa, a optional přidat prostor pro padding; b) zvýšit specifikovanou velikost dostatečně, aby umožnila možné zvýšení velikosti RouterInfo, a vždy přidat padding, když zpráva 3 je skutečně odeslána. V každém případě, “m3p2len” délka zahrnutá ve zprávě 1 musí být přesně velikost toho rámce, když odeslán ve zprávě 3.
Bob musí selhat připojení, pokud zůstávají jakékoli příchozí data po ověření zprávy 1 a přečtení paddingu. Neměly by být žádná další data od Alice, protože Bob belum odpověděl zprávou 2.
Síťový ID pole je použito pro rychlou identifikaci cross-síťových připojení. Pokud toto pole je nenulové a nesouhlasí s Bobovým síťovým ID, Bob by měl disconnect a zablokovat budoucí připojení. Od 0.9.42. Viz návrh 147 pro více informací.
Funkce derivace klíče (KDF) (pro handshake zprávu 2 a zprávu 3 část 1)
// vezměte h uložené z KDF pro zprávu 1
// MixHash(ciphertext)
h = SHA256(h || 32 byte šifrovaný payload z zprávy 1)
// MixHash(padding)
// Pouze pokud je padding délka nenulová
h = SHA256(h || náhodné padding z zprávy 1)
// h je použito jako asociativní data pro AEAD ve zprávě 2
// Zachovejte Hash h pro KDF pro zprávu 3
Toto je "e" zpráva vzor:
Bob generuje svůj ephemerální DH klíč pár e.
// h je z KDF pro zprávu 1
// Bob ephemerální klíč Y
// MixHash(e.pubkey)
// || níže znamená připojit
h = SHA256(h || e.pubkey);
// h je použito jako asociativní data pro AEAD ve zprávě 2
// Zachovejte Hash h pro KDF pro zprávu 3
Konec "e" zpráva vzor.
Toto je "ee" zpráva vzor:
// DH(e, re)
Definujte input_key_material = 32 byte DH výsledek Alicina ephemerálního klíče a Bobova ephemerálního klíče
Nastavte input_key_material = X25519 DH výsledek
// přepsat Alicinu ephemerální klíč v paměti, již není potřeba
// Alice:
e(public a private) = (všechny nuly)
// Bob:
re = (všechny nuly)
// MixKey(DH())
Definujte temp_key = 32 byte
Definujte HMAC-SHA256(key, data) jako v [RFC-2104](https://tools.ietf.org/html/rfc2104)
// Generujte dočasný klíč z chaining klíče a DH výsledku
// ck je chaining klíč, z KDF pro zprávu 1
temp_key = HMAC-SHA256(ck, input_key_material)
// přepsat DH výsledek v paměti, již není potřeba
input_key_material = (všechny nuly)
// Výstup 1
// Nastavte nový chaining klíč z dočasného klíče
// byte() níže znamená jeden byte
ck = HMAC-SHA256(temp_key, byte(0x01)).
// Výstup 2
// Generujte šifrovací klíč k
Definujte k = 32 byte
// || níže znamená připojit
// byte() níže znamená jeden byte
k = HMAC-SHA256(temp_key, ck || byte(0x02)).
// přepsat dočasný klíč v paměti, již není potřeba
temp_key = (všechny nuly)
// Zachovejte chaining klíč ck pro KDF pro zprávu 3
Konec "ee" zpráva vzor.
2) SessionCreated
Bob odesílá Alici.
Noise obsah: Bobův ephemerální klíč Y Noise payload: 16 byte options blok Non-noise payload: Náhodné padding
(Bezpečnostní vlastnosti payloadu)
XK(s, rs): Autentizace Důvěrnost
<- e, ee 2 1
Autentizace: 2.
Odesílatel autentizace odolná vůči key-compromise impersonation (KCI).
Odesílatel autentizace je založena na ephemerální-statickém DH ("es" nebo "se")
mezi odesílatelovým statickým klíčem párem a příjemcovým ephemerálním klíčem párem.
Předpokládající, že odpovídající soukromé klíče jsou bezpečné, tato autentizace nemůže být padělána.
Důvěrnost: 1.
Šifrování pro ephemerálního příjemce.
Tato payload má forward sekreci, protože šifrování zahrnuje ephemerální-ephermerální DH ("ee").
Nicméně, odesílatel nemá autentizován příjemce,
takže tato payload mohla být odeslána jakékoli straně, včetně aktivního útočníka.
"e": Bob generuje nový ephemerální klíč pár a ukládá jej do e proměnné,
zapisuje ephemerální veřejný klíč jako čistý text do zprávy bufferu,
a hašuje veřejný klíč spolu se starým h pro odvození nového h.
"ee": DH je proveden mezi Bobovým ephemerálním klíčem párem a Aliciným ephemerálním klíčem párem.
Výsledek je hašen spolu se starým ck pro odvození nového ck a k, a n je nastaven na nulu.
Hodnota Y je šifrována pro zajištění payload nerozlišitelnosti a jedinečnosti, které jsou nezbytné DPI protiopatření. Používáme AES šifrování k dosažení tohoto, místo složitějších a pomalejších alternativ, jako je elligator2. Asymetrické šifrování do Alicina router veřejného klíče by bylo příliš pomalé. AES šifrování používá Bobův router haš jako klíč a AES stav z zprávy 1 (který byl inicializován s Bobovým IV, jak je publikován v síťové databázi).
AES šifrování je pro DPI odolnost pouze. Jakákoli strana znající Bobův router haš a IV, které jsou publikovány v síťové databázi, a zachytila první 32 byte zprávy 1, mohou dešifrovat hodnotu Y v této zprávě.
Raw obsah:
+----+----+----+----+----+----+----+----+
| |
+ obfuscated with RH_B +
| AES-CBC-256 encrypted Y |
+ (32 bytes) +
| |
+ +
| |
+----+----+----+----+----+----+----+----+
| ChaChaPoly frame |
+ Encrypted and authenticated data +
| 32 bytes |
+ k defined in KDF for message 2 +
| n = 0; see KDF for associated data |
+ +
| |
+----+----+----+----+----+----+----+----+
| unencrypted authenticated |
+ padding (optional) +
| length defined in options block |
~ . . . ~
| |
+----+----+----+----+----+----+----+----+
Y :: 32 bytes, AES-256-CBC encrypted X25519 ephemerální klíč, little-endian
klíč: RH_B
iv: Using AES state from message 1
Nešifrovaná data (Poly1305 autentizační tag není zobrazen):
+----+----+----+----+----+----+----+----+
| |
+ +
| Y |
+ (32 bytes) +
| |
+ +
| |
+----+----+----+----+----+----+----+----+
| options |
+ (16 bytes) +
| |
+----+----+----+----+----+----+----+----+
| unencrypted authenticated |
+ padding (optional) +
| length defined in options block |
~ . . . ~
| |
+----+----+----+----+----+----+----+----+
Y :: 32 bytes, X25519 ephemerální klíč, little-endian
options :: options blok, 16 byte, viz níže
padding :: Náhodná data, 0 nebo více byte.
Celková zpráva délka musí být 65535 byte nebo méně.
Alice a Bob budou používat padding data v KDF pro zprávu 3 část 1.
Je autentizováno, takže jakýkoli úprava způsobí, že následující zpráva selže.
Poznámky
Alice musí ověřit, že Bobův ephemerální klíč je platný bod na křivce zde.
Padding by měl být omezen na rozumné množství. Alice může odmítnout připojení s nadměrným paddingem. Alice bude specifikovat své padding možnosti ve zprávě 3. Min/max pokyny TBD. Náhodná velikost od 0 do 31 byte minimum? (Distribuce bude určena, viz Příloha A.)
Při jakékoli chybě, včetně AEAD, DH, timestamp, zdánlivém opakovaném přehrání nebo klíč ověření selhání, Alice musí zastavit další zpracování zprávy a ukončit připojení bez odpovědi. To by mělo být abnormální ukončení (TCP RST).
Pro rychlou handshaking, implementace musí zajistit, aby Bob bufferoval a poté vyprázdnil celý obsah první zprávy najednou, včetně paddingu. To zvyšuje pravděpodobnost, že data budou obsažena v jednom TCP paketu (pokud nejsou segmentovány operačním systémem nebo middleboxy), a přijata najednou Alicí. To je také pro efektivitu a pro zajištění efektivity náhodného paddingu.
Alice musí selhat připojení, pokud zůstávají jakékoli příchozí data po ověření zprávy 2 a přečtení paddingu. Neměly by být žádná další data od Boba, protože Alice belum odpověděla zprávou 3.
Options blok: Poznámka: Všechna pole jsou big-endian.
+----+----+----+----+----+----+----+----+
| Rsvd(0) | padLen | Reserved (0) |
+----+----+----+----+----+----+----+----+
| tsB | Reserved (0) |
+----+----+----+----+----+----+----+----+
Reserved :: 10 byte celkem, nastaveno na 0 pro kompatibilitu s budoucími možnostmi
padLen :: 2 byte, big-endian, délka paddingu, 0 nebo více
Min/max pokyny TBD. Náhodná velikost od 0 do 31 byte minimum?
(Distribuce bude určena, viz Příloha A.)
tsB :: 4 byte, big-endian, Unix timestamp, unsigned sekundy.
Přeteče v roce 2106
Poznámky
- Alice musí odmítnout připojení, kde je timestamp hodnota příliš daleko od aktuálního času. Nazvěme maximální časový rozdíl “D”. Alice musí udržovat místní cache dříve použitých handshake hodnot a odmítnout duplicity, aby se zabránilo opakovanému přehrání. Hodnoty v cache jsou závislé na implementaci, nicméně 32-byte hodnota Y (nebo její ekvivalentní šifrovaná hodnota) může být použita.
Problémy
- Zahrňte minimální a maximální padding možnosti zde?
Šifrování pro handshake zprávu 3 část 1, pomocí KDF pro zprávu 2)
// vezměte h uložené z KDF pro zprávu 2
// MixHash(ciphertext)
h = SHA256(h || 24 byte šifrovaný payload z zprávy 2)
// MixHash(padding)
// Pouze pokud je padding délka nenulová
h = SHA256(h || náhodné padding z zprávy 2)
// h je použito jako asociativní data pro AEAD ve zprávě 3 část 1, níže
Toto je "s" zpráva vzor:
Definujte s = Alicina statická veřejná klíč, 32 byte
// EncryptAndHash(s.publickey)
// EncryptWithAd(h, s.publickey)
// AEAD_ChaCha20_Poly1305(key, nonce, associatedData, data)
// k je z handshake zprávy 1
// n je 1
ciphertext = AEAD_ChaCha20_Poly1305(k, n++, h, s.publickey)
// MixHash(ciphertext)
// || níže znamená připojit
h = SHA256(h || ciphertext);
// h je použito jako asociativní data pro AEAD ve zprávě 3 část 2
Konec "s" zpráva vzor.
Funkce derivace klíče (KDF) (pro handshake zprávu 3 část 2)
Toto je "se" zpráva vzor:
// DH(s, re) == DH(e, rs)
Definujte input_key_material = 32 byte DH výsledek Alicina statického klíče a Bobova ephemerálního klíče
Nastavte input_key_material = X25519 DH výsledek
// přepsat Bobův ephemerální klíč v paměti, již není potřeba
// Alice:
re = (všechny nuly)
// Bob:
e(public a private) = (všechny nuly)
// MixKey(DH())
Definujte temp_key = 32 byte
Definujte HMAC-SHA256(key, data) jako v [RFC-2104](https://tools.ietf.org/html/rfc2104)
// Generujte dočasný klíč z chaining klíče a DH výsledku
// ck je chaining klíč, z KDF pro zprávu 1
temp_key = HMAC-SHA256(ck, input_key_material)
// přepsat DH výsledek v paměti, již není potřeba
input_key_material = (všechny nuly)
// Výstup 1
// Nastavte nový chaining klíč z dočasného klíče
// byte() níže znamená jeden byte
ck = HMAC-SHA256(temp_key, byte(0x01)).
// Výstup 2
// Generujte šifrovací klíč k
Definujte k = 32 byte
// || níže znamená připojit
// byte() níže znamená jeden byte
k = HMAC-SHA256(temp_key, ck || byte(0x02)).
// h z zprávy 3 část 1 je použito jako asociativní data pro AEAD ve zprávě 3 část 2
// EncryptAndHash(payload)
// EncryptWithAd(h, payload)
// AEAD_ChaCha20_Poly1305(key, nonce, associatedData, data)
// n je 0
ciphertext = AEAD_ChaCha20_Poly1305(k, n++, h, payload)
// MixHash(ciphertext)
// || níže znamená připojit
h = SHA256(h || ciphertext);
// Zachovejte chaining klíč ck pro datovou fázi KDF
// Zachovejte haš h pro datovou fázi Additional Symmetric Key (SipHash) KDF
Konec "se" zpráva vzor.
// přepsat dočasný klíč v paměti, již není potřeba
temp_key = (všechny nuly)
3) SessionConfirmed
Alice odesílá Bobovi.
Noise obsah: Alicina statická klíč Noise payload: Alicina RouterInfo a náhodné padding Non-noise payload: žádné
(Bezpečnostní vlastnosti payloadu)
XK(s, rs): Autentizace Důvěrnost
-> s, se 2 5
Autentizace: 2.
Odesílatel autentizace odolná vůči key-compromise impersonation (KCI). Odesílatel
autentizace je založena na ephemerální-statickém DH ("es" nebo "se")
mezi odesílatelovým statickým klíčem párem a příjemcovým ephemerálním klíčem párem.
Předpokládající, že odpovídající soukromé klíče jsou bezpečné, tato autentizace nemůže být padělána.
Důvěrnost: 5.
Šifrování pro známého příjemce, silná forward sekrece. Tato payload je šifrována na základě
ephemerální-ephermerální DH jakož i ephemerální-statického DH s příjemcovým statickým klíčem párem.
Předpokládající, že ephemerální soukromé klíče jsou bezpečné, a příjemce není aktivně padělaný
útočníkem, který ukradl jeho statický soukromý klíč, tato payload nemůže být dešifrována.
"s": Alice zapisuje svou statickou veřejnou klíč z s proměnné do zprávy bufferu,
šifruje ji, a hašuje výstup spolu se starým h pro odvození nového h.
"se": DH je proveden mezi Aliciným statickým klíčem párem a Bobovým ephemerálním klíčem párem.
Výsledek je hašen spolu se starým ck pro odvození nového ck a k, a n je nastaven na nulu.
Toto obsahuje dva ChaChaPoly rámce. První je Alicina šifrovaná statická veřejná klíč. Druhý je Noise payload: Alicina šifrovaná RouterInfo, optional možnosti, a optional padding. Používají různé klíče, protože MixKey() funkce je volána mezi nimi.
Raw obsah:
+----+----+----+----+----+----+----+----+
| |
+ ChaChaPoly frame (48 bytes) +
| Encrypted and authenticated |
+ Alice static key S +
| (32 bytes) |
+ +
| k defined in KDF for message 2 |
+ n = 1 +
| see KDF for associated data |
+ +
| |
+----+----+----+----+----+----+----+----+
| |
+ Length specified in message 1 +
| |
+ ChaChaPoly frame +
| Encrypted and authenticated |
+ +
| Alice RouterInfo |
+ using block format 2 +
| Alice Options (optional) |
+ using block format 1 +
| Arbitrary padding |
+ using block format 254 +
| |
+ +
| k defined in KDF for message 3 part 2 |
+ n = 0 +
| see KDF for associated data |
~ . . . ~
| |
+----+----+----+----+----+----+----+----+
S :: 32 bytes, ChaChaPoly encrypted Alice's X25519 static key, little-endian
inside 48 byte ChaChaPoly frame
Nešifrovaná data (Poly1305 autentizační tagy nejsou zobrazeny):
+----+----+----+----+----+----+----+----+
| |
+ +
| S |
+ Alice static key +
| (32 bytes) |
+ +
| |
+ +
+----+----+----+----+----+----+----+----+
| |
+ +
| |
+ +
| Alice RouterInfo block |
~ . . . ~
| |
+----+----+----+----+----+----+----+----+
| |
+ Optional Options block +
| |
~ . . . ~
| |
+----+----+----+----+----+----+----+----+
| |
+ Optional Padding block +
| |
~ . . . ~
| |
+----+----+----+----+----+----+----+----+
S :: 32 bytes, Alice's X25519 static key, little-endian
Poznámky
Bob musí provést obvyklou Router Info validaci. Ujistěte se, že typ signatury je podporován, ověřte signaturu, ověřte, že timestamp je v rámci limitů, a další kontroly, které jsou nezbytné.
Bob musí ověřit, že Alicina statická klíč přijatá v prvním rámci odpovídá statickému klíči v Router Info. Bob musí nejprve vyhledat Router Info pro NTCP nebo NTCP2 Router Address s odpovídajícím verzí (v) možností. Viz sekce Publikované Router Info a Nepublikované Router Info níže.
Pokud Bob má starší verzi Aliciny RouterInfo ve své netdb, ověřte, že statický klíč v router info je stejný v obou, pokud je přítomen, a pokud starší verze je méně než XXX stará (viz klíč rotate čas níže)
Bob musí ověřit, že Alicina statická klíč je platný bod na křivce zde.
Možnosti by měly být zahrnuty, aby specifikovaly padding parametry.
Při jakékoli chybě, včetně AEAD, RI, DH, timestamp, nebo klíč ověření selhání, Bob musí zastavit další zpracování zprávy a ukončit připojení bez odpovědi. To by mělo být abnormální ukončení (TCP RST).
Pro rychlou handshaking, implementace musí zajistit, aby Alice bufferovala a poté vyprázdnila celý obsah třetí zprávy najednou, včetně obou AEAD rámců. To zvyšuje pravděpodobnost, že data budou obsažena v jednom TCP paketu (pokud nejsou segmentovány operačním systémem nebo middleboxy), a přijata najednou Bobem. To je také pro efektivitu a pro zajištění efektivity náhodného paddingu.
Zpráva 3 část 2 rámec délka: Toto je délka druhého AEAD rámce (včetně 16-byte MAC) obsahující Alicinu RouterInfo a optional padding, které budou odeslány ve SessionConfirmed zprávě. Jak routery pravidelně regenerují a republishují svou RouterInfo, velikost aktuální RouterInfo může změnit se před odesláním zprávy 3. Implementace musí zvolit jednu ze dvou strategií: a) uložit aktuální RouterInfo k odeslání ve zprávě 3, takže velikost je známa, a optional přidat prostor pro padding; b) zvýšit specifikovanou velikost dostatečně, aby umožnila možné zvýšení velikosti RouterInfo, a vždy přidat padding, když zpráva 3 je skutečně odeslána. V každém případě, “m3p2len” délka zahrnutá ve zprávě 1 musí být přesně velikost toho rámce, když odeslán ve zprávě 3.
Zpráva 3 část 2 rámec obsah: Formát tohoto rámce je stejný jako formát datových fází rámců, kromě toho, že délka rámce je odeslána Alicí ve zprávě 1. Viz tu zprávu pro důležité poznámky o umožnění dostatečného prostoru pro padding.
Zpráva 3 část 2 padding není vyžadováno, pokud Alice připojí datovou fázi rámec (optional obsahující padding) na konec zprávy 3 a odešle obě najednou, protože to bude vypadat jako jeden velký proud byte pro pozorovatele. Jako Alice obecně, ale ne vždy, má I2NP zprávu k odeslání Bobovi (to je důvod, proč se připojila k němu), toto je doporučená implementace, pro efektivitu a pro zajištění efektivity náhodného paddingu.
Celková délka obou Message 3 AEAD rámců (části 1 a 2) je 65535 byte; část 1 je 48 byte, takže část 2 maximální rámec délka je 65487; část 2 maximální plaintext délka (bez MAC) je 65471.
Funkce derivace klíče (KDF) (pro datovou fázi)
Datová fáze používá nulovou délku asociativního datového vstupu.
KDF generuje dva šifrovací klíče k_ab a k_ba z chaining klíče ck, používající HMAC-SHA256(key, data) jako definováno v RFC-2104 . To je Split() funkce, přesně jako definována v Noise specifikaci.
ck = z handshake fáze
// k_ab, k_ba = HKDF(ck, zerolen)
// ask_master = HKDF(ck, zerolen, info="ask")
// zerolen je nulová délka byte pole
temp_key = HMAC-SHA256(ck, zerolen)
// přepsat chaining klíč v paměti, již není potřeba
ck = (všechny nuly)
// Výstup 1
// šifrovací klíč, pro Alici odesílá Bobovi (Noise nemá j