Découverte des noeuds et livraison chiffrée vérifiable

AeroNyx19 juin 20263 min de lecture59 vues

Comment les noeuds AeroNyx découvrent des peers signés, choisissent un chemin réseau diversifié à deux sauts, relaient un ChatRelay opaque et vérifient la livraison terminale par reçu signé.

Le 17 juillet 2026, un smoke test de production a envoyé un ChatRelay opaque d'un client authentifié depuis US1, via Korean1, jusqu'à Noway1. Le terminal l'a écrit dans le pending store et a renvoyé un reçu signé vérifié par la source. C'est une preuve limitée pour un chemin ChatRelay éligible, pas l'affirmation que tous les paquets AeroNyx utilisent onion routing.

Invariant du protocole: L'infrastructure relay ne doit recevoir ni texte clair ni clé de déchiffrement. Le middle ne traite que des route metadata bornées, proof, TTL, next hop et ciphertext opaque; le terminal reçoit uniquement le minimum requis pour store-and-forward avec le ciphertext.

Ce qui fonctionne actuellement

Peer descriptors signés, peer store persistant, gossip, reachability probes, préférence des routes avec receipt, client sessions authentifiées, terminal pending store et delivery receipts signés fonctionnent en production.

Flux de livraison authentifiée

  1. Le client établit une session avec Ed25519 et X25519 éphémère puis envoie ChatRelay dans un DataPacket chiffré. La source lie sender à session identity et choisit middle/terminal diversifiés. Elle ne compte la livraison qu'après vérification d'un receipt lié à route, au payload commitment exact, au terminal attendu et à freshness.
text
authenticated client -> source -> middle -> terminal pending store
                                  <- terminal-signed receipt <-

Le receipt terminal est lié au route ID, au payload commitment exact, à l'identité terminale attendue et à la fenêtre de freshness. Un receipt différent ou périmé est rejeté.

Niveaux de preuve

Trois niveaux restent séparés afin qu'un health check ne soit pas présenté comme une livraison réelle:

Code de preuveSignification
synthetic_onion_message_delivery_probeProbe contrôlé du chemin, pas du trafic utilisateur réel.
opaque_relay_acceptanceAcceptation d'un relay chiffré origin-neutral; elle ne prouve pas la livraison terminale.
verified_client_onion_delivery_receiptLe payload authentifié a atteint le terminal attendu et la source a vérifié son reçu.

Diversité des routes

Source, middle et terminal doivent être distincts. Même IPv4 /24, IPv6 /48 ou DNS host normalisé est refusé; un endpoint incorrect échoue fermé. La diversité ASN et propriétaire n'est pas encore implémentée.

Compatibilité inter-versions

Les routes receipt-capable sont prioritaires. Les anciens peers peuvent servir de fallback limité, mais sans receipt valide ils n'augmentent jamais verified_client_onion_deliveries et ne sont pas affichés comme livraison vérifiée.

Contrat de l'API publique

La card directe d'un noeud est disponible via GET http://<node>:8422/api/discovery/public-card, et l'agrégat privacy-safe via GET https://api.aeronyx.network/api/privacy_network/vpn/public/network-stats/. L'ancien segment vpn reste uniquement pour compatibilité; le produit est AeroNyx Privacy Protocol.

json
{
  "real_relay_ready": true,
  "verified_client_onion_deliveries": 1,
  "verified_client_onion_delivery_age_seconds": 42,
  "message_delivery_proof_ready": true,
  "message_delivery_ready": true,
  "message_delivery_evidence_mode": "verified_client_onion_delivery_receipt"
}

Limite de confidentialité

L'API publique expose seulement readiness, compteurs et âge de preuve agrégés, jamais route ID, endpoints, clés, payloads, adresses, destinations, DNS ou social graph. Le contenu reste aveugle, mais la résistance à l'analyse globale ou l'anonymat de niveau Tor ne sont pas encore prouvés.

Limites actuelles

  • La vérification couvre seulement ChatRelay authentifié éligible sur deux sauts, pas tous les paquets, voice ou media. verified_client_onion_deliveries est un signal process-local réinitialisé au restart, pas un total historique ni un consensus global.

Libellés produit

Seul verified_client_onion_delivery_receipt s'affiche comme Verified client delivery; opaque_relay_acceptance comme Encrypted relay active et synthetic_onion_message_delivery_probe comme Path probe passed. Ces états ne doivent pas être fusionnés.

Documentation associée