Has descrito un método, pero no el objetivo ni ninguna circunstancia:

1. ¿Cuál es la situación y su objetivo en ella?
2. ¿Contra qué adversarios quieres protegerte?

El escenario asumido

Supongo que quieres:

• desea enviar datos,
• sin que un intruso pasivo pueda obtener los contenidos,
• donde tiene ambas computadoras (o quizás un amigo es dueño de la computadora de destino).

En este caso, hay un canal alternativo disponible: puede hablar con su amigo (o usted mismo) por teléfono o en la vida real, para que pueda darles la contraseña. Utilice un archivo 7z cifrado y envíelo por correo electrónico o algo así.

Para verificar la integridad, en caso de que un atacante activo haya manipulado la transmisión, puede calcular el hash (generado mediante, por ejemplo, el comando sha256sum en sistemas basados en GNU) e incluirlo en un archivo en El archivo 7z. El archivo en sí ya tiene sumas de comprobación, pero eso no califica como cifrado autenticado (integridad criptográfica + confidencialidad), por lo que debe verificarlo por separado. También puede, al dar la contraseña, darle el hash a su amigo para que puedan verificarlo de esa manera.

Pero también podrías querer decir ...

• desea enviar datos,
• a alguien a quien nunca conoció (como un visitante de su sitio web),
• sin que un espía activo pueda obtener o modificar los contenidos.

En ese caso, ¿cómo vas a intercambiar claves? Cualquier contraseña que envíe a través de la línea, un interceptor puede interceptar. Y cualquier algoritmo de intercambio de claves que proteja contra intercepciones pasivas, puede ser derrotado por atacantes activos. La forma en que https lo resuelve, es tener terceros de confianza. Al tener un certificado de una de esas partes confiables, como Let's Encrypt , el destinatario puede estar razonablemente seguro de que las claves de cifrado que recibió no provienen de un atacante.

Entonces, lo que necesitas realmente depende de la situación. A partir de su descripción, asumo que un archivo 7z encriptado es suficiente; pero si desea una respuesta más específica, necesita hacer una pregunta más específica.

En cuanto a "¿es suficiente el cifrado de una capa?"

Bueno, ¿cuánto confías en un algoritmo dado? Puedo venderte un algoritmo de súper lujo por solo $ 500, pero nadie lo comprobó. Podría usar AES: diseñado por belgas, usado en los estándares de los EE. UU., Y mucha gente lo ha estudiado por fallas. Las probabilidades de que se rompa son, en mi opinión, insignificantes. Pero tal vez tenga miedo de que la NSA tenga AES de puerta trasera, en cuyo caso es posible que desee usar algoritmos rusos como GOST. Pero, ¿qué pasaría si los rusos dieran esa puerta por detrás? Podría usar ambos y mezclar los dos, pero si bien eso en teoría no es un problema, en la práctica las modificaciones leves del uso recomendado pueden provocar fallas catastróficas. Sería como una sopa criptográfica casera.

Para resumir una larga historia: sí, usar solo una capa de cifrado es definitivamente suficiente. (Suponiendo una situación estándar). Sin embargo, la pregunta es: ¿es seguro el algoritmo? ¡Elija su método de encriptación sabiamente!

No es necesario

Para responder a su pregunta en general: No necesariamente .

Eso no quiere decir que sea una pérdida de tiempo.

El cifrado por sí solo no siempre es suficiente para garantizar la confidencialidad de sus datos, pero los detalles se basan en los detalles de su caso de uso.

Un ejemplo

Por ejemplo, supongamos que utilizó un esquema de cifrado no acolchado como AES-256 en modo CTR, que administró correctamente sus IV y claves, y que su sistema fue diseñado para enviar cadenas JSON cifradas en el siguiente formato:

{evil:[true|false]}

AES-256 en modo CTR es bastante seguro, pero la longitud de la salida cifrada será de 11 bytes si es verdadera, y de 12 bytes si es falsa. Otros modos de cifrado también sufrirían esto, aunque posiblemente en menor grado.

Pero como muestra el ejemplo pedante: teóricamente, sus datos podrían filtrarse de sus metadatos.

Además

Ahora, supongamos que logras normalizar tus datos y salvaguardas su salida contra el meta criptoanálisis,

Si sus datos son analizados y utilizados por un algoritmo, es casi seguro que desee autenticar su integridad (debido a las sustituciones de texto sin formato conocidas).

Por ejemplo: si estaba implementando un protocolo de navegador web sin cifrado autenticado, uno podría ser capaz de intercambiar parte de su texto cifrado (generalmente el encabezado) e inyectar una etiqueta de script o cualquier etiqueta de recurso remoto. Este recurso inyectado podría usarse para exponer el contenido de sus datos encriptados.

Una vulnerabilidad similar fue explotada en varios clientes de correo electrónico de PGP , lo que permite a los atacantes ver el contenido de un correo electrónico sin romper el cifrado. "

tl;dr

Use el cifrado autenticado y conozca sus datos. Es posible que deba protegerlo contra el metanálisis.

Si solo quiere asegurarse de que nadie tenga acceso a los datos simples durante el tránsito y que los datos no puedan modificarse, entonces es suficiente cifrar los datos una vez, suponiendo que se hacen correctamente, es decir, clave segura, cifrado seguro Algoritmo y fuerte protección de integridad.

Pero, hay casos en que se necesita más, como autenticación fuerte, ocultación de metainformación como quién se comunica con quién, ocultación de patrones de tráfico como tamaño y tiempo de datos, etc. En este caso, es posible que desee transferir los datos ya cifrados. sobre un túnel que proporciona protección adicional.

A las personas de seguridad les gusta hablar de cifrado "en reposo" y "en tránsito". Son cosas ligeramente diferentes. El cifrado también viene con otras características además de hacer que sus datos sean ilegibles para el destinatario. El cifrado de archivos a menudo se usa junto con la firma, lo que demuestra el origen del archivo. El cifrado de transporte generalmente se realiza con una clave privada en el extremo remoto, lo que demuestra que ha enviado el archivo al lugar correcto.

Por supuesto, ambos enfoques pueden implementarse de tal manera que proporcionen los beneficios del otro, pero esto es un poco más esotérico que usar el software tal como salió de la caja.

Sin embargo, tienen diferentes puntos débiles: el cifrado de archivos requiere que usted y su interlocutor acepten una o más claves, lo que debe hacerse (o al menos verificar) a través de otro canal que no sea la forma en que envía los datos cifrados. El cifrado de transporte se puede hacer sin primero acordar una clave (suponiendo que use un mecanismo basado en certificado, el más obvio es TLS). OTOH TLS, SSL y SSH no son algoritmos de cifrado sino protocolos para acordar algoritmos y luego implementarlos para el canal. En el caso de TLS y SSL, la negociación ha sido históricamente un área de debilidad: ha sido posible, en algunos casos, engañar a un punto final para que acepte un algoritmo relativamente inseguro.

Entonces, si bien no es muy parecido a comparar manzanas con naranjas, son cosas diferentes y, por lo tanto, puede ser una ventaja al usar ambas.

Cuando se implementa correctamente, el cifrado único a través de un protocolo que proporciona cifrado autenticado es suficiente para verificar:

1. el contenido del archivo cifrado no se puede recuperar sin la clave secreta,
2. el contenido del archivo cifrado no ha sido manipulado por alguien que no tenga la clave secreta.

El cifrado autenticado utiliza una función de cifrado para asignar un texto sin formato para crear un texto cifrado basado en una clave secreta, pero también genera un Código de autenticación de mensaje (MAC) basado en el texto y una clave secreta. Una persona que no tenga la clave secreta no puede generar un MAC válido para un mensaje (y cualquier destinatario que intente descifrar un mensaje dañado descubrirá rápidamente que estaba dañado). Un algoritmo de código de autenticación de mensaje simple es MAC = Encrypt(Hash(ciphertext), Key) (Encrypt-Then-MAC) donde usted agrega este MAC a su texto cifrado y lo verifica antes de descifrarlo.

Dicho esto, hay muchas situaciones en las que varios niveles de encriptación son apropiados y la norma (incluso si cada protocolo de encriptación proporciona un MAC para verificar la integridad). Por ejemplo, carga un archivo ya encriptado a un servidor remoto usando el protocolo SSH ; o se conecta a la intranet de su trabajo a través de una VPN que utiliza IPSec para cifrar el tráfico de su red; luego utiliza SSH o visita una página web de HTTPS a través de esa VPN; o utiliza el cifrado a través de WiFi y luego se conecta a un sitio web HTTPS, etc. Es posible que se prefieran los protocolos de transferencia cifrados como SSH o HTTPS, incluso cuando se transfieren archivos que comenzaron a cifrarse, ya que puede verificar la identidad del servidor al que está cargando el contenido. (a diferencia de telnet o http, donde un interceptor de la red podría interceptar solicitudes y suplantarse secretamente al servidor correcto y los archivos nunca llegarán a su destino previsto. Dicho esto, el interceptor no podrá descifrar su archivo fuertemente cifrado sin la clave secreta ).

Tenga en cuenta que los escuchas ilegales de la red pueden, en todos los escenarios, escuchar la cantidad de tráfico que se envía y dónde se encuentra el próximo salto.