P2P vs transferencia por servidor: ¿cuál es más seguro?

Ni la transferencia de par a par ni la basada en servidor son inherentemente más seguras: la seguridad depende del modelo de cifrado, no de la topología. Una transferencia por servidor bien implementada con cifrado AES-256-GCM de conocimiento cero es indistinguible de P2P en cuanto a confidencialidad: el servidor solo ve texto cifrado en ambos casos. P2P añade privacidad de metadatos (ningún tercero sabe que ocurrió una transferencia), pero introduce dificultades de disponibilidad, paso por NAT y autenticación. Los servicios basados en servidor gestionan mejor la fiabilidad y la comodidad del receptor. La respuesta honesta: elige según el modelo de amenaza y el entorno del receptor, no por la intuición teórica de que «P2P es más seguro».

Cómo funcionan realmente los dos modelos

La transferencia por servidor sube un archivo a un intermediario (almacenamiento de objetos respaldado por S3, OVH, Backblaze B2 o Cloudflare R2), devuelve un enlace, y el receptor descarga desde ese mismo intermediario. El archivo existe brevemente en un servidor que ninguna de las partes controla. Si el servidor usa cifrado de extremo a extremo, solo almacena texto cifrado.

La transferencia P2P establece una conexión directa entre emisor y receptor, generalmente mediante canales de datos WebRTC. El archivo nunca toca un servidor persistente — solo un servidor de señalización (para intercambiar información de conexión) y posiblemente un relay TURN para el paso por NAT. Ejemplos incluyen Wormhole.app (que en realidad usa un servidor con cifrado E2E), ToffeeShare, FilePizza y el BitTorrent clásico para compartición a gran escala.

La palabra «par a par» abarca un espectro. El P2P verdadero significa que el dispositivo del emisor se conecta directamente al del receptor. El P2P práctico con WebRTC a menudo cae en un relay TURN cuando falla la conexión directa, punto en el que se acerca más a una transferencia por servidor de corta duración.

La cuestión de la confidencialidad

Si ambos modelos usan AES-256-GCM con una clave que el servidor nunca ve, la confidencialidad es equivalente. El contenido del archivo no puede ser leído por nadie sin la clave en ninguno de los dos casos.

Lo que difiere son los metadatos. Una transferencia por servidor revela que «el usuario X subió un archivo de tamaño Y en el momento T, y el usuario Z lo descargó». Una transferencia P2P solo revela que dos direcciones IP se comunicaron brevemente — sin tamaño de archivo registrado centralmente, sin correlación temporal entre usuarios. Para modelos de amenaza donde los metadatos importan (periodismo de investigación, denuncia de irregularidades, activismo en contextos adversariales), la menor huella de metadatos del P2P es real.

Para el modelo de amenaza de «evitar que un archivo se filtre a un atacante», el servidor con cifrado E2E en el cliente es suficiente.

Asimetría de disponibilidad

La transferencia por servidor siempre está disponible dentro de su ventana de retención. Sube una vez, el receptor descarga en cualquier momento de los próximos 7 días desde cualquier dispositivo. El emisor puede cerrar su portátil, irse de vacaciones, lo que sea.

P2P requiere que ambas partes estén en línea simultáneamente (para conexión directa) o el uso de un relay que se convierte de todas formas en un servidor temporal. Si envías un archivo de 4 GB por WebRTC a un receptor cuyo portátil entra en suspensión al 20%, la transferencia falla. El receptor tiene que coordinarse contigo para reintentar.

Para flujos de trabajo asíncronos — un freelancer entrega archivos mientras el cliente duerme en otra zona horaria — la transferencia por servidor es simplemente más práctica.

La realidad del NAT y los cortafuegos

El paso por NAT de WebRTC usa ICE (Interactive Connectivity Establishment), STUN para descubrir IPs públicas, y TURN para redirigir cuando no es posible la conexión directa. Los cortafuegos corporativos, los NATs estrictos, el NAT de nivel de operador en redes móviles y el Wi-Fi de invitados a menudo bloquean o inutilizan WebRTC. En pruebas, las conexiones P2P fallan directamente o caen a TURN en aproximadamente el 15-20% de los intentos en el mundo real.

La transferencia por servidor usa HTTPS ordinario en el puerto 443. Funciona en cualquier lugar donde HTTPS funciona, que es en cualquier lugar donde funciona un navegador. Sin ICE, sin STUN, sin TURN, sin dramas con cortafuegos.

Comparativa directa

| Dimensión | Transferencia P2P (WebRTC) | Transferencia por servidor (E2EE) | |---|---|---| | Confidencialidad | Cifrado de extremo a extremo | Cifrado de extremo a extremo | | Fuga de metadatos | Baja (solo señalización) | Moderada (el servidor ve tamaños/tiempos) | | Comodidad del receptor | Ambas partes en línea | Descarga asíncrona | | Compatibilidad NAT/cortafuegos | Puede fallar 15-20% | Funciona donde HTTPS funciona | | Tamaño práctico máximo | Ilimitado en teoría, frágil a escala | Según el servicio (2-50 GB gratuito) | | Soporte de reanudación | Poco frecuente | Estándar (tus.io, chunked) | | Múltiples receptores | Reenviar a cada uno | Un enlace, muchas descargas | | Coste del servidor | Mínimo (solo señalización) | Almacenamiento + ancho de banda | | Supuesto de confianza | Confiar en el código del cliente WebRTC | Confiar en la implementación E2EE |

Dónde P2P gana genuinamente

Transferencias grandes y puntuales entre dos personas técnicamente capaces en la misma zona horaria con redes cooperativas. Un desarrollador que envía un .iso de 50 GB a un colega, ambos en fibra doméstica, ambos con los navegadores abiertos — P2P termina en el tiempo que tardan en saturar sus enlaces de subida, con coste de servidor cero.

Los escenarios sensibles a los metadatos se benefician de P2P. Un periodista que recibe archivos de una fuente confidencial gana algo al no tener un servidor de terceros que registre la transferencia. Incluso con cifrado E2EE en un servidor, la existencia y el tamaño de la transferencia quedan registrados.

La distribución estilo BitTorrent de un archivo a miles de receptores es un caso de uso P2P aparte donde el modelo escala elegantemente — la carga de ancho de banda se distribuye por el enjambre. No es relevante para las transferencias típicas de 1 a 1 o 1 a pocos, pero merece mencionarse.

Dónde la transferencia por servidor gana

En casi todas las entregas ordinarias de archivos. El emisor sube una vez y se va. El receptor descarga a su ritmo. La transferencia funciona desde cualquier red, incluyendo Wi-Fi de hotel y datos móviles. Varios receptores obtienen el mismo enlace. La retención es automática. Existen pasarelas de pago y soporte.

La transferencia por servidor también gana en fiabilidad. Una subida de 3 GB que falla al 2,8 GB se reanuda desde el 2,8 GB en un servidor que usa subidas fragmentadas con tus.io. Una transferencia P2P que falla al 2,8 GB normalmente reinicia desde cero — las implementaciones de WebRTC basadas en navegador rara vez guardan el progreso.

La afirmación de marketing del «sin servidor»

Algunas herramientas P2P afirman que «tus archivos nunca tocan nuestros servidores». Esto solo es parcialmente exacto. Los servidores de señalización intercambian ofertas SDP y candidatos ICE — no el archivo en sí, pero suficientes metadatos para establecer la conexión. Los relays TURN (cuando se usan) transportan brevemente el flujo de archivo cifrado a través de la infraestructura del proveedor.

Mientras tanto, una transferencia por servidor con conocimiento cero bien implementada y AES-256-GCM en el lado del cliente puede hacer la misma afirmación funcional: «nuestros servidores nunca ven el contenido de tu archivo». El texto cifrado pasa por el almacenamiento, pero el texto en claro solo existe en los dispositivos del emisor y del receptor.

La distinción entre «los bits del archivo no transitan por nuestra infraestructura» y «no podemos descifrar lo que transita por nuestra infraestructura» es real, pero a menudo menor de lo que el marketing implica.

Autenticación y verificación del receptor

Ninguno de los dos modelos resuelve automáticamente la autenticación del receptor. Ambos suelen basarse en «quien tenga el enlace puede recibir el archivo», opcionalmente reforzado con una contraseña. La autenticación verdadera del receptor (¿recibió realmente Alice este archivo y no alguien que interceptó su email con el enlace?) requiere canales fuera de banda — compartir la contraseña por Signal, confirmar la recepción por teléfono.

Los servicios de servidor facilitan esto con notificaciones de descarga (el emisor recibe un webhook o email cuando se usa el enlace). P2P puede ofrecer algo similar a través de la interfaz del emisor, pero solo durante la sesión.

La calidad de implementación importa más que la topología

Una herramienta P2P descuidada que usa ECDH sin intercambio de claves autenticado pierde frente a una herramienta basada en servidor cuidadosa que usa X25519 con certificados de par verificados. Una herramienta de servidor que usa AES-128 en modo CBC pierde frente a una herramienta P2P que usa AES-256-GCM. La topología es menos importante que hacer bien la criptografía.

HexaTransfer usa AES-256-GCM en el lado del cliente con claves en fragmentos de URL, TLS 1.3 para el transporte, y almacenamiento en servidor que solo guarda texto cifrado — una topología de servidor con las propiedades de confidencialidad de P2P para el contenido de los archivos.

Conclusión

La ventaja de seguridad del P2P se refiere principalmente a la privacidad de los metadatos, no a la confidencialidad de los archivos. Para la mayoría de los usuarios — freelancers, pequeñas empresas, creativos que entregan activos a clientes — la transferencia por servidor con cifrado de conocimiento cero gana en fiabilidad, comodidad y compatibilidad sin pérdida significativa de confidencialidad. P2P tiene sentido cuando la privacidad de los metadatos es un requisito estricto o cuando ambas partes están en línea simultáneamente y el archivo es demasiado grande para el nivel gratuito de un servidor.

Pruébalo en hexatransfer.com — gratis, sin cuenta, hasta 10 GB.