Encriptación de servidor a servidor: rotación de claves en el aire. ¿Puede mejorar la seguridad?

Con una sesión adecuada de TLS-con-AES, el tiempo necesario para que un interceptor "descifre información" variaría en siglos , al menos si los "recursos suficientes" se limitan a, digamos, Convirtiendo toda la masa de Júpiter en energía. En ese momento estoy bastante seguro de que las computadoras involucradas se habrán convertido en una masa compacta de óxido, por lo que el punto es un poco discutible. En pocas palabras, el cifrado simétrico no es el punto débil de TLS; Podría decirse que el cifrado utilizado correctamente no ha sido el punto débil de nada en las últimas dos décadas (al menos).

Sin embargo, para los verdaderamente paranoicos que desean obtener un sentimiento cálido y confuso de seguridad a partir de los encantamientos criptográficos rituales, puede negociar un nuevo apretón de manos sobre una sesión existente, en cualquier momento que desee. Tanto el cliente como el servidor pueden iniciar eso. Consulte el estándar TLS , especialmente las secciones 7.4.1.1 y 7.4.1.2.

Thomas lo tiene activado para TLS y / o AES.

Si está trabajando con un algoritmo menos moderno o es paranoico adicional, los dos métodos de actualización de claves que mencionó se han intentado en varios momentos y ambos tienen inconvenientes:

• datos como semilla a nueva clave : esta es la base de algunos cifrados de flujo. Por ejemplo, vea los modos de Comentarios de cifrado y Comentarios de salida que se usan comúnmente con DES. El truco es que el receptor debe estar sincronizado con el remitente. Si hay una interrupción en la transmisión, la transmisión puede convertirse rápidamente en un problema si se aplica una clave incorrecta a los datos cifrados.

• envuelve una nueva clave en una clave antigua - esta rara vez se usa, ya que si estás asumiendo que el atacante (dado el tiempo) ha recibido tu clave, debes asumir que ' Habré capturado todo el texto cifrado y no tendrá problemas para obtener la nueva clave. Sobre todo, en ese momento, le has ahorrado el trabajo de averiguar la nueva clave.

Una solución típica a este problema es usar una clave secundaria para transmitir la clave simétrica. Eso es exactamente lo que hace TLS: utiliza una clave asimétrica para proteger la distribución de la clave simétrica. Eso agrega una carga adicional: para obtener esa transmisión, el atacante debe averiguar la clave privada del par asimétrico utilizado para la transmisión de la clave simétrica. No habrá mucha exposición aquí, ya que lo único que puede estar encriptado son los nuevos pares de claves de sesión (simétricas).

Otro, en sistemas que no pueden manejar claves asimétricas, es usar una clave de distribución de clave secundaria que SOLAMENTE se usa para la distribución de claves. Esto tendrá una vida útil, ya que esa clave también tendrá problemas de exposición, pero mitigará el riesgo en algún nivel.

La distribución de claves es uno de los problemas más desagradables de la criptografía. No importa cómo lo corte, debe obtener al menos la primera llave de una manera algo dolorosa. Entonces, necesita una forma de mantener las claves apropiadamente actualizadas, y necesita una manera de recuperarse si alguna vez se pierde o compromete una clave. Las técnicas para todo esto varían mucho dependiendo de si se trata de criptografía asimétrica o simétrica, y algunos de los mejores sistemas combinan los dos para lograr la mayor potencia.

Odio las respuestas que estoy a punto de dar, pero en este caso es cierto. Si tiene que preguntar si desea utilizar una biblioteca criptográfica preexistente o si intenta crear la suya, definitivamente ya tiene su respuesta. Aún así, crear algo como AES o Skein o algo similar es mejor dejarlo como un ejercicio de aprendizaje y no de producción. Tal vez malinterpreté tu intención, pero no trates de crear tu propia criptografía para algo menos que algo divertido para ti.

Aunque, para responder a su pregunta, el punto de la fortaleza del cifrado es utilizar criptografía con la fuerza adecuada para garantizar la confidencialidad de los datos mientras sea útil. Si al utilizar el poder de cómputo de hoy en día está transmitiendo datos que deben mantenerse confidenciales durante 9 años, pero tomará 100 años romper el cifrado, creo que probablemente sea bueno sin rotar las claves.

Pregunto cuál sería una buena razón para introducir complejidad adicional, sin ningún beneficio. Parece que está solicitando un error críptico al intentar solucionar un error crítico al tratar de recuperar información crítica.