Welche Verfahren nutzt ArchiCrypt Live
ArchiCrypt Live setzt per Voreinstellung den neuen AES (Advanced Encryption Standard) ein.
Dieser Algorithmus ging aus einem Wettbewerb als Sieger hervor, der 3 Jahre andauerte und in dem die vorgestellten Methoden strengsten Untersuchungen unterzogen wurden. Das Verfahren hat die Eigenschaft, dass die einzige Möglichkeit, unbefugt an Daten zu gelangen der s.g. Brute-Force Angriff ist. ArchiCrypt Live setzt die besonders sichere Variante mit einer Schlüssellänge von 256 BIT ein. Das von Ihnen eingegebene Passwort wird dabei nicht direkt eingesetzt, sondern dient als Eingangsgröße für eine s.g. kryptografische Einweg-Hash-Funktion. Die notwendige Funktion muss 256 BIT liefern, die gegen s.g. Kollisionsattacken resistent sind. Die Umsetzung in ArchiCrypt Live orientiert sich dabei am SHS (Secure Hash Standard) des NIST (National Institut of Standards and Technology) und setzt das Verfahren SHA ein.
(siehe auch Secure Hash Standard im Internet)
ArchiCrypt Live setzt gleichzeitig eine s.g. KDF (Key-Derivation-Function) ein. Dabei wird die SHA Funktion 1000 mal durchlaufen. Grundlage für dieses Verfahren war der PKCS #5 Password-Based Cryptography Standard, welcher klare Vorgaben macht.
In der Endausscheidung waren von den anfänglich 15 Verfahren noch 5 Kandidaten im Rennen.
Obwohl die Verfahren von zum Teil äußerst renommierten Firmen eingebracht wurden, waren bei einigen Methoden schnell Schwachstellen und Lücken entdeckt. Dies sollte uns einmal mehr davor warnen, ein Verfahren unter Ausschluss der Öffentlichkeit zu entwickeln. Glauben Sie auch keinem Unternehmen, welches Ihnen einen neuen selbst entwickelten Algorithmus verkaufen will. Die Versuchung dies doch zu tun, ist aber offensichtlich sehr hoch.
Die Methoden der Endrunde lieferten sich hinsichtlich der Leistungen ein Kopf an Kopf Rennen. Letztlich fiel folgende Entscheidung:
Rijndael: 86 Stimmen
Serpent: 59 Stimmen
Twofish: 31 Stimmen
RC6: 23 Stimmen
MARS: 13 Stimmen
Die Entscheidung zu Gunsten von Rijndael kam letztlich dadurch zu Stande, dass er die Anforderungen (siehe AES), die unterschiedlich gewichtet wurden, am besten erfüllte. Gleichzeitig bedeutet dies jedoch, dass die anderen Verfahren durchaus in bestimmten Einsatzgebieten bessere Eigenschaften aufweisen, als der Gewinner. Sicher, nach heutigem Verständnis, sind alle der oben aufgeführten Methoden.
Sicher bedeutet in diesem Zusammenhang, dass die beste Methode ohne Passwort an die Klartextdaten zu gelangen die s.g. Brute-Force Methode ist. Man geht den Daten sozusagen mit roher Gewalt an den Kragen und testet alle möglichen Passwörter durch, bis man das korrekte Passwort erwischt hat.
Verschlüsselungsverfahren werden in einem bestimmten Modus aufgeführt (z.B. ECB - Electronic Code Book oder CBC Cipher Block Chaining).
ArchiCrypt Live greift seit Version 6 auf den Standard SISWG (Security in Storage Workgroup) (P1619.0 December 19, 2007 - Standard Architecture for Encrypted Shared Storage Media) – 
www.siswg.org zurück. In diesem Standard wird das Verfahren XTS-AES oder kurz XEX-Verfahren beschrieben.
XEX ist ein Modus in dem AES ausgeführt wird. Es gibt 2 Schlüssel, die jeweils 256 BIT (256 BIT AES Verschlüsselung ECB und 256 BIT AES Verschl. Tweak) lang sind.
Warum XEX?
Von 2004 - 2006 war im Entwurf des P1619 AES im LRW Modus vorgesehen, eine Testabstimmung im August 2006 zeigte, dass die meisten SISWG Mitglieder dem Entwurf so nicht zustimmen würden. Man wechselte daher von LRW-AES zu XEX-AES (auch XTS-AES ab. Entwurf 11).
Gründe für die fehlende Unterstützung durch die SISWG Mitglieder:
- Ein Angreifer kann unter bestimmten Voraussetzungen den LRW Tweak Schlüssel ableiten, wenn der Klartext den Tweak Schlüssel selbst und einen Nullblock enthält.
- Wenn der Tweak Schlüssel bekannt ist (dies war zunächst sogar so vorgesehen [Tweak Key nicht geheim; in ArchiCrypt Live jedoch nicht umgesetzt, sondern ebenfalls geheim) ist die LRW Variante nicht mehr von der ECB Variante zu unterscheiden. Der Verlust des Tweak Schlüssels wirkt sich jedoch nicht auf die Sicherheit des Algorithmus im ECB Modus aus.
Ein weiterer wichtiger Grund ist die höhere Geschwindigkeit von XEX gegenüber LRW AES.
/* SINGLE 128 BIT block
The XEX-AES encryption procedure for a single 128-bit block is modeled with this equation:
C = XEX-AES-blockEnc(Key, P, i, j)
where:
Key is the 256, 320, or 384 bit XEX-AES key
P is a block of 128 bits (i.e., the plaintext)
i is a 128-bit tweak value, representing the number of the data unit (see clause 6.1)
j is the sequential number of the 128-bit block inside the data unit
C is the block of 128 bits of ciphertext resulting from the operation
The key is parsed as a concatenation of two fields, Key = Key1 | Key2, with Key2
consisting of the last 128 bits of Key and Key1 consisting of the first 128, 192, or 256 bits.
The ciphertext shall then be computed by the following or an equivalent sequence of
steps:
j
1. T = AES-enc(Key2,i) GFMUL (GF(2) mod x^128+x^7+x^2+x+1
2. PP = P XOR T
3. CC = AES-enc(Key1 ,PP)
4. C = CC XOR T
AES-enc(K,P) is the procedure of encrypting plaintext P using AES algorithm with key
K, according to FIPS-197. The multiplication and computation of power in line 1 is
128 executed in GF(2 ) field.
*/
/* 128 oder mehr BIT
The XEX-AES encryption procedure for a data unit of plaintext of 128 or more bits is modeled with this
equation:
C = XEX-AES-Enc(Key, P, i),
where
Key is the 256, 320, or 384 bit XEX-AES key
P is the plaintext
i is a 128-bit tweak, representing number of the data unit (see clause 6.1)
C is the ciphertext resulting from the operation, of the same bit-size as P
The plaintext data unit is first partitioned into m+1 blocks,
P = P0 … Pm 1Pm
where m is the largest integer such that 128m is no more than the bit-size of P, the first m
blocks P0,…, Pm 1 are all exactly 128-bit long, and the last block Pm is between 0 and
127-bit long. The ciphertext C is then computed by the following or an equivalent
sequence of steps:
1. for q=0 to m-2
2. Cj = XEX-AES-blockEnc(Key, Pj, i, q) //
3. endfor
4. b = bit-size of Pm
5. if b=0
6. Cm-1 = XEX-AES-blockEnc(Key, Pm-1, i, m-1) //
7. Cm = empty
8. else
// Pm is a partial block
9. CC = XEX-AES-blockEnc(Key, Pm-1, i, m-1) //
10. Cm = first b bits of CC
11. CP = last (128-b) bits of CC
12. PP = Pm | CP
// PP is a 128-bit block
13. Cm-1 = XEX-AES-blockEnc(Key, PP, i, m) //
14. endif
15. C = C1 … Cm-1 Cm
*/
Informationen über die Verfahren erhalten Sie unter den angegebenen Internetadressen:
•MARS - IBM
•RC6 - RSA Laboratories
•RIJNDAEL - Joan Daemen, Vincent Rijmen
•Serpent - Ross Anderson, Eli Biham, Lars Knudsen
•Twofish - Bruce Schneier, John Kelsey, Doug Whiting, David Wagner, Chris Hall, Niels Ferguson
•Blowfish - Bruce Schneier
Um den sicheren Versand zu realisieren und die Funktionen zur Signatur bereitzustellen, nutzt ArchiCrypt Live das berühmte RSA Verfahren. Es wurde im Jahre 1977 von Ron Rivest, Adi Shamir und Leonard Adleman entwickelt. Das Verfahren basiert auf der Tatsache, dass es zwar ohne Weiteres möglich ist, das Produkt n zweier großer Primzahlen p und q zu berechnen, der umgekehrt Weg, die beiden Primzahlen aus dem Produkt zu berechnen (faktorisieren), derzeit technisch eine unüberwindbare Hürde darstellt.
Der RSA-Algorithmus nutzt diese Eigenschaft, indem er als öffentlichen Schlüssel eine Zahl O und als privaten Schlüssel eine weitere Zahl R verwendet, die aus diesen beiden Primzahlen p und q über ein Verfahren gebildet werden. Die Primzahlen p und q werden hingegen nicht veröffentlicht!
Die Schlüssel, die ArchiCrypt Live generiert und zur Verschlüsselung und zur Signatur einsetzt, haben eine Bitlänge von 1024. Zum Signieren wird MD5 (Message Digest 5) verwendet. MD5 definiert ein Verfahren zur Erzeugung digitaler Unterschriften; es ist in RFC 1321 (RFC = Request for comment) definiert.
Alle der aufgeführten Verfahren sind als Referenzimplementierung in der Programmiersprache C, teilweise auch in Java frei verfügbar. Zudem gibt es für jedes Verfahren s.g. Testvektoren, mit denen man sicherstellen kann, dass die Implementation der Verfahren korrekt ist.
