TomL hat geschrieben: 07.12.2017 19:50:58
Primär muss man sich entscheiden, ob man symmetrische oder asymmetrische Entschlüsselung bevorzugt.
Es gibt hier keine Entscheidung. Zumal symmetrische Verschlüsselungsverfahren für die Verschlüsselung von vielen Daten geeignet sind, asymmetrische Verschlüsselungsverfahren dagegen überhaupt nicht. Nicht umsonst werden asymmetrische Verschlüsselungsverfahren meist nur zum Schlüsselaustausch genutzt. Nimmt man nun einmal RSA als Beispiel, dann nutzt dieses Verschlüsselungsverfahren lediglich 8 byte Blöcke mit begrenzter Nachrichtenlänge. Wird diese Grenze nun überschritten anhand der Datenmenge, dann hat das kritische Folgen hinsichtlich der Sicherheit der Daten. Und je mehr dieser Daten erzeugt werden, desto mehr Teile des ursprünglichen Schlüssels werden sozusagen unfreiwillig veröffentlicht. Daher sollte das zwingend vermieden werden, auch wenn es auf den ersten Blick wirkt, als würde das problemlos funktionieren.
TomL hat geschrieben: 07.12.2017 19:50:58
Ein Vorteil der asymmetrischen Verschlüsselung mit RSA2048 ist, dass der Key zur Verschlüsselung nicht auch zur Entschlüsselung genutzt werden kann.
Sicher ist das praktisch, aber dennoch ungeeignet um große Datenmengen zu verschlüsseln. Wenn dann nimmt man eine Hybridverschlüsselung, indem die Daten stets symmetrisch verschlüsselt werden, und dann verschlüsselt man den symmetrischen Schlüssel mit einem asymmetrischen Verschlüsselungsverfahren. Das wäre dann eine saubere Sache.
TomL hat geschrieben: 07.12.2017 19:50:58
Alles zusammengenommen hat jetzt zu der Entscheidung geführt, RSA2048 nicht mehr für meine Zwecke zu nutzen und auf die Implementierung von ECC zu warten, welche dann RSA-16384 entspricht.
Genau genommen ist RSA-2048 ohnehin die letzte logische Option, bevor es schmerzhaft wird in Sachen Leistung mit größeren Schlüssellängen. Hier ist ECC eben deutlich schneller und effektiver, und heute schon experimentell in gpg nutzbar, mit dem --expert Parameter.
TomL hat geschrieben: 07.12.2017 19:50:58
Zu den Cipher'n AES256 und Camelia gibts derzeit nicht solche nahen Prognosen, wann die gebrochen sind - sofern man eine "harte" Passphrase wählt. Das klingt also erst mal ganz gut. Ein scheinbarer Nachteil ist, dass zur Verschlüsselung im Batchmode die Passphrase lesbar (zumindest für root) auf der Maschine hinterlegt sein muss - ein Nachteil deshalb, weil man damit auch entschlüsseln kann.
Wie gesagt man kann auch eine Hybridverschlüsselung umsetzen. Dann liesst man den symmetrischen Schlüssel eben mit dem Private-Key aus, und entschlüsselt dann die symmetrisch verschlüsselten Daten. Eine weitere Option wäre auch noch Twofish, zu dem es seit 1998, keine vollständige Kryptoanalyse gibt, um den Verschlüsselungsalgorithmus überhaupt brechen zu können. Und nimmt man nun die Verschlüsselungsalgorithmen mit 256 Bit Schlüssellänge, dann hat man es mit einem 32 stelligen Schlüssel zutun, den man berechnen muss, oder man ermittelt das Nutzerpasswort was diesen Schlüssel frei gibt. Zumindest ist das selbst für Supercomputer eine Mammutaufgabe, und technisch noch nicht möglich.