La criptografía basada en la web es siempre humo de serpentario

Artículo original ↗ Discusión en Hacker News ↗

Argumento central: criptosistemas incoherentes y criptografía web

  • Afirmación central discutida: cualquier criptosistema es “incoherente” si la misma entidad distribuye el cliente y también opera el servicio frente al que se supone que protege, especialmente con autoactualizaciones.
  • En las aplicaciones web, el JavaScript y los service workers controlados por el servidor pueden cambiarse en cualquier momento, de modo que el proveedor puede eliminar o debilitar silenciosamente el cifrado para usuarios concretos.
  • Varios señalan que esto no solo aplica a aplicaciones web, sino también a mensajeros propietarios de “E2EE” y a apps móviles que se autoactualizan.

Confianza, actualizaciones y modelos de amenaza

  • Muchos comentarios subrayan: siempre tienes que confiar en quien te suministra el software; no puedes protegerte por completo contra que se vuelva malicioso o sea coaccionado.
  • Las autoactualizaciones (incluidos los clientes con “bomba de tiempo”) les dan de hecho a los proveedores ejecución remota de código y la capacidad de introducir puertas traseras de forma selectiva.
  • Otros enfatizan los modelos de amenaza: E2EE sigue siendo valioso frente a terceros, filtraciones masivas de datos y abusos internos, aunque no pueda defender contra el proveedor y su gobierno.

Valor de E2EE frente a TLS / afirmación de “humo de serpentario”

  • Los críticos del artículo dicen que llamar a la criptografía web “humo de serpentario” es exagerado e ignora beneficios reales:
    • Protege los datos en reposo frente a fugas de bases de datos y acceso casual o interno.
    • Eleva el listón frente a un simple compromiso de base de datos de solo lectura.
  • Quienes lo apoyan responden que, si el proveedor puede enviar silenciosamente un keylogger o un cargador de texto plano, afirmaciones como “no podemos leer tus mensajes” son, en el mejor de los casos, marketing condicional.

Ángulos legales, empresariales y gubernamentales

  • Algunos sostienen que E2EE también es una estrategia legal: desplazar la carga haciendo que cumplir órdenes de intervención de comunicaciones sea “imposible” en la práctica.
  • Otros ven incentivos reales de ingeniería (reducción de responsabilidad, prevención de abusos internos), aunque los escépticos cuestionan si superan los incentivos empresariales hacia la vigilancia o la cooperación con gobiernos.
  • Se debate la amenaza de los estados nación: algunos ven el E2EE basado en EE. UU. principalmente vulnerable ante agencias estadounidenses; otros dicen que eso es en gran medida académico para los usuarios típicos.

Mitigaciones y diseños alternativos

  • Mitigaciones sugeridas: código abierto, compilaciones reproducibles, distribución anónima, almacenamiento direccionado por contenido, atestación de código por terceros (por ejemplo, manifiestos al estilo WEBCAT, servicios externos de verificación de código) y protocolos con múltiples clientes independientes.
  • Varios señalan que estas prácticas son comunes en la distribución tradicional de software, pero raras en las aplicaciones web, lo que hace que el E2EE basado en la web sea especialmente frágil hoy en día.