Doble encriptación con algoritmo de elaboración doméstica

El principio de Kerckhoffs afirma:

  

Un criptosistema debe ser seguro incluso si todo sobre el sistema,   excepto la clave, es de conocimiento público.

Por lo tanto, si AES se rompe, es probable que el algoritmo de tu homebrew sea mucho más fácil y ya se habría roto.

Me doy cuenta de que parte de tu pregunta original decía:

provided they do not have the algorithm

Sin embargo, como esto viola el principio de Kerckhoffs, su enfoque de elaboración casera es en sí mismo defectuoso e inseguro.

La principal razón por la que esto es un problema es que no se puede cuantificar la cantidad de seguridad que agrega a su sistema. Le remito a la respuesta de Thomas Pornin a una pregunta similar aquí :

  

Un giro adicional es que la oscuridad del algoritmo puede dañar la seguridad.   Lo que explico anteriormente es que no se puede confiar en la oscuridad para la seguridad:   podría aumentar la seguridad, pero no mucho (y realmente no puede   saber "cuánto"). Resulta que también puede disminuir la seguridad. los   El problema es el siguiente: es muy difícil hacer un seguro.   algoritmo criptográfico. El único método conocido es publicar el   algoritmo y esperar a la sabiduría colectiva de los criptógrafos alrededor   el mundo para roerlo y llegar a una conclusión que se puede expresar   como "se puede romper de esa manera" o "aparentemente robusto". Un   El algoritmo se declara "bueno" solo si resistió el ataque de   docenas o cientos de criptógrafos competentes durante al menos tres o   cuatro años.

Por lo tanto, debería usar otro algoritmo si le preocupa que AES pueda romperse pronto (eso o no use AES en absoluto). Supongo que el resto de su sistema no es 100% seguro, por lo que, en lugar de perder tiempo, esfuerzo, energía y recursos en la creación de un algoritmo de elaboración doméstica, este esfuerzo debería gastarse en otro lugar, donde puede ser cuantificable que en realidad esté aumentando. seguridad. Todo el código tiene un costo, y no es solo el salario del desarrollador junior lo que lo está creando. Debe ser mantenido y comprendido por todos, y cada persona adicional que aprenda cómo funciona es una vía adicional para que el algoritmo se filtre. No pierdas tu tiempo.

Podría funcionar, y sería seguridad en profundidad en lugar de seguridad por oscuridad, pero hay algunas formas de desordenar esto catastróficamente:

• Usando un algoritmo HomeBrew que es vulnerable a ataques de canal lateral. Ahora el atacante puede hacer un análisis de tiempo o caché simple, por ejemplo, y omitir la parte AES enteramente. ¿Está tan seguro en su implementación?

• Reutilización del material entre los algoritmos. Si reutiliza las teclas y los nonces, por ejemplo, AES(HomeBrew(openText, "secret"), "secret") , podría ser vulnerable al análisis criptográfico. Esta es una amenaza lejana, pero es necesaria si desea mantener el mismo estándar de seguridad de solo AES(openText) .

• Usando una implementación de HomeBrew frágil. Si se rompe cuando el texto contiene nulos, tiene un tamaño superior, está por debajo de cierto tamaño o se parece a this , o contiene unicode válido, o contiene codificaciones inválidas, etc. Esto es un problema de programación, pero abre su software a cualquier cosa, desde denegaciones de servicio a una autenticación incorrecta o peor.

En general, me parece una idea divertida , pero no una práctica . Tal vez el uso de algo que no sea casero sea mejor; Hay formas más seguras de aumentar la profundidad de su seguridad.

Por sí mismo, su algoritmo de fabricación casera es una forma de seguridad en la oscuridad . Sin embargo, cuando se aplica en combinación con un buen cifrado conocido, su algoritmo de elaboración doméstica puede considerarse una estrategia de defensa en profundidad. Cotizando directamente desde Wikipedia,

  

Un sistema puede usar la seguridad en la oscuridad como una defensa en profundidad   medida; mientras que todas las vulnerabilidades de seguridad conocidas serían mitigadas   a través de otras medidas, divulgación pública de productos y versiones en   su uso los convierte en objetivos tempranos para vulnerabilidades recién descubiertas en   Esos productos y versiones. El primer paso de un atacante suele ser   recopilación de información; Este paso puede ser retrasado por la seguridad a través de   oscuridad.

Si se divulga públicamente una vulnerabilidad en AES hoy en día, aún así, a un atacante le tomará un tiempo descubrir cómo descifrar su algoritmo de elaboración doméstica, dándole tiempo para cambiar a otro algoritmo. Como dice el dicho, "no pongas todos tus huevos en una canasta".

Para los realmente paranoicos, puede adoptar dos capas de cifrado estándar diferente, como AES + DES. Sin embargo, tener múltiples capas de cifrado diferente no es gratis. La compensación es que el texto cifrado se vuelve más grueso.

Dieter Vandenbroeck escribió un artículo sobre cuándo tiene sentido la seguridad a través de la oscuridad:

  

Por lo general, el principio de seguridad a través de la oscuridad es completamente   incorrecto. La idea detrás de este principio es tener oscuridad en tu   La solución como principal medio de seguridad. Por supuesto, esto no es un   sustituto válido de la seguridad real: una vez que su esquema de oscuridad es   Roto, tu seguridad se rompería. Podría formar una defensa contra   scripts automatizados, pero un atacante con suficiente determinación lo hará   Siempre podrás luchar a través de esta defensa.

En su caso, no tendrá un script automatizado y, para cuando AES pueda ser descifrado de forma automática, es probable que el homebrew sea aún más defectuoso y tan fácil de descifrar. Así que no, no creo que Homebrew te ofrezca un beneficio de seguridad adicional en comparación con AES simple.

• Tiene sentido , incluso si usa ROT13, ya que agregará una capa de seguridad. AES (HomeBrew (openText)) siempre será más seguro que AES(openText)...

• ... a menos que este algoritmo suyo agregue alguna debilidad a AES que facilitará el criptoanálisis. Lo cual dudo.

• Pero personalmente me quedo con algoritmos conocidos y uso algo como AES(Threefish(Plaintext)).

• Sin embargo, ¿dónde está la diversión en eso?

• ¿Y cómo pretende mantener seguro su algoritmo, si pretende usarlo?

Generalmente no me molestaría.

Estoy de acuerdo con abligh.

Es probable que el "Homebrew_Crypto (AES (texto sin formato))" no agregue mucho a la seguridad del sistema, pero lo que HARÁ, incluso contra un atacante a nivel estatal, simplemente los retrasará. (Disminuirá mucho la cantidad de atacantes no sofisticados; para No Such Agencies los forzará a usar algunos ciclos más de tiempo de supercomputadora, lo que puede obtener puntos Brownie en su lista "Enemies Of Our Woved National Security State".)

Una variación realmente divertida de esto sería:

"Homebrew_Crypto (Twofish_Or_Some_Other_Good_Crypto_Algorithm (AES (texto sin formato)))" - con el riesgo de ralentizar significativamente la E / S, por supuesto. Algo así como esas muñecas rusas que anidan una dentro de la otra.

Tenga en cuenta que la última opción estaba disponible en Truecrypt y creo en sus sucesores como Veracrypt.

Hay otra razón por la que este podría ayudar. En lugar de hacer AES (Homebrew (Plaintext)) , supongamos que haces Homebrew (AES (Plaintext)) .

Supongamos también que es el peor de los casos, y aunque creas que eres un genio de las criptografías, tu algoritmo Homebrew no es más útil que ROT-13.

En este caso, hoy tiene un esquema combinado que no es peor que AES solo (salvo que podría ser un poco más lento), pero no mejor. Si su Homebrew es mejor que ROT-13, quién sabe que el esquema combinado podría ser ligeramente mejor que AES solo.

Sin embargo, ahora asumamos que en algún momento en el futuro, AES se rompe. Un exploit de día cero está disponible, y un exploit es ampliamente publicitado. Script Kiddies en abundancia intenta encontrar material encriptado AES y descifrarlo. Suponiendo que no lo estén dirigiendo específicamente a usted, es poco probable que puedan descifrar sus datos mediante el pirateo, ya que no pensarán aplicar algún otro descifrado primero, y hay frutos bajos en otros lugares. Esto, al menos, le da un poco más de tiempo para cambiar su cifrado subyacente a algo que no está roto.

Si vale la pena la velocidad y la penalización de mantenimiento es otra pregunta completamente.

1. Se comprobó que el cifrado estándar es bueno
2. Algoritmo desconocido "por si acaso" que incluso en caso de fugas no proporcionará mucho al atacante a menos que sepa cómo romper AES

Excepto que ahora tiene DOS estándares que mantener, y una debilidad en UNO de ellos debilitará el segundo, porque dos cifras en tándem producen efectivamente un tercer cifrado que está sujeto a las debilidades de cada uno. El homebrew probablemente lo estropeará para todos, al final del día. :)

Si tiene un cifrado que se CONOCE como más fuerte que el otro, entonces sería mejor gastar el esfuerzo para garantizar que se implementa correctamente.

Incluso los protocolos establecidos con seguridad demostrable solo deben combinarse en ciertos casos; los algoritmos inadecuados en cascada pueden hacer que surjan patrones subyacentes cuando los cifrados individuales "deshacen" el trabajo de los demás, simplemente porque sus metodologías son contraproducentes.

Es mucho más probable que un cifrado de homebrew debilite el resultado en lugar de fortalecerlo. En mi opinión, es mejor no tejer tu propia criptografía.