OpenSSL vs GPG für die Verschlüsselung von Off-Site-Backups?

Question

Angesichts der Option zwischen der Verwendung von GPG und OpenSSL für die lokale Verschlüsselung vor dem Verschieben von Archiven auf einen externen Backup-Standort, was sind die Vor- und Nachteile der einzelnen Lösungen?

Hintergrund: Ich verwalte derzeit eine Server-Infrastruktur basierend auf Ubuntu 14.04.1 mit allen aktuellen Patches angewendet, wie sie verfügbar werden.

Alle diese Systeme sind kopflos, werden automatisch mit geprüften Voreinstellungen und Automatisierungstools erstellt und in virtuellen Maschinen über KVM auf einheitlicher Intel-basierter Hardware ausgeführt.

Wir haben eine Vorliebe für Ruby, aber eine stärkere Vorliebe für "Dinge richtig machen". Aus beiden Gründen haben wir das Juwel "Backup" als Mittel zum Erstellen von verschlüsselten Archiven von Daten ausgewählt, die wir beibehalten möchten, da es die gleichen verschlüsselten Archive für einen Entwickler erstellt, der Vagrant verwendet, unabhängig vom Mechanismus was es übertragen wird.

Die gesamte Software und Konfiguration wird über Puppet verwaltet, so dass keine der beiden Entscheidungen Auswirkungen auf die Benutzerfreundlichkeit oder Benutzerfreundlichkeit hat. Beide Optionen erstellen relevante Skripts zum Verwalten, Überprüfen oder Wiederherstellen von erstellten Sicherungen.

Gegeben, bietet eine Verschlüsselungsoption einen Vorteil gegenüber dem anderen, wenn sie für diesen Zweck verwendet wird?

Answer 1

Ich würde GPG für die Dateiverschlüsselung wählen, es hat jahrzehntelang sichere Verschlüsselung getestet und ist sehr einfach zu mehreren "Empfänger" (Backup-Schlüssel?) Oder Signaturen mit seinen öffentlichen Schlüsseln & sogar Server (wenn sie nützlich sein würden).

Mit GPG wurden alle einfachen Fehler vermieden/behoben, es wählt einen längeren "zufälligen" Schlüssel für die eigentliche Verschlüsselung und macht eine gute Anzahl von "Runden", um es sehr sicher zu machen.

OpenSSL sollte der Lage sein, alle die gleichen Dinge zu tun, (es seit 1998 ist schon, aber wenn die Versionsnummern alles bedeuten erreichte Version 1 im Jahr 2010), aber es ist sehr einfach, einen Fehler zu machen, dass die drastisch senken könnte Sicherheit. Und von this post on security.stackexchange.com (ab Januar 2013) and another durch einen 159K Ruf Benutzer, der openssl enc Befehl könnte etwas zu wünschen übrig lassen:

Das Verschlüsselungsformat von OpenSSL verwendet wird, ist nicht-Standard: es ist „was OpenSSL tut“, und wenn alle Versionen von OpenSSL dazu neigen, miteinander übereinzustimmen, gibt es immer noch kein Referenzdokument, das dieses Format außer dem OpenSSL-Quellcode beschreibt. Das Header-Format ist ziemlich einfach:

magic-Wert (8 Bytes): Die Bytes 53 61 6c 74 65 64 5f 5F Salz Wert (8 Bytes)

daher ein fester 16-Byte-Header, beginnend mit der ASCII-Codierung der Zeichenfolge "Salted__", gefolgt vom Salz selbst. Das ist alles ! Keine Angabe des Verschlüsselungsalgorithmus; Sie sollten das selbst im Auge behalten.

Der Prozess, bei dem das Passwort und Salz in den Schlüssel gedreht und IV ist nicht dokumentiert, aber ein Blick auf den Quellcode zeigt, dass es die OpenSSL-spezifische EVP_BytesToKey() Funktion aufruft, die eine benutzerdefinierte key derivation function mit etwas wiederholt Hashing verwendet . Dies ist ein nicht standardisiertes und nicht gut geprüftes Konstrukt (!), Das auf der MD5-Hash-Funktion von zweifelhafter Reputation (!!) beruht; Diese Funktion kann in der Befehlszeile mit dem undokumentierten-md Flag geändert werden (!!!); Der "Iterationszähler" wird durch den Befehl enc auf gesetzt und kann nicht geändert werden (!!!!). Das bedeutet, dass die ersten 16 Bytes des Schlüssels gleich sind MD5 (Passwort || Salz), und das ist es.

Das ist ziemlich schwach! Jeder, der weiß, wie man Code auf einem PC schreibt, kann versuchen, ein solches Schema zu knacken und wird in der Lage sein, mehrere Dutzende Millionen potenzieller Passwörter pro Sekunde zu "versuchen" (Hunderte von Millionen sind mit einer GPU erreichbar). Wenn Sie "openssl enc" verwenden, vergewissern Sie sich, dass Ihr Passwort eine sehr hohe Entropie hat! (d. H. Höher als normalerweise empfohlen; Ziel für mindestens 80 Bits). Oder, vorzugsweise, benutze es überhaupt nicht; Stattdessen, gehen Sie für etwas robuster (GnuPG, wenn Sie symmetrische Verschlüsselung für ein Kennwort, verwendet eine stärkere KDF mit vielen Iterationen der zugrunde liegenden Hash-Funktion).

man enc hat auch diese unter "BUGS":

Es sollte eine Option sein, ein Iterationszahlcode zu ermöglichen einbezogen werden.