¿Por qué los métodos de cifrado son elegidos por lo que no se rompe en lugar de lo que es posible?

La respuesta simple es que no es tan simple.

Hay varias razones para esto.

Primero, abordemos la noción de:

  

"¿Qué no está roto, en lugar de lo que es posible?"

Fuera de la información, los algoritmos teóricamente seguros, todos los algoritmos entran en la categoría de "aún no está roto" para alguna noción de seguridad semántica. Esto incluye clases completas de sistemas para los cuales no tenemos (en uso hoy en día) reemplazos resistentes a cuántica, como algoritmos asimétricos para firmas digitales e intercambio de claves en TLS. No es que no existan algoritmos resistentes cuánticos para problemas como el intercambio de claves y las firmas ... Simplemente no hemos descubierto cómo podemos usarlos prácticamente todavía, y en los casos incluso hemos investigado lo suficiente como para asegurarnos de que son razonables. seguro. De modo que "lo que es posible" es más académico que práctico, incluso en el mundo de los sistemas de hiperescala.

En esa nota, el rendimiento. Incluso en el mundo de los sistemas de hiperescala, el rendimiento es crítico, incluso para los jugadores más grandes. Google, por ejemplo, está constantemente buscando formas de ahorrar milisegundos y aumentar la cantidad de sesiones simultáneas que pueden atender, y ellos (y todos los demás) deben preocuparse no solo de sus propios servidores, sino también del hardware que el cliente tiene en la red. otro extremo, que puede ser una computadora portátil moderna o una computadora de escritorio de gama baja de 15 años, o un teléfono inteligente, o un teléfono con funciones de ocho años con un navegador web básico, o para sistemas no web, una baja - dispositivo incrustado de energía, o una tarjeta inteligente con casi ningún recurso informático en absoluto.

En esa nota, compatibilidad. Incluso en los procesadores x64 modernos más modernos, el software puede manejar fácilmente cualquier algoritmo que se les presente, como Matija señaló en otro Responda puede implementar algoritmos en un sistema criptográfico que los consumidores de esos sistemas no puedan entender.

Consideraciones adicionales señaladas por SEJPM en un comentario es certificación y política. Algunos implementadores de sistemas ni siquiera tienen una opción en los algoritmos. Un sistema certificado por FIPS, por ejemplo, solo puede implementar los algoritmos de FIPS. Y no cualquier aplicación de esos algoritmos servirá ... La implementación en sí misma debe contar con la certificación FIPS. Muchos sistemas del gobierno de los Estados Unidos tienen este requisito. Los sistemas rusos, por otro lado, pueden ser requeridos para implementar su propio algoritmo estándar, GOST. Entonces, incluso en los senarios donde existen mejores algoritmos (y para FIPS, esta es una realidad, no una teoría) no son una opción por razones regulatorias.

Para resolver todos estos problemas, tenemos una variedad de opciones, y todas esas opciones tienen varios beneficios e inconvenientes, y para un uso específico tenemos que considerar cuidadosamente las compensaciones que hacen que la elección de las "más opción "segura", ya menudo imposible de medir sin recurrir a la opinión individual sobre el impacto de esas compensaciones. Y, como hemos visto, debido a los requisitos de rendimiento y compatibilidad, la seguridad en sí misma is es una compensación válida para producir un sistema completo que funcione de manera nominalmente óptima. bien.

En resumen, compatibilidad. Claro, puede seleccionar solo los cifrados más seguros en solo el TLS más reciente y estar seguro durante un período de tiempo más largo. Sin embargo, la mitad de las personas en Internet no podrían comunicarse con usted en ese momento.

Puede estar bien para usted (por ejemplo, en servidores que uso exclusivamente para mí, hago exactamente eso). Para otros usos, perder incluso algunos porcentajes de clientes (como los que siguen utilizando Windows XP no admitidos, por ejemplo) es inaceptable, y soportar una cifra más débil por un tiempo más es una solución que se debe utilizar, incluso si más trabajo.

Me da la impresión de que no has interiorizado estos principios:

1. La seguridad tiene que ver con el riesgo frente al intercambio de costos, y estos intercambios varían entre usuarios y aplicaciones.
2. Un sistema de seguridad no es más fuerte que su vínculo más débil, y el cifrado obsoleto a menudo no es el vínculo más débil.

Para usar un ejemplo que otros mencionaron, si un minorista en línea restringe los paquetes de cifrado aceptados de su servidor HTTPS público, renunciará a los ingresos de los clientes que usan software obsoleto. Aquí se debe emitir un juicio.

Otra consideración: actualizar el software antiguo para usar la nueva criptografía es costoso y propenso a errores, y compite por los recursos con otras mejoras. Y # 2 nos dice que algunas de estas mejoras de la competencia pueden ser correcciones a errores de seguridad que son de mayor riesgo que el criptografía obsoleto pero ininterrumpido.

Pero tenga en cuenta que es una práctica estándar recomendar que los proyectos nuevos siempre utilicen el criptográfico recomendado best disponible en el momento en que comienzan. Por ejemplo, los criptógrafos de hoy generalmente le dicen a la gente que use SHA-2 en todos los proyectos nuevos, no en SHA-1.