ruby - OpenSSL vs GPG para cifrar copias de seguridad fuera del sitio

encryption puppet (1)

Dada la opción entre utilizar GPG y OpenSSL para el cifrado local antes de enviar los archivos a una ubicación de respaldo fuera del sitio, ¿cuáles son los beneficios y desventajas de cada solución?

Antecedentes: actualmente administro una infraestructura de servidor basada en Ubuntu 14.04.1 con todos los parches actuales aplicados a medida que están disponibles.

Todos estos sistemas no tienen cabezal, se construyen automáticamente usando preseeds y herramientas de automatización analizadas, y se ejecutan en máquinas virtuales a través de KVM en hardware uniforme basado en Intel.

Tenemos una preferencia por Ruby, pero una preferencia más fuerte por "hacer las cosas correctamente". Debido a ambos, hemos elegido la joya de "copia de seguridad" como medio para crear archivos cifrados de datos que queremos preservar, ya que creará los mismos archivos encriptados para un desarrollador que use Vagrant que lo haría en producción, independientemente del mecanismo de que se transmite

Todo el software y la configuración se administran a través de Puppet, por lo que ninguna decisión tendrá ningún impacto sobre la "experiencia del usuario" o la conveniencia. Cualquiera de las opciones creará scripts relevantes para administrar, verificar o restaurar desde cualquier copia de seguridad creada.

Teniendo eso en cuenta, ¿la opción de encriptación ofrece alguna ventaja contra la otra cuando se usa para este propósito?

Elegiría GPG para el cifrado de archivos, tiene décadas de encriptación probada y es muy fácil tener múltiples "destinatarios" (claves de respaldo?) O firmas con sus claves públicas e incluso servidores (si fueran útiles).

Con GPG, se han evitado / solucionado todos los errores simples, se selecciona una clave "aleatoria" más larga para el cifrado real y se hace una buena cantidad de "rondas" para que sea muy segura.

OpenSSL debería poder hacer todas las mismas cosas (ha estado presente desde 1998, pero si los números de versión significan algo, llegó a la versión 1 en 2010), pero es muy fácil cometer un error que podría reducir drásticamente la seguridad. Y a partir de esta publicación en security.stackexchange.com (de enero de 2013) y otra de un usuario de reputación de 159K, el comando openssl enc podría dejar algo que desear:

El formato de encriptación utilizado por OpenSSL no es estándar: es "lo que OpenSSL hace", y si todas las versiones de OpenSSL tienden a estar de acuerdo entre sí, todavía no hay ningún documento de referencia que describa este formato excepto el código fuente de OpenSSL. El formato del encabezado es bastante simple:
valor mágico (8 bytes): los bytes 53 61 6c 74 65 64 5f 5f valor de sal (8 bytes)
De ahí un encabezado fijo de 16 bytes, que comienza con la codificación ASCII de la cadena "Salted__", seguido de la sal misma. Eso es todo ! Sin indicación del algoritmo de encriptación; se supone que debes hacer un seguimiento de eso tú mismo.
El proceso por el cual la contraseña y la sal se convierten en la clave y IV no está documentado, pero al observar el código fuente se muestra que llama a la función EVP_BytesToKey() específica de OpenSSL, que utiliza una función de derivación de clave personalizada con hashing repetido . Esta es una construcción no estándar y no bien examinada (!) Que se basa en la función hash MD5 de dudosa reputación (!!); esa función se puede cambiar en la línea de comandos con el indicador -md no -md (!!!); la "cuenta de iteración" es establecida por el comando enc en 1 y no se puede cambiar (!!!!). Esto significa que los primeros 16 bytes de la clave serán iguales a MD5 (contraseña || sal) , y eso es todo.
Esto es bastante débil! Cualquiera que sepa escribir código en una PC puede intentar descifrar tal esquema y podrá "probar" varias docenas de millones de contraseñas potenciales por segundo (cientos de millones se podrán lograr con una GPU). Si usa "openssl enc", ¡asegúrese de que su contraseña tenga una entropía muy alta! (es decir, mayor de lo recomendado habitualmente, apunte a 80 bits, al menos). O, preferiblemente, no lo use en absoluto; en cambio, busque algo más robusto ( GnuPG , al hacer un cifrado simétrico para una contraseña, utiliza un KDF más fuerte con muchas iteraciones de la función hash subyacente).

man enc incluso tiene esto en "BUGS":

Debería haber una opción para permitir que se incluya un recuento de iteraciones.