La seguridad POR la oscuridad es horrible. ¿Es buena la seguridad y la oscuridad?

¡No hagas rodar tu propia criptografía!

Desde un punto de vista criptográfico puramente , cualquier función biyectiva que conserva la longitud no puede reducir la seguridad. De hecho, incluso la función de identidad , definida como f (x) = x , no lo hará reduzca la seguridad, suponiendo que las claves utilizadas para el cifrado estándar y su cifrado homebrew son mutuamente independientes. La única manera posible de reducir la seguridad es si su función homebrew no usa una clave diferente e independiente y pierde la clave en el texto cifrado, por ejemplo con f _k (x) = x ⊕ k hecho en cada bloque individual de entrada x , un cifrado XOR clásico vulnerable a ataques de texto plano conocido.

Desde un punto de vista práctico, hay errores que pueden ser importantes. Mencioné la conservación de la longitud arriba por una buena razón. Una función de compresión sigue siendo una función, y en ocasiones la compresión y el cifrado pueden llevar a muy malos resultados . Esto es parcialmente por lo que su segundo ejemplo, con su algoritmo personalizado aplicado antes del cifrado estándar, es realmente peor. Puede filtrar información sobre el texto plano a lo largo. También puede haber errores en su implementación que resulten en otras vulnerabilidades de seguridad. Desde un punto de vista puramente teórico, están fuera de alcance.

En un comentario me indicaron que es posible que no esté enfatizando lo suficiente qué tan mala es esta idea. Si bien puede estar bien en teoría, el mundo real funciona de manera diferente. En realidad, usar tu propio criptografía casera es una muy mala idea , no importa cómo lo uses. La única vez que deberías hacer esto es si eres un criptógrafo profesional. Bernstein puede hacer esto. Rivest puede hacer esto. Rijmen puede hacer esto. No se puede. No se dispare en el pie y, en su lugar, utilice los algoritmos adecuados.

Hay un riesgo involucrado cuando aplica su algoritmo de cifrado personalizado primero.
Esto se basa en el hecho de que un cifrado como AES filtra información sobre la longitud del texto sin formato.

Suponga que el ejemplo extremadamente hipotético (y poco práctico) en el que el algoritmo personalizado "encripta" un texto plano de un solo byte como 0x40 a 64 ceros y un texto plano de dos bytes como 0x02 0x00 a 512 ceros.

Al cifrar esto usando AES, un atacante aún sabrá la longitud del resultado cifrado personalizado con solo mirar la longitud del texto cifrado AES.
Con esta información, el atacante puede "descifrar" esto en el texto sin formato original sin tener la clave de cifrado AES.

En resumen: un algoritmo personalizado muy malo puede dañar la seguridad de un siguiente cifrado AES.

La primera pregunta que se debe hacer al evaluar cualquier tipo de sistema de seguridad es "¿Quién es el atacante y qué pueden hacer?" En el extremo inferior, estás en contra de un atacante que solo puede ver la salida cifrada de uno de tus mensajes. En el nivel más alto, te enfrentas a un atacante que conoce los pares de texto simple y texto cifrado de cientos de otros mensajes , que puede obligar a su computadora a encriptar otros mensajes con la misma clave , que puede monitorear las líneas eléctricas de su edificio y medir las pequeñas variaciones en el consumo de energía a medida que avanza el proceso de encriptación , y todo tipo de ataques similares. Los algoritmos de cifrado estándar se examinan para asegurarse de que sean resistentes incluso a estos adversarios poderosos.

Si usa su propio cifrado primero, incluso si la segunda capa es cifrado de grado militar, corre el riesgo de disminuir su seguridad en comparación con solo usar el cifrado estándar.

Por ejemplo, suponga que está cifrando texto. Primero use un simple cifrado de sustitución y luego use su elección de algoritmo de golpe fuerte. Desafortunadamente, los cifrados de sustitución dependen intrínsecamente de realizar búsquedas de matriz a partir de información privada (es decir, su texto plano y su clave). Esto los hace vulnerables a los ataques de temporización: debido a la forma en que funcionan las memorias caché de la CPU si dos letras en el texto sin formato están muy juntas, probablemente cifrarán más rápido que dos letras adicionales. Eso no suena como mucha información, pero si un atacante puede ver suficientes encriptaciones, puede averiguar cuál es el texto simple sin tener que descifrar AES o lo que sea que esté usando en la parte superior.

Si su capa de encriptación personalizada no interactúa en absoluto con información secreta: es decir, funciona con datos que ya han sido suficientemente encriptados para la transmisión y no tocan las claves del encriptado estándar, entonces puede ser seguro. Al menos, no será posible pasar por alto el cifrado estándar. Sin embargo, aún existen riesgos porque cada pieza adicional de software conlleva riesgos adicionales. Quizás un error en su capa personalizada le permite a un adversario remoto ejecutar comandos arbitrarios en su máquina; ¡Entonces podrían simplemente enviarse por correo electrónico el texto sin formato!

El mensaje para llevar a casa, entonces, es que tener un solo trozo de excelente código de seguridad que esté bien examinado y libre de errores como una función de encriptación estándar aún puede ser socavado si coloca un programa doméstico con errores (de cualquier tipo, encriptación o de lo contrario) en el mismo sistema.

Simple. No hagas esto.

En primer lugar, los algoritmos de cifrado están diseñados para que usted, yo y todos los que nos rodean puedan verlo e intentar romperlo. "Literalmente puede buscar en las matemáticas para AES . Mucha gente inteligente ha invertido tiempo en validar AES. Este es un principio de buen cifrado y por eso podemos confiar en él.

Segundo, Obscurity nunca es una opción de "Seguridad". No proporciona ningún beneficio. Si realmente crees esto, te remito a "Ley de Schneier" .

  

Cualquiera puede inventar un sistema de seguridad que él mismo no pueda romper. He dicho esto con tanta frecuencia que Cory Doctorow la ha llamado "Ley de Schneier": cuando alguien te entrega un sistema de seguridad y dice: "Creo que esto es seguro", lo primero que debes preguntar es: "¿Quién demonios es?" ¿tú?" Muéstrame lo que has roto para demostrar que tu afirmación de la seguridad del sistema significa algo. - Bruce Schneier, 2016

Todo lo que has hecho es:

• Introduzca un riesgo innecesario en su aplicación
• Mayor tiempo de depuración para problemas
• Se agregó tiempo de CPU para una función sin valor

El principal más básico en Seguridad. Keep It Simple Stupid (KISS).

La seguridad por oscuridad es buena, a veces incluso excelente , siempre y cuando no sea la única capa de seguridad en la que se confía. Pero en tu caso, me temo que no vale la pena.

Toma GPG por ejemplo. Si usa GPG para cifrar un archivo con AES, tendrá un encabezado que le permitirá al atacante reconocerlo como un archivo GPG cifrado con AES. Si luego usa un cifrado personalizado para cifrar el archivo GPG, obtendrá un archivo que podría ser irreconocible. Un atacante podría suponer erróneamente que está usando cualquier tipo de cifrado (y perder mucho tiempo por nada), o podría suponer que está utilizando su cifrado personalizado y luego decidir utilizar técnicas de criptoanálisis para analizar su archivo (y lograr descifrarlo si Es lo suficientemente bueno o tu algoritmo apesta lo suficiente. Por otro lado, si lo hace al revés (primero cifre con un algoritmo personalizado y luego con AES), el escenario no cambia significativamente después de todo.

Dicho esto, me temo que no vale la pena porque el cifrado personalizado tiene un gran con de todos modos: tendrá que almacenar su software de cifrado en algún lugar, y su software es totalmente personalizado, lo que significa que Si por alguna razón lo pierde (copias de seguridad perdidas o robadas, etc.), está atornillado y no podrá recuperar ninguno de sus datos.

Una mejor solución podría ser utilizar varias capas de cifrado utilizando algoritmos que ya se conocen y están disponibles. Por ejemplo, GPG parece ser compatible con twofish, camellia, etc. No tengo experiencia para saber qué algoritmos deberían considerarse los más seguros, aparte de AES. De todos modos, solo como ejemplo, AES - > PESCADO - > CAMELLIA es probablemente una solución mucho mejor que su AES - > CUSTOM_ALGO. Por supuesto, siempre y cuando uses diferentes contraseñas seguras para cada capa de cifrado.

OPSEC? ...

Poner barreras adicionales entre la información crítica y un adversario es una buena idea en general, siempre que se haga de manera efectiva .

La oscuridad como una medida de seguridad significativa se aborda mediante el principio de OPSEC (seguridad operacional). En resumen, esto implica privar a un adversario de cualquier información que pueda ayudarlos a comprometer a su organización a través de métodos sociales o técnicos.

Sin embargo, con un buen cifrado, mantener las claves en secreto es suficiente para proteger sus datos. Cualquier capa técnica adicional debe estar justificada por sus propios méritos técnicos.

... O busto

La criptografía es una disciplina matemática muy complicada, y los pequeños errores pueden tener enormes consecuencias. Cuando se trata de criptografía, suponga que el valor de un algoritmo es prácticamente cero, a menos que un experto confiable indique lo contrario.

En los EE. UU., la NSA y el NIST son los asesores oficiales de los algoritmos e implementaciones criptográficos, respectivamente. Si no sabe dónde buscar opiniones o desea una base razonable para las políticas internas, comience allí.

En la práctica, envolver un buen cripto no tiene sentido. Una vez que un atacante encuentra un buen cripto, generalmente girarán y atacarán los puntos finales donde se exponen los datos no cifrados.

Este podría ser el servidor web donde los usuarios suministran información, el sistema SCADA que alimenta su base de datos o las estaciones de trabajo donde los empleados analizan o monitorean la información. Si tiene una bomba de datos que extrae información de una base de datos y la convierte a otro formato para enviarla a un proveedor / cliente, ese es otro gran objetivo. Alternativamente, podrían ir a buscar sus llaves.

En la balanza

Agregar características a una aplicación tiene una posibilidad distinta de cero de introducir errores y complicar la solución de problemas. Esto puede provocar un tiempo de inactividad prolongado cuando algo sale mal o respuestas más lentas a las vulnerabilidades de seguridad en la aplicación. Debido a estos factores, una característica de seguridad de poco o ningún valor es un detrimento en lugar de una mejora.

Si desea protegerse contra un posible ataque a AES, simplemente debe usar otro estándar criptográfico basado en un algoritmo revisado en lugar de desarrollar el suyo propio. Obtendrá una mejor seguridad con menos esfuerzo.

Hay dos problemas principales con el modo de seguridad y de oscuridad.

1. La oscuridad puede interferir con la seguridad. Si haces tu propio cripto, es muy probable que tenga defectos. Incluso los mejores sistemas tienen fallas, a pesar de que los principales expertos han trabajado en ellas durante décadas. Las posibilidades de que pueda hacerlo mejor que la comunidad de seguridad son bajas.

2. Pocas cosas son realmente oscuras. No hay muchas ideas nuevas en criptografía y lo que sea que hagas será una variación de algo que se ha hecho antes, así que no es tan oscuro. Los cambios menores son algo que los atacantes están acostumbrados a manejar.

Es fácil ver que la primera variante (último algoritmo personalizado) no puede comprometer la seguridad de un cifrado conocido, ya que si pudiera, sería un método para descifrar el cifrado conocido. Después de todo, los atacantes también podrían ejecutar el algoritmo personalizado en un cyphertext cifrado únicamente con el cifrado conocido si les ayudara a descifrarlo.

La otra dirección (el algoritmo personalizado primero) podría comprometer la seguridad del algoritmo conocido al introducir redundancia en la entrada de texto plano del cifrado conocido, lo que podría debilitar ese algoritmo.

Por ejemplo, tome el siguiente esquema de "cifrado" personalizado totalmente defectuoso: repita el texto sin formato de entrada dos veces para producir un "texto cifrado". Esto conduce a una cantidad extrema de redundancia agregada en la entrada del segundo algoritmo, lo que podría debilitar algunos cifrados reales. (Si debilita AES o no es una pregunta diferente). Esto realmente sucedió con el Enigma , donde los operadores repitieron un tres. Secuencia de boletines en su texto simple que hizo que su texto cifrado fuera vulnerable a ciertos tipos de ataques. Cita de la Cryptanalysis de la página de Wikipedia Enigma :

  

El segundo problema fue la repetición de la clave de mensaje dentro de   Indicador, que fue un grave fallo de seguridad. La configuracion del mensaje   fue codificado dos veces, resultando en una relación entre la primera y la cuarta,   Segundo y quinto, y tercero y sexto carácter. Este problema de seguridad   permitió a la Oficina de cifrado polaca entrar en el Enigma de antes de la guerra   sistema ya en 1932. El 1 de mayo de 1940, los alemanes cambiaron la   procedimientos para cifrar la clave del mensaje una sola vez.

La solución 1 podría reducir la seguridad si utiliza la misma clave secreta para cifrar AES y CustomEncryptionAlgorithm.

CustomEncryptionAlgorithm podría permitir la deducción de la clave secreta y, por lo tanto, comprometer AES también.

Si creas una clave única para CustomEncryptionAlgorithm, deberías volver a estar bien.

Algo como KEY = SHA-2 (AES-CipherText)

El problema es que es posible que su función de cifrado personalizada tenga un error y de alguna manera reduzca la seguridad. La única forma de asegurarse de que su CustomEncryptionAlgorithm no esté reduciendo su seguridad es tener investigadores que sean más inteligentes que usted, yo y el resto de su equipo combinados para verter su trabajo y verificarlo. Pero entonces no es de ninguna manera oscura en absoluto.

Para hacer un ejemplo extremo:

public string CustomEncryptionAlgorithm(string plaintext) {
    var ciphertext = plaintext.shuffle();
    return "password";
    return ciphertext; // ya ya. I know. You'd never make a bug that obvious.
                       // tell it to the guy who did the 'goto bug' at apple
}

Si obtuvieras este esquema, obtendrías algo como esto:

• AES - > CipherText - > CustomEncryptionAlgorithm- > Texto cifrado :

  'abcABC123!@#' -> 'password'
  'correct_horse_staple_battery' -> 'password'
  'password' -> 'password'
  

Por otro lado, si usaste el otro esquema:

• CustomEncryptionAlgorithm - > CipherText - > AES - > CipherText

  'abcABC123!@#' -> '8ZnO44trPK48kqr3rDxkdQ=='
  'correct_horse_staple_battery' -> '8ZnO44trPK48kqr3rDxkdQ=='
  'password' -> '8ZnO44trPK48kqr3rDxkdQ=='
  

Un poco mejor, tal vez. Pero todavía no es bueno en lo más mínimo.

Como se ha dicho: ¿Quién es el atacante?

¡Esto es realmente lo que debes averiguar y definir primero!

¿Es su abuela tecnofóbica quien tiene problemas con el control remoto del televisor? ¿Tu hermana pequeña (y muy curiosa)? Tu padre, que en realidad programa y administra computadoras, ¿y sabe cómo quitar un disco duro? El matón de la escuela local que te trabaja más? ¿Crimen organizado? ¿Una empresa que puede gastar millones en alquilar computadoras en la nube para un ataque de craqueo? ¿Un dictador del tercer mundo? ¿FBI, NSA o agencias equivalentes en tu propio país? ¿Alguna potencia mundial que tenga un excelente servicio de espionaje y no le importarán las bolsas de cadáveres para conseguirte?

Segundo: ¿Qué seguridad real y adicional su 'cifrado' 1 le dará contra sus atacantes? A menos que pueda explicar muy bien por qué es necesario cifrar el texto cifrado de nuevo [2] o es muy útil, no debe hacerlo. Más complejidad no significa más seguridad, significa más errores y más posibilidades de que las cosas no funcionen correctamente.

¿Y por qué los atacantes no se meten en su casa ni se meten a escondidas y colocan algún software espía o registrador de claves en su computadora? ¿Está seguro de que su cifrado será de ayuda contra el criptoanálisis de la manguera de goma [3], o si no existe la posibilidad de hacerlo, quién es lo suficientemente poderoso como para romper el AES pero no puede comunicarse con usted o con su persona más querida y cercana?

1. Digamos que tienes la oportunidad de obtener un cifrado sólido y seguro es casi tan alto como mi oportunidad de caminar en la luna; con cifrado, no solo todo debe funcionar con la clave correcta, sino que nada puede funcionar sin ella ...

   No conozco ningún sistema de cifrado construido por alguien fuera del campo que no se agrieta al ser revisado por expertos, y cuántos fuertes ¿Se han roto los sistemas de encriptación inventados por los mejores expertos?

2. Un ejemplo sería la comunicación en la Segunda Guerra Mundial desde Alemania a submarinos Una comunicación muy secreta era "sólo oficial", que era encriptado, la metainformación fue precedida y ambas fueron encriptadas por La clave regular y enviado. Al recibir la radio / operador Enigma lo haría descifrar el mensaje y pasar la información meta y aún encriptado Bloquee al oficial. ( vea aquí, por ejemplo, )

3. "en el que se aplica una manguera de goma con fuerza y con frecuencia al Las plantas de los pies hasta la clave del criptosistema. descubierto, un proceso que puede tomar un tiempo sorprendentemente corto y es bastante computacionalmente económico. "

Respuesta corta: puede ser, pero no en tu ejemplo.

Respuesta larga: otras respuestas han cubierto adecuadamente por qué su ejemplo no es tan útil y puede doler. Dicho esto, la oscuridad puede ser muy útil. Caso en cuestión: no coloque SSH en el puerto 22. Si cambia de 22 a 2222, tendrá una pequeña fracción de los intentos de fuerza bruta que de lo contrario haría. Si cambias al puerto 10000 + rand(1,55535) , es probable que desaparezcan por completo. Otro ejemplo es el puerto que golpea. Básicamente, la oscuridad es más útil en el proceso de conexión, no en el cifrado o las contraseñas.

Se refiere al segundo algoritmo como oscuridad, por lo que parece suponer que no agrega ninguna seguridad.

Si realmente no agrega seguridad, ¿por qué usarlo? Use la segunda contraseña además de la primera para el cifrado aes. Una contraseña dos veces más larga es mucho más segura que dos contraseñas (ejemplo: 2^2+2^2 = 4 vs. 2^4 = 16 ), especialmente cuando el segundo algoritmo es inseguro de todos modos.

Si se hace correctamente: seguro. La pregunta es ¿cómo sabes que es correcto? Ciertamente puedes escribir algo que filtre información a través de varias capas. La más obvia es la longitud y las repeticiones. También usar la misma clave puede ser problemático.

Es demasiado difícil decir lo que es correcto y todo eso. Claro, podrías argumentar que usar ROT13 antes de que AES lo haga un poco seguro y mi intuición diría ... bueno, al menos no puede doler, pero en realidad no lo sé.

Mi intuición diría que si aplicas un algoritmo que produce una salida indistinguible de la aleatoriedad sin cambiar la longitud y luego aplicas AES, al menos no debería reducir la seguridad de AES.

La oscuridad es parte de una seguridad (general), y es ortogonal a la seguridad (cifrado AES en su caso). La oscuridad defiende contra diferentes amenazas que la criptografía. Tome las contraseñas, por ejemplo: se requieren hash criptográficos para evitar que se filtren plaintexts del servidor, TLS evita que se escuche el tráfico de la red, mientras que la oscuridad es un formulario de contraseña que rellena con [*******] evita que su espectador pueda ver su texto sin formato. Por lo tanto, no puede hacer seguridad por oscuridad (solo), pero la seguridad con generalmente es el camino a seguir. En el mundo real, la oscuridad significa ocultar los metadatos, por ejemplo, enviar por correo con BCC en lugar de CC / To o bloquear cookies de terceros.

Es malo, malo , malo .

Hay una anécdota de algún protocolo móvil del Lejano Oriente para la inicialización de SIM o algo similar, que usó una combinación de RSA (bueno, seguro y fuerte) y algo hecho en casa.

La debilidad decisiva no fue solo el cifrado "adicional" de fabricación casera. Pero el problema era que, de hecho, había un caso especial cuando el método adicional era asociativo con RSA, lo que causaba un sangrado parcial de la clave. No recuerdo detalles, como me contaron como anécdota de una conferencia hace muchos años.

Pero el punto es válido: con una adición inadecuada de homebrew a un protocolo seguro, usted podría hacer que el protocolo sea más débil que su versión original. Entonces, eso es un gran no ir.