¿Por qué mantenemos nuestras claves en secreto, en lugar de nuestros algoritmos? [duplicar]

No solo queremos el secreto. Queremos el secreto cuantificable . El punto no es solo garantizar la confidencialidad de los datos, sino también poder saber que efectivamente garantizamos la confidencialidad de los datos.

Cuando tenemos un algoritmo público y una clave secreta, se puede cuantificar el secreto. Por ejemplo, si usamos AES con una clave de 128 bits, entonces sabemos que un atacante tendrá que probar un promedio de 2 ¹²⁷ posibles teclas (es decir, demasiadas para hacerlo) para encontrar la correcta.

Si, por el contrario, intentáramos usar un algoritmo secreto, enfrentaríamos tres grandes desafíos:

• Como explica @Xander, hacer un algoritmo de encriptación seguro es terriblemente difícil. El único método conocido que ofrece cierta confiabilidad decente es el diseño público: publique el algoritmo, suelte a cientos de criptógrafos en él y vea si pueden encontrar algo incorrecto en él. Si, después de un par de años, ninguno de ellos encontró algo malo en el algoritmo, entonces es probable que no sea demasiado débil. Con un algoritmo secreto, tiene que hacer usted mismo todo ese trabajo de revisión cruzada, lo que no es factible en un tiempo decente.

• No sabemos cuántos "algoritmos de cifrado decentes" pueden existir. Un atacante puede tratar de enumerar los posibles algoritmos, si "posible" significa "lo que el diseñador pudo haber encontrado". Parte del problema está en el ámbito de la psicología, por lo que la cuantificación será difícil.

• Todavía existe un algoritmo secreto como código fuente en algunas computadoras, binarios compilados en otras, y en la cabeza de al menos un diseñador. A menos que todas las computadoras de desarrollo involucradas y el cadáver del diseñador se hayan disuelto en un gran caldero de ácido, es muy difícil evitar que ese "algoritmo secreto" se filtre por todas partes. Por otro lado, una clave secreta es un elemento pequeño que puede administrarse de manera más eficiente y mantenerse en secreto (almacenado solo en RAM, posiblemente reconstruido a partir de un algoritmo de intercambio de claves como Diffie-Hellman ...).

Dado que el algoritmo probablemente se filtrará, también puede considerarlo público y confiar solo en el secreto de la clave. Al hacer realmente público el algoritmo, puede beneficiarse de una revisión extendida por parte de otras personas, lo que es una condición casi inevitable para lograr la seguridad.

Hay un par de cosas a considerar.

Primero, crear un algoritmo de cifrado seguro es difícil. No es un poco difícil, pero es realmente difícil, ya que no podemos demostrar que los algoritmos de cifrado son realmente seguros, pero solo demuestran que con lo que sabemos, no sabemos cómo romperlos con un esfuerzo de menos de 2 ^ n para un gran valor de n. Y así, la única manera de estar razonablemente seguro de que no hay fallas desastrosas en un algoritmo (y existen prácticamente en todos los algoritmos diseñados por amateurs, y muchos diseñados por profesionales) es someterlos a una revisión rigurosa por parte de personas calificadas. Entonces, si un algoritmo es revisado, no puede, por definición, ser secreto. Si, por otro lado, no se examina, no puede considerarse seguro bajo ninguna medida razonable.

Segundo, está el asunto práctico del secreto a largo plazo. Si solo confió en el algoritmo para el secreto, corre el riesgo de tener que cambiar el algoritmo en caso de que se descubra. Eso es difícil e implica modificar cada implementación del algoritmo, lo cual es costoso y perjudicial. Si la clave es el único secreto, las claves se pueden cambiar de forma económica y sencilla, lo que hace que los esquemas basados en claves sean mucho más atractivos.

En última instancia, la criptografía moderna se basa en el principio de Kerckhoffs que establece que: Un criptosistema debe ser seguro incluso si todo sobre el sistema, excepto la clave, es de conocimiento público. Esto se debe a que, con el conocimiento que tenemos, esta es realmente la única forma razonable de abordar un diseño de sistema de cifrado serio y seguro.

El esquema que has propuesto utiliza la sustitución básica. El mapeo, sin embargo complicado es (7 - 10) * 2 = -6. Entonces, usar el análisis de frecuencia en el texto cifrado proporcionaría el texto plano. En este momento, la cadena que está utilizando es demasiado corta para cualquier análisis, pero con el tiempo, el exceso de información que utiliza el mismo esquema proporcionará los medios para obtener el texto sin formato.

Una vez en este camino, es posible que desee considerar cómo se genera el texto cifrado si se cambia la función, como cada letra 12 o cada letra 18, solo para confundir la distribución de frecuencia del texto cifrado. Eventualmente, encontrarás los enigmas / decodificadores usados durante la guerra mundial. Y muy poco después, el uso de diffie helman para negociar de forma segura una clave compartida en público. DH es la piedra angular por la cual las negociaciones de claves públicas se manejan en Internet. Un desarrollo bastante interesante, ya que la clave utilizada para inicializar las máquinas de enigma requería que alguien transmitiera la clave en primer lugar. Una cosa difícil de hacer en medio de la lucha. Con eso, se solucionó el problema del huevo y la gallina.

Ahora, si solo las autoridades de certificación pueden controlar la cantidad de CA de segundo nivel, todo será mejor.

Una respuesta menos académica:

Imagina que eres el gobierno de algún país. Imagine que ha contratado a personas para diseñar este nuevo e increíble algoritmo de cifrado, y que ha contratado a personas para que construyan máquinas que lo implementen, y ha equipado todos sus barcos y aviones y centros de comando móviles, embajadas y oficinas y ... .con ello.

Y luego tu enemigo captura una de las máquinas, o tu enemigo se convierte en una de las personas que construyeron las máquinas, o ...

¿Cuál es más fácil? ¿Diseñar un nuevo algoritmo, diseñar nuevas máquinas y reemplazarlas todas? ¿O cambiar la clave?

Puede ser útil pensar en algo como DES no como un algoritmo, sino como un generador de algoritmo que, dados 56 bits, producirá uno de los algoritmos de encriptación de 2 ^ 56, la mayoría de los cuales son igualmente fuertes; esquemas más nuevos como AES pueden generar 2 ^ 128 o más algoritmos, todos los cuales son fuertes. Diseñar un algoritmo de cifrado seguro desde cero es extremadamente difícil; Tomar un algoritmo seguro y convertirlo en un "generador de algoritmo" que puede generar una gran cantidad de algoritmos seguros es, en comparación, mucho más fácil. Dada la opción de contratar a algún experto para diseñar un algoritmo de cifrado desde cero a un costo de miles de dólares o más, o lanzar unos cuantos dados y usar los resultados como "clave" para algún otro "generador de algoritmos", este último no solo es mucho más fácil y más para la mayoría de los usuarios de la criptografía, sino que también evita la necesidad de que ellos confíen en un extraño a su secreto. Si alguien tira algunos dados físicos y usa los resultados para generar una clave que se usa para asegurar la información secreta para su propio uso, y si lo estuviera, no querría que nadie pudiera decodificar sus secretos, no es necesario que deje que cualquier otra persona o grupo de individuos posee conocimientos suficientes para hacerlo.

Bueno, ¿cuántos algoritmos puedes imaginar? Tenga en cuenta que no deben confiar en que una clave sea diferente, de lo contrario, está utilizando claves.

¿Cuántos no comparten una forma de atacar? P.ej. replace x with x+10 y replace x with k[d] son vulnerables a un ataque de frecuencia de letras.

¿Cuántos no son el equivalente de 123456 y password , es decir, no estarán en la lista de algoritmos principales para verificar?

¿Hay suficientes como para que sea demasiado lento para que alguien las revise todas?