Brute-force una frase de contraseña, generada por 'pwgen 16 -s', de un archivo GPG CAST5

2

Una triste historia: uno de nuestros discos duros falló. Mientras fallaba, logramos realizar una copia de seguridad rápida. Como es nuestra práctica estándar, ciframos la copia de seguridad utilizando GPG (sin embargo, el método que utiliza Duplicity para hacer eso, muy probablemente es gpg -c ). Desafortunadamente, almacenamos la contraseña incorrecta. (Doh!)

La copia de seguridad contiene algunos datos que nos gustaría mucho recuperar.

Sabemos que la frase de contraseña fue generada por el comando pwgen -n 16 -s en una máquina de servidor moderna de Ubuntu de 32 bits que es un invitado en un host Xen. Es posible que tengamos una frase de contraseña del mismo grupo de frases de contraseña pwgen (esa es la "frase de contraseña incorrecta"). Hay varios archivos en la copia de seguridad, cada uno cifrado con la misma frase de contraseña.

¿Es posible intentar forzar la frase de contraseña de forma bruta? ¿Qué herramientas hay para eso? ¿Cómo calcular el costo y el tiempo de dicho intento de recuperación de frase de contraseña de fuerza bruta? (Supongamos, supongamos, que estamos dispuestos a alquilar instancias de GPU de HPC de Amazon según sea necesario, y que Amazon tiene suficientes disponibles).

Dado que tenemos 62 ^ 16 contraseñas posibles, y descifrar el archivo más pequeño (265B) con gpg toma 0.02s en mi caja (bastante antigua), la respuesta parece ser "no factible" ... Pero nunca duele preguntar.

Si lo prefieren las reglas del sitio, puedo reformular esta pregunta como "¿qué tan difícil de romper es este método de cifrado de respaldo?" :-)

    
pregunta Alexander Gladysh 04.06.2012 - 20:27
fuente

1 respuesta

4

Me temo que no hay mejor que la fuerza bruta. Las herramientas que usaste hacen su trabajo correctamente o lo suficientemente cerca.

  • La duplicidad invoca gpg -c , que se encripta usando CAST5 con una clave de 128 bits por defecto. No hay ningún ataque importante contra CAST5 que yo sepa.
  • gpg -c usa una función de fortalecimiento de claves para generar una clave simétrica. Implica 2 16 rondas de SHA-1, y dudo mucho que se haya roto, por lo que la clave real tiene tanta entropía como la contraseña que ingresó (aproximadamente 95 bits).
  • pwgen lee un número aleatorio de 32 bits de /dev/urandom (que es de calidad criptográfica, excepto en ocasiones en un sistema recién instalado que no ha tenido tiempo de generar entropía, y solo si puede predecir el tiempo de todas las operaciones del disco) hasta ahora, que es una tarea difícil) y toma el resto módulo 62. Eso no es correcto, porque está sesgado hacia los dígitos 0123 , pero el sesgo es insignificante (aproximadamente 2 -30 apagado de un Distribución uniforme) para solo 16 carreras.
    (En realidad, hay un problema importante en pwgen : de forma predeterminada se establece de forma predeterminada un generador aleatorio que no es de calidad criptográfica si /dev/urandom no está disponible. Pero es muy poco probable que no haya /dev/urandom ).

Cada carácter que muestra pwgen se genera de forma independiente, por lo que tener otra contraseña del mismo lote no ayudará.

Fuerza bruta para 2 95 posibles claves está fuera de discusión. Eso es algo más de mil millones de billones. Necesitaría calcular aproximadamente 2 110 hash SHA-1.

Si la máquina física en la que generó la copia de seguridad aún está encendida, existe una posibilidad muy pequeña de que la memoria asignada por pwgen no haya sido reutilizada por otro proceso. O la memoria asignada por el emulador de terminal, o un programa que utilizó para copiar y pegar la clave, o (incluso más difícil de explotar) la memoria asignada por gpg . Sus copias de seguridad pueden valer la pena si alguien estudia detenidamente un volcado de memoria.

Compruebe si la salida de pwgen podría haberse registrado en algún lugar. ¿Sigue siendo visible en una historia terminal? ¿Ejecuta rutinariamente programas bajo script ? ¿Todavía está en una sesión de pantalla en vivo? ¿Está en el historial de un portapapeles?

Creo que lo mejor que puedes hacer es intentar recuperar el hardware en el disco fallido.

    
respondido por el Gilles 04.06.2012 - 23:04
fuente

Lea otras preguntas en las etiquetas