Inhaltsverzeichnis
Verschlüsselungsarten
Die Stärke der Sicherheit der drei besten Cipher/Verschlüsselungsarten ist wie folgt, der sicherste steht oben:
- serpent (der sicherste in
CryptSetup- ganzes Dateisystem verschlüsseln) - twofish (der sicherste in
GPG- einzelne Dateie verschlüsseln) → GPG-Verschlüsselung mit Passwort - blowfish (der sicherste in
openSSL- einzelne Dateie verschlüsseln) → OpenSSL-Verschlüsselung mit Passwort
- die derzeit sichersten und frei verfügbaren Verschlüsselungsverfahren, der Reihe nach:
- Serpent (wurde als "hochsicher" eingestuft) ⇒ Serpent wurde bezüglich seiner Sicherheit als einziger nicht kritisiert.
- Twofish (Nachfolger von Blowfish) ⇒ Bei Twofish wurden bezüglich seiner Sicherheit vor allem die Eigenschaften der Schlüssel-Teilung und seine Komplexität, die eine Sicherheitsanalyse beeinträchtigt, kritisiert.
- MARS ⇒ MARS wurde hinsichtlich seiner Sicherheit lediglich wegen seiner Komplexität, die eine Sicherheitsanalyse erschwert, kritisiert.
- Blowfish (mit einer ausreichend hohen Anzahl an Runden) ⇒ Es ist kein effizienter Angriff auf die Blowfish-Verschlüsselung mit voller Rundenzahl bekannt. Außer der Brute-Force-Methode ist kein Weg bekannt, den Algorithmus mit 16 Runden zu brechen. - Aber! Da Blowfish eine Blockgröße von 64 Bit verwendet, ist ein Geburtstagsangriff möglich.
- Advanced Encryption Standard (AES, Rijndael) ⇒ Rijndael wurde vor allem wegen seiner mathematischen Struktur, die möglicherweise zu Angriffen führen könnte, kritisiert. - Manche Kryptographen sehen in der mathematischen Eleganz und einfachen Struktur ein Problem. Auch ist ein Kritikpunkt, das Rijndael sich als Gleichungssystem beschreiben lässt.
- Verschlüsselungstechniken: Blockchiffren / Block-Cipher
Interessant ist auch die von der Beale-Chiffre abgeleitete Buch-Verschlüsselung für den Einsatz ohne EDV.
Hier hat "c't uplink" eine Sendung gemacht, in der u.a. auch von einer Verschlüsselungen gesprochen wird, die auch Quanten-Computer nicht knacken können:
CAMELLIA
Es ist eine Ablösung für 3DES, IDEA, RC2 und RC4.
Japans erste 128-Bit-Blockchiffre „Camellia“ wurde als neuer Standard-Verschlüsselungsalgorithmus im Internet zugelassen. Camellia ist international als Vertreter japanischer Verschlüsselungsverfahren und als einzigartige 128-Bit-Blockverschlüsselung anerkannt, der über die gleiche Sicherheitsstufe und Verarbeitungsfähigkeit wie AES verfügt. Tatsächlich wurde Camellia 2003 als von der EU empfohlene Verschlüsselung und von E-Government empfohlene Verschlüsselung ausgewählt und wurde kürzlich auch als internationale ISO/IEC-Standard-Verschlüsselung übernommen.
Firefox und Opera deaktivieren CAMELLIA. Warum? Ist er zu schwach oder ist es ein anderer Grund? Laut dieser Quelle sollen AES und CAMELLIA in etwa gleich stark sein…
Die Verschlüsselungen, die standardmäßig mit den Webbrowsern ausgestattet sind, beschränken sich auf diejenigen, die von der IETF als SSL/TLS-Standard übernommen wurden. Das heißt, wenn Camellia nicht vom SSL/TLS-Standard übernommen würde, könnte Camellia selbst im E-Government-System nicht mit den Webdiensten verwendet werden, obwohl Camellia bereits als von E-Government empfohlene Verschlüsselung ausgewählt wurde. Kurz gesagt, allein aufgrund der technischen Überlegenheit des Algorithmus und der Übernahme als De-jure-Standard usw. war er als Umgebung, die für Produkte und Dienstleistungen umfassend genutzt werden kann, unzureichend. Im Hinblick auf die wichtigsten verschlüsselten Kommunikationsprotokolle wie SSL/TLS und S/MIME hat die IETF die Internet-Verschlüsselungen Triple DES, IDEA, RC2 und RC4 als Standard übernommen, die vor 1995 erstellt wurden und daher zum Zeitpunkt der Standardisierung der Protokolle verfügbar waren. Unter diesen werden derzeit noch Triple DES und RC4 als Standards verwendet. Mit den jüngsten Fortschritten in der Chiffrierforschung sind jedoch Bedenken hinsichtlich der Sicherheit dieser Standardchiffren entstanden. Um dieses Problem anzugehen, hat die IETF zusätzliche Untersuchungen zu den Verschlüsselungsschemata der nächsten Generation durchgeführt, insbesondere zu den 128-Bit-Blockchiffren, die international als Verschlüsselungsverfahren der nächsten Generation empfohlen werden und sicherer sind als die 64-Bit-Blockchiffren Triple DES und RC4, von denen die Schwachstellen bereits bekannt sind.
CHACHA20
XChaCha20 ist ein 256-Bit-Stream-Verschlüsselungstyp und AES ist ein Block-Verschlüsselungstyp (128, 192 oder 256 Bit). Wie AES verschlüsselt XChaCha20 symmetrisch, indem es einen einzigen Schlüssel zum Verschlüsseln und Entschlüsseln von Daten verwendet. (Obwohl es auch eine asymmetrische Version davon gibt.) Anstatt Daten in Blöcke aufzuteilen, verschlüsselt XChaCha20 jedes Datenbit separat. Dadurch ist der Prozess deutlich schneller und weniger komplex als bei AES. Einige argumentieren, dass XChaCha20 dadurch eine bessere Wahl als AES ist.
Im Gegensatz zu 256-Bit-AES kann XChaCha20 ohne spezielle Hardware reibungslos ausgeführt werden, wodurch die Verschlüsselung einfacher zu implementieren und weniger anfällig für technische und menschliche Fehler ist.
AES
Advanced Encryption Standard (AES)
Eine von FIPS freigegebener Blockchiffre (Rijndael, 1998 veröffentlicht) die von US-Regierungsministerien und -Behörden zum Schützen von streng geheimen Informationen verwendet werden darf. 256-Bit-Schlüssel, 14 Runden, 128-Bit-Block (AES-256, 2001 veröffentlicht), LRW-Modus.
NIST hat Rijndael (AES) im Jahre 2000 als hinreichend sicher eingestuft
Blowfish
Entworfen 1993 von Bruce Schneier. 448-Bit-Schlüssel, 64-Bit-Block. TrueCrypt verwendet Blowfish mit 16 Runden im LRW-Modus.
CAST5
CAST5 (alias CAST-128) wurde von Carlisle Adams und Stafford Tavares entworfen und 1997 veröffentlicht. 128-Bit-Schlüssel, 64-Bit-Block, LRW-Modus. CAST5 darf sowohl für kommerzielle als auch für nicht-kommerzielle Zwecke lizenzfrei benutzt werden.
Der CAST5-Nachfolger CAST-256 war ein Kandidat in der AES-Challenge.
Serpent
Entworfen von Ross Anderson, Eli Biham, und Lars Knudsen; 1998 veröffentlicht; 256-Bit-Schlüssel; 128-Bit-Block; LRW-Modus. Serpent war einer der AES-Finalisten (es wurde angenommen, dass Serpent der sicherste der fünf Finalisten sei).
NIST hat Serpent im Jahre 2000 als hoch-sicher eingestuft, Serpent wurde bezüglich seiner Sicherheit nicht kritisiert;
Triple-DES
Triple-DES, 1978 veröffentlicht, benutzt 3 DES-Durchläufe; entwickelt von IBM und der NSA (1976). Triple-DES arbeitet im LRW-Modus und verwendet 3 voneinander unabhängige 56-Bit-Schlüssel (jeweils einen pro Durchlauf) und einen 64-Bit-Block. Hinweis: Diese Blockchiffre ist sehr langsam.
Twofish
Entworfen von Bruce Schneier, John Kelsey, Doug Whiting, David Wagner, Chris Hall and Niels Ferguson; 1998 veröffentlicht; 256-Bit-Schlüssel; 128-Bit-Block; LRW-Modus. Twofish war einer der AES-Finalisten.
NIST hat Twofish im Jahre 2000 als hoch-sicher eingestuft; Bei Twofish wurden bezüglich seiner Sicherheit vor allem die Eigenschaften der Schlüssel-Teilung und seine Komplexität, die eine Sicherheitsanalyse beeinträchtigt, kritisiert. Andererseits stellt Twofish laut seinem Entwickler-Team gerade durch diese Schlüsselteilung (key-dependent S-boxes) eine Sicherheitsarchitektur gegen noch unbekannte Angriffe dar.
MARS
Entworfen von IBM (Don Coppersmith); 1998 veröffentlicht; 128, 192 oder 256-Bit-Schlüssel; 128-Bit-Block; Feistelchiffre-Struktur; 32 Runden; MARS war einer der AES-Finalisten.
NIST hat MARS im Jahre 2000 als hoch-sicher eingestuft; MARS wurde hinsichtlich seiner Sicherheit lediglich wegen seiner Komplexität, die eine Sicherheitsanalyse erschwert, kritisiert.
RC6
Entworfen von Ronald L. Rivest, Matt Robshaw, Ray Sidney, Yiqun Lisa Yin; 1997 veröffentlicht; abgeleitet von RC5; 128, 192 oder 256-Bit-Schlüssel; 128-Bit-Block; Feistelchiffre-Struktur; 20 Runden; MARS war einer der AES-Finalisten.
NIST hat RC6 im Jahre 2000 als hinreichend sicher eingestuft
AES-Twofish
Zwei kaskadierte Blockchiffren im LRW-Modus. Jeder Block wird zuerst mit Twofish (256-Bit-Schlüssel) und anschließend mit AES (256-Bit-Schlüssel) verschlüsselt. Die beiden Schlüssel sind voneinander unabhängig.
AES-Twofish-Serpent
Drei kaskadierte Blockchiffren im LRW-Modus. Jeder Block wird zuerst mit Serpent (256-Bit-Schlüssel), dann mit Twofish (256-Bit-Schlüssel) und zum Schluss mit AES (256-Bit-Schlüssel) verschlüsselt. Die drei Schlüssel sind voneinander unabhängig.
Serpent-AES
Zwei kaskadierte Blockchiffren im LRW-Modus. Jeder Block wird zuerst mit AES (256-Bit-Schlüssel) und anschließend mit Serpent (256-Bit-Schlüssel) verschlüsselt. Die beiden Schlüssel sind voneinander unabhängig.
Serpent-Twofish-AES
Drei kaskadierte Blockchiffren im LRW-Modus. Jeder Block wird zuerst mit AES (256-Bit-Schlüssel), dann mit Twofish (256-Bit-Schlüssel) und zum Schluss mit Serpent (256-Bit-Schlüssel) verschlüsselt. Die drei Schlüssel sind voneinander unabhängig.
Twofish-Serpent
Zwei kaskadierte Blockchiffren im LRW-Modus. Jeder Block wird zuerst mit Serpent (256-Bit-Schlüssel) und anschließend mit Twofish (256-Bit-Schlüssel) verschlüsselt. Die beiden Schlüssel sind voneinander unabhängig.
Verschlüsselung von Daten
Verschlüsselung von Dateien
Verschlüsselung von Laufwerken/Partitionen
ZFS-Beispiel (FreeBSD + Linux)
allgemeine Vorbereitungen: ZFS-Pool ohne Mount-Point anlegen:
> zpool create -O encryption=aes-256-gcm -O keyformat=passphrase -m none HDD1000 /dev/sda
Enter new passphrase:
Re-enter new passphrase:
> zpool list HDD1000
NAME SIZE ALLOC FREE CKPOINT EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT
HDD1000 928G 209K 928G - - 0% 0% 1.00x ONLINE -
> zpool status HDD1000
pool: HDD1000
state: ONLINE
config:
NAME STATE READ WRITE CKSUM
HDD1000 ONLINE 0 0 0
sda ONLINE 0 0 0
errors: No known data errors
> zfs get mountpoint,compression,encryption HDD1000
NAME PROPERTY VALUE SOURCE
HDD1000 mountpoint none local
HDD1000 compression off default
HDD1000 encryption aes-256-gcm -
initialisieren: ZFS-Volumen mit Passwort anlegen:
> zfs create -o mountpoint=/HDD1000/test HDD1000/test > zfs list NAME USED AVAIL REFER MOUNTPOINT HDD1000 390K 899G 98K none HDD1000/test 98K 899G 98K /HDD1000/test > zfs list HDD1000/test NAME USED AVAIL REFER MOUNTPOINT HDD1000/test 98K 899G 98K /HDD1000/test > zfs get mountpoint,compression,encryption HDD1000/test NAME PROPERTY VALUE SOURCE HDD1000/test mountpoint /HDD1000/test local HDD1000/test compression off default HDD1000/test encryption aes-256-gcm -
Es ist auch möglich die einzelnen ZFS-Volumen mit unterschiedlichen Passwörtern zu verschlüsseln:
> zfs create -o encryption=aes-256-gcm -o keylocation=prompt -o keyformat=passphrase -o mountpoint=/HDD1000/test2 HDD1000/test2 Enter new passphrase: Re-enter new passphrase:
Bitte achten Sie darauf, dass das Passwort nicht zu kurz ist:
cannot create 'HDD1000/test2': Passphrase too short (min 8).
ZFS-Pool mit ZFS-Volumen aushängen:
> zpool export HDD1000
ZFS-Pool und ZFS-Volumen wieder einhängen:
> zpool import HDD1000 > zfs load-key -L prompt -a Enter passphrase for 'HDD1000': 1 / 1 key(s) successfully loaded > zfs mount -a > df -h /HDD1000/test Dateisystem Größe Benutzt Verf. Verw% Eingehängt auf HDD1000/test 900G 128K 900G 1% /HDD1000/test
ZFS-Volumen und ZFS-Pool löschen:
> zfs destroy HDD1000/test > zpool destroy HDD1000
Linux-Beispiel (cryptsetup mit Passwort)
allgemeine Vorbereitungen + mit Passwort initialisieren:
> cryptsetup benchmark > cryptsetup benchmark --cipher serpent > cryptsetup -y -c serpent-xts-plain -s 512 -h sha512 luksFormat /dev/sda1 > cryptsetup luksOpen /dev/sda1 cryptoluks > cryptsetup status cryptoluks > mkfs -t ext4 -m 0 -L Sphinx /dev/mapper/cryptoluks > cryptsetup luksClose cryptoluks > ls -lha /dev/mapper/
mit Passwort mappen + mounten:
> cryptsetup luksOpen /dev/sda1 cryptoluks > cryptsetup status cryptoluks /dev/mapper/cryptoluks is active. type: LUKS2 cipher: serpent-xts-plain keysize: 512 bits key location: keyring device: /dev/loop0 loop: /dev/sda1 sector size: 512 offset: 32768 sectors size: 1953488896 sectors mode: read/write > mount /dev/mapper/cryptoluks /mnt/ > df -h /mnt/ Dateisystem Größe Benutzt Verf. Verw% Eingehängt auf /dev/mapper/cryptoluks 916G 28K 916G 1% /mnt
unmounten + unmappen:
> umount /mnt > cryptsetup luksClose cryptoluks > ls -lha /dev/mapper/