Descubrimiento de nodos y relé cifrado multisalto

Los nodos de AeroNyx se encuentran entre sí mediante descriptores firmados y con caducidad, y pueden reenviar cargas útiles cifradas de extremo a extremo salto a salto, de modo que cada relé quita solo su propia capa de cifrado. Hoy, el chat real de los usuarios pasa de forma predeterminada por el relé central de AeroNyx (RelayWS). Enrutar el chat a través de nodos es un ajuste opcional de la aplicación.

Qué funciona hoy

Las rutas centralizadas y descentralizadas funcionan en paralelo.

Cómo funciona el descubrimiento

Cada nodo publica un descriptor firmado con su clave de identidad Ed25519. Un descriptor incluye el ID del nodo, las horas de emisión y de caducidad, un endpoint público opcional, indicadores de capacidad (como relé cebolla intermedio o relé de chat), indicaciones aproximadas de capacidad y la clave usada para el cifrado cebolla. Los nodos rechazan los descriptores caducados o que llevan una firma no válida.

• La difusión está acotada. El intercambio entre pares tiene límite de frecuencia y está sujeto a políticas, y los mensajes tienen límites de tamaño.
• Recuperación tras un reinicio. Un nodo mantiene una caché local de pares y, tras un reinicio, recurre a los endpoints semilla configurados. Los operadores también pueden fijar semillas (véase la sección sobre semillas fijadas).
• Selección de rutas. Solo los descriptores recientes con un endpoint utilizable y una clave cebolla se consideran candidatos a relé.

Qué endpoints puede indicar un descriptor

Una firma demuestra quién publicó un descriptor, no que su endpoint sea seguro de contactar. Por tanto, un nodo solo acepta dos formas de endpoint:

• una dirección IP pública sobre http o https; se rechazan los rangos de loopback, privados, de enlace local, CGNAT, de documentación, de multidifusión y reservados;
• una URL https:// con un nombre DNS público. Se rechazan los nombres de una sola etiqueta, localhost y los sufijos privados como .local, .internal y .home.arpa.

Los nombres de host se resuelven en el momento de la conexión mediante un resolvedor que descarta toda dirección no pública, de modo que un nombre no puede apuntar al propio nodo, a una red privada ni a un servicio de metadatos en la nube. Los clientes de pares también ignoran la configuración de proxy y nunca siguen redirecciones.

La forma con nombre de host existe para que puedan participar los nodos que no tienen una dirección IP propia, como un nodo TEE detrás de una pasarela en la nube.

Semillas fijadas

Un nodo que arranca sin una instantánea del operador solo confía en las identidades que ya posee, por lo que puede acabar confiando únicamente en sí mismo. Para ese caso, un operador puede indicar la identidad esperada en una dirección:

[discovery]
pinned_seeds = ["<64-hex node id>@<public ip>:<port>"]

• Una identidad fijada se acepta por primera vez solo tras un intercambio por TLS ligado a la identidad fijado a esa identidad.
• Todo descriptor posterior de una identidad fijada, de cualquier origen, debe mantener la dirección fijada y anunciar TLS ligado a la identidad.
• La confianza no se transmite: los demás descriptores de la respuesta de una semilla siguen siendo candidatos no confiables.
• Una fijación eliminada no puede volver desde una caché o una copia de seguridad antiguas.

La Directory Chain

Cada nodo mantiene además un historial firmado y enlazado por hash de sus propios eventos de descriptor, llamado su Directory Chain. Otros nodos pueden replicar ese historial, obtener objetos descriptor y solicitar pruebas de inclusión para un descriptor concreto. Los pares fijados por el operador pueden firmar puntos de control de observación sobre los historiales que han visto.

No hay un registro global ni un coordinador único: cada nodo firma su propio historial, y los demás lo replican y lo comprueban.

TLS ligado a la identidad

Para llegar a un nodo por HTTPS normalmente hacen falta un nombre de dominio y un certificado de una autoridad de certificación, y la mayoría de los nodos de AeroNyx solo son accesibles por dirección IP. En su lugar, un nodo demuestra su propio endpoint HTTPS con su identidad Ed25519.

• Cómo funciona. El nodo crea una clave TLS ECDSA P-256 ordinaria y un certificado autofirmado. Un nombre alternativo del sujeto lleva un vínculo, aeronyx-tls-binding:v1:<node id>:<expiry>:<signature>, donde la firma la hace la clave de identidad del nodo sobre un resumen con separación de dominio de la clave pública del propio certificado, el ID del nodo y la caducidad. El handshake TLS 1.3 demuestra que el nodo posee la clave del certificado. La clave de identidad nunca firma un handshake.
• Qué comprueba un cliente. Un verificador acepta un certificado solo para el nodo al que pretendía llegar: exactamente un vínculo, el ID de nodo esperado, sin caducar, con como máximo 31 días de validez restantes y una firma válida sobre la clave de este certificado. Un certificado emitido por una autoridad de certificación no cumple esta comprobación.
• El mismo puerto. El puerto público de la API (8422/TCP) sirve ambos: una conexión que empieza con un handshake TLS recibe TLS, y cualquier otra recibe HTTP sin cifrar como antes. Está activado de forma predeterminada (discovery.public_api_identity_tls).
• Entre nodos. Un nodo cuyo descriptor firmado anuncia la función de protocolo anpf1-ibt1 sirve TLS ligado a la identidad. Un par que ve esa función debe llegar a ese nodo por TLS fijado a su identidad y nunca recurre a HTTP sin cifrar. La función está cubierta por la firma del descriptor, de modo que un atacante de red no puede eliminarla para forzar una degradación. Si varias identidades reclaman el mismo endpoint, no se produce ninguna dirección TLS y la solicitud falla de forma cerrada. Los nodos antiguos sin la función, y los endpoints de pasarela con nombre DNS, mantienen su comportamiento anterior.
• Referencia. Código fuente y vectores de prueba congelados: aeronyx-node-tls.

El efecto es que la información de ruta de los saltos cebolla, la difusión, la sincronización del directorio y el tráfico de testigos entre nodos ya no es legible en la red. La compatibilidad de la aplicación para conectarse a los nodos de este modo está en desarrollo.

Cómo funciona el relé multisalto

1. El remitente envuelve la carga útil en una capa de cifrado por cada salto, usando la clave cebolla publicada de cada relé.
2. Cada relé comprueba la firma, la marca de tiempo y el estado antirrepetición del salto anterior, quita su propia capa y reenvía el bloque opaco restante. Nunca ve las capas interiores.
3. El nodo final (terminal) entrega el mensaje a la bandeja de entrada del relé del receptor (de forma predeterminada, el relé central) y, solo después de que el relé lo acepte, devuelve un acuse de recibo firmado. El acuse vincula el ID de la ruta, un compromiso con la carga útil, la identidad del nodo terminal y la hora de entrega. Demuestra que el mensaje fue aceptado bajo custodia del relé, no que el receptor lo haya leído. Un nodo con el traspaso desactivado conserva el mensaje en su propio almacén y firma el mismo tipo de acuse, por lo que el acuse por sí solo no distingue entre ambos casos.

Qué ve cada parte

Ningún nodo por sí solo vincula su dirección de red con la persona a la que usted escribe. El nodo terminal y el relé central ven ambos quién escribió a quién.

El protocolo acepta como máximo tres saltos de relé verificados. La ruta de privacidad de la aplicación usa dos. Los límites contra abusos en los relés se describen en Protección contra abusos del relé ciego.

El chat en la aplicación

• Predeterminado: los mensajes pasan por el servicio central RelayWS. El contenido de los mensajes está cifrado de extremo a extremo, pero el servicio gestiona los metadatos de entrega. Consulte Integración de clientes con el relé de chat.
• Ruta de privacidad (opcional, desactivada de forma predeterminada): cuando está activada y hay una ruta lista, la aplicación envía primero los mensajes individuales por la ruta cebolla de dos saltos. Si ninguna ruta cebolla acepta el mensaje, la aplicación lo retiene en el dispositivo y no usa el relé estándar a menos que usted lo apruebe para ese mensaje.
• Buzón anónimo (beta): un depósito independiente que solo funciona mientras se está conectado a la red de privacidad. Las conversaciones ordinarias no lo usan.

Tamaños de las respuestas de recogida del buzón anónimo

Antes, el resultado de una recogida del buzón era una única imagen fija de 163.130 bytes, fuera cual fuese el elemento, de modo que un mensaje corto costaba una respuesta de unos 160 KiB. La versión 2 de la recogida, negociada mediante la función de protocolo firmada anpf1-ampc1, rellena el elemento sellado hasta la menor de cinco clases de tamaño (4.204, 16.492, 65.644 o 131.180 bytes, o el máximo del códec). Un elemento de 4.096 bytes ahora viaja como 4.518 bytes.

Nodo TEE

Un nodo de producción se ejecuta dentro de un entorno de ejecución de confianza de Phala Cloud (dstack sobre Intel TDX). Solo funciona como buzón anónimo y relé cebolla: su VPN está deshabilitada, MemChain está desactivado y su clave de identidad procede del servicio de claves de dstack. Solo es accesible mediante un nombre de host TLS en la pasarela, y por eso se añadieron los endpoints con nombre de host. Actualmente la aplicación no verifica la atestación TEE del nodo.

Estado en vivo

El estado agregado de la red se publica en:

GET https://api.aeronyx.network/api/privacy_network/vpn/public/network-stats/

Los agregados de relé y de descubrimiento aparecen bajo data.protocol_status, por ejemplo peer_store.blind_relay y peer_store.peer_quorum. Tenga en cuenta dos aspectos al leerlos:

• Los agregados a nivel de nodo cuentan solo los nodos con un latido en los últimos 120 segundos, de modo que un nodo fuera de línea desaparece de recuentos como protocol_status.reported_nodes. network.total_nodes y network.vpn_nodes siguen contando los nodos activos registrados, estén en línea o no.
• Los contadores de sondas sintéticas (probe_*, two_hop_probe_*) miden el estado de las rutas. No son tráfico de usuarios.

La respuesta pública solo contiene recuentos, categorías de estado y marcas de tiempo. Nunca incluye ID de nodo, endpoints, ID de ruta, cargas útiles, destinatarios, direcciones IP de clientes, datos DNS ni aristas del grafo social. Consulte Estadísticas de la red y límite de privacidad.

Preguntas frecuentes

¿Mis mensajes de chat de AeroNyx pasan por nodos descentralizados?

No de forma predeterminada. Los mensajes pasan por el servicio central RelayWS. Puede activar la ruta de privacidad en la aplicación, que envía los mensajes individuales por una ruta cebolla de dos saltos a través de nodos cuando hay una lista. Si ninguna ruta acepta un mensaje, la aplicación lo retiene hasta que haya una ruta disponible o hasta que usted apruebe enviar ese mensaje por el relé estándar.

¿Puede un nodo relé leer los mensajes que reenvía?

No. Un relé quita solo su propia capa de cifrado y reenvía un bloque opaco. Además, el contenido de los mensajes está cifrado de extremo a extremo entre las personas de la conversación.

¿Qué es la Directory Chain?

La Directory Chain es el historial propio de cada nodo, firmado y enlazado por hash, de sus descriptores. Otros nodos lo replican y pueden solicitar pruebas de inclusión. No tiene un coordinador global.

¿Cómo puede unirse a la red un nodo que está detrás de una pasarela?

Puede publicar un nombre de host https:// como su endpoint. Los demás nodos resuelven ese nombre en el momento de la conexión y solo usan direcciones públicas, por lo que el nombre no puede redirigirse a destinos privados o internos.

¿Por qué la página de estadísticas públicas muestra más nodos registrados que nodos en línea?

network.total_nodes y network.vpn_nodes cuentan los nodos activos registrados estén o no en línea. Compárelos con network.online_vpn_nodes. Los recuentos de protocolo y reenvío solo incluyen nodos con un latido reciente.

¿Los nodos necesitan un nombre de dominio o una autoridad de certificación para HTTPS?

No. Un nodo puede demostrar su endpoint HTTPS con su propia clave de identidad: su certificado TLS lleva una firma de la identidad del nodo sobre la clave del certificado, y un cliente o par que conoce el ID del nodo puede verificarla. Los nodos detrás de una pasarela pueden seguir usando un nombre de host https:// en su lugar.

¿Qué demuestra un acuse de entrega firmado?

Demuestra que el nodo terminal aceptó el mensaje bajo custodia del relé, en la práctica la bandeja de entrada del relé del receptor. No demuestra que el receptor haya visto o leído el mensaje. Para eso se usan los acuses de entrega y de lectura del protocolo de chat.