Reticulum profilis ir siūloma architektūra

3. Reticulum NET technologinis profilis

Reticulum Network Stack yra atskiras tinklo stekas, kuris nepriklauso nuo IP kaip būtino pagrindo, tačiau gali būti tuneliuojamas per TCP, UDP, privatus IP tinklus arba internetą. Jis gali veikti per Ethernet, Wi-Fi, LoRa/RNode, Packet Radio TNC, serial sąsajas, I2P, stdio/pipes ir Python pagrindu kuriamas pasirinktines sąsajas. Tai reiškia, kad Reticulum NET tinka scenarijams, kuriuose reikia sujungti skirtingas fizines terpes ir sumažinti priklausomybę nuo tradicinės infrastruktūros.

RNS naudoja „destinations“ modelį vietoje tradicinių IP adresų ir portų. Destinations yra 16 baitų SHA-256 santraukos iš identifikuojančių charakteristikų, o SINGLE destinacijos papildomai pririšamos prie viešojo rakto. Todėl postkvantinę tapatybės ir sesijos politiką reikia aiškiai susieti su RNS destination hash, bridge identity ir pasirinktų algoritmų rinkiniu.

Kriptografiniu požiūriu Reticulum pagal nutylėjimą šifruoja duomenis naudojant X25519, Ed25519, Curve25519 ECDH pagrindu išvedamus per-link ephemeral raktus ir AES-256-CBC su HMAC-SHA256. Architektūra yra praktiška ir efektyvi dabartinei gręsmių aplinkai, bet PQC migracijos požiūriu turi būti laikoma klasikine.

3.1. Reticulum galimybių matrica

Septynios techninės galimybės, kurios tiesiogiai įtakoja PQC Bridge dizainą: terpių įvairovė, multi-hop, klasikinis šifravimas, MDU, sesijų mechanizmai, vartų vieta ir pasirinktiniai adapteriai.

Galimybė	Reikšmė Reticulum NET	Vertė PQC Bridge	Pastaba
Heterogeniškos terpės	LoRa, Ethernet, Wi-Fi, TCP/UDP, I2P, serial, KISS/AX.25 ir pasirinktinės sąsajos.	Leidžia testuoti PQC ne tik IP tinkle, bet ir degradavusios infrastruktūros scenarijuose.	Tinka krizių ryšiui ir edukaciniams demonstratoriams.
Savikonfigūruojamas multi-hop	Automatiškai atranda topografiją ir maršrutus.	Bridge nesirūpina IP maršrutizavimu, bet sieja kriptografinę sesiją su pasirinktu keliu.	Reikia matuoti path discovery laiką ir klaidas.
End-to-end klasikinis šifravimas	ECC pagrindu forward secrecy.	Geras bazinis sluoksnis, bet nesprendžia PQC gręsmės.	Negalima dokumentuoti kaip PQC-ready be papildomo sluoksnio.
Mažas pralaidumas	Minimumas 5 bitų/s, dokumentuotas API.	Leidžia tyrinėti PQC handshake kainą LoRa/radio ryšyje.	ML-KEM paketai gali lemti fragmentaciją.
Nuoroda / Ištekliai / Kanalas	Sesijos, patikimas perdavimas, didesnių duomenų skaidymas.	Rekomenduojamas transportas PQC handshake ir politikos pranešimams.	Vieno paketo režimas netinka pilnam handshake.
Transporto mazgas / šliuzas (gateway)	Jungia vietinį segmentą su platesniu RNS tinklu.	Natūrali vieta PQC Bridge vartų funkcijai ir saugumo domenų atskyrimui.	Tinka laboratoriniam pilotui.
Individualizuotos sąsajos moduliai	Python plečiamos sąsajos.	Galima kurti KME/QKD, SDR, optinių ar kitų terpių adapterius.	Reikia valdyti supply chain ir testuoti saugumą.
Vieši ar privatūs entrypoint	Magistralinė linija/TCP įėjimo taškai.	PQC Bridge gali veikti virš privataus RNS backbone tarp institucijų.	TCP metaduomenis reikia valdyti papildomai.

5. Siūloma architektūra

Rekomenduojama architektūra yra sluoksninė. Reticulum veikia kaip atsparus transportas, o PQC Bridge veikia virš jo arba saugumo domenų vartuose. Tokiu būdu išlaikomas suderinamumas su Reticulum ekosistema ir kartu sukuriamas kriptoagilus postkvantinis apsaugos sluoksnis. Pirmajame etape nerekomenduojama keisti Reticulum protokolo branduolio — tai sukeltų wire-format, API, suderinamumo ir auditavimo riziką.

PQC Bridge turi būti projektuojamas kaip aiški saugumo funkcija su savo tapatybe, algoritmų rinkiniu, KDF politika, atšaukimo mechanizmu ir žurnalais. Jis gali būti realizuojamas dviem pagrindiniais būdais:

• Aplikacinis envelope — kiekviena programa supakuoja duomenis į PQC apsaugotą formatą prieš siunčiant per RNS.
• Vartai (gateway) / tiltas (bridge) paslauga — du saugumo domenai turi Reticulum vartus, atliekančius postkvantinį raktų sudarymą ir pranešimų apsaugą.

5.2. Modelis

Šeši loginiai sluoksniai — nuo fizinių sąsajų iki aplikacijos — ir kaip kiekvienas jų sujungtas su PQC Bridge sprendimu.

Sluoksnis	Funkcija	PQC Bridge sprendimas
Aplikacijos sluoksnis	Žinutės, failai, komandos, telemetrija, valdymo pranešimai.	PQC envelope, AEAD, raktų rotacija, anti-replay, politika ir auditavimas.
PQC Bridge sluoksnis	Postkvantinis raktų sudarymas, pasirašymas, KDF, raktų gyvavimo ciklas.	ML-KEM, ML-DSA / SLH-DSA, suite_id, CBOM, logai, KME adapteris.
Reticulum Link / Resource / Channel	Patikimas perdavimas per RNS, didesnių pranešimų skaidymas, forward secrecy klasikiniu pagrindu.	Naudojamas PQC rankos paspaudimui, ciphertext ir politikos pranešimams perduoti.
Reticulum transportas	Savikonfigūruojamas multi-hop, destination modelis, transport nodes.	Bridge susieja sesiją su RNS destination, transport hash ir kelio metrika.
Fizinės ir loginės sąsajos	LoRa/RNode, TCP/Backbone, Wi-Fi, Ethernet, I2P, serial, custom interfaces.	Matuojamas payload overhead, handshake trukmė, patikimumas, tinkamumas terpėms.
Pasirinktinis QKD / KME sluoksnis	QKD raktų generavimas ir pristatymas aplikacijoms per KME.	QKD raktas sujungiamas su ML-KEM paslaptimi per KDF, laikantis KME saugumo ribų.

5.3. Hibridinio rakto sudarymas

Minimalus PQC Bridge modelis turi sudaryti sesijos raktą iš ML-KEM paslapties ir aiškaus konteksto. Hibridiniame variante įtraukiamas Reticulum klasikinės sesijos kontekstas arba atskiras X25519 komponentas, o QKD variante — KME pateiktas raktas su key_id.

Svarbu nenaudoti „paprasto suklijavimo“ kaip neapibręžtos saugumo praktikos — turi būti naudojama standartizuota arba saugumo peržiūrą praėjusi KDF/secret combiner konstrukcija su domenų atskyrimu, versijomis ir protokolo transkripto pririšimu. NIST SP 800-227 apibrężia KEM saugaus naudojimo rekomendacijas, IETF RFC 9794 nustato hibridinių schemų terminiją.

5.4. QKD/KME adapterio vieta

QKD integraciją racionaliausia realizuoti kaip pasirenkamą KME adapterį, o ne kaip privalomą Reticulum funkciją. ETSI GS QKD 014 apibrężia REST pagrindu veikiantį raktų pristatymo API tarp Secure Application Entity (SAE) ir Key Management Entity (KME) — HTTPS, JSON, key ID, Master/Slave SAE logika ir prielaida, kad API naudojamas saugumo riboje kiekvienoje svetainėje.

Tokia architektūra atitinka vartų modelį: PQC Bridge vienoje svetainėje veikia kaip SAE, gauna key_id ir rakto medžiagą iš KME, perduoda key_id kitai pusei per RNS, o kita pusė gauna identišką raktą iš savo KME. ETSI darbo programoje GS QKD 014 v1.3.1 yra stabilaus projekto stadijoje — pilotui būtina aiškiai nurodyti, kuri API versija naudojama.

{
  "version": "ret-pqc-bridge-0.1",
  "suite_id": "RNS-PQC-MLKEM768-MLDSA65-AESGCM256-HKDFSHA256",
  "sender_bridge_id": "bridge-A",
  "receiver_bridge_id": "bridge-B",
  "rns_destination_hash": "<16-byte-destination-hash>",
  "handshake_id": "random-128-bit-id",
  "nonce": "random-96-or-192-bit-value",
  "mlkem_public_key_or_ciphertext": "bytes-base64",
  "optional_qkd_key_id": "uuid-or-null",
  "transcript_hash": "sha256-or-sha3-256",
  "policy": {
    "fallback": "fail_closed",
    "key_lifetime_seconds": 3600,
    "replay_window": 64
  },
  "ciphertext": "bytes-base64",
  "tag": "bytes-base64",
  "signature": "ML-DSA-or-SLH-DSA-signature"
}