© 2017 W.Ehrhardt Letzte Änderung 21. Apr 2017
Start CRC/Hash Krypto Sonstiges Info Links English

Kryptographische Algorithmen


Auf dieser Seite sind verschiedene Verschlüsselungs-Algorithmen zu finden: die 128-Bit-Blockchiffren AES und Twofish, die 64-Bit-Blockchiffre Blowfish, sowie die Stromchiffren Salsa20/XSalsa20/ChaCha und Sosemanuk. Bitte beachten: Im Abschnitt Weitere Blockchiffren sind ein paar zusätzliche Blockchiffren mit Kurzbeschreibungen und Quellcode-Archiven zu finden: AnubisCamelliaSEEDSerpentSHACAL-2SkipJackXTEA.

Die Basis-, Test-, Demo-Quellcodes sind mit vielen gängigen Pascal- (TP 5/5.5/6, BP 7, VP 2.1, FPC 1.0/2.0/2.2/2.4/2.6/3.x) und Delphi-Compilern übersetzbar (getestet mit Versionen V1 bis V7/9/10-12/17-18).

Vor dem Herunterladen von Software von diesen Seiten bitte diesen rechtlichen Hinweis beachten.


A E S

Hier gibt es AES (Advanced Encryption Standard) bezogene Pascal / Delphi - Quellcodes: Die eigentlichen AES-Basis-Routinen und Betriebsmodi (mit Test-Programmen, die Kompilierung und Ergebnisse verifizieren), Demo-Programme für Authentizität / Verschlüsselung und Verifikation / Entschlüsselung von Dateien, sowie einen Vergleich mit anderen Implementationen.


Letzte Änderungen:  Verifikation/Vergleich in konstanter Zeit für die Komplettpaket-Funktionen (aes_eax, aes_gcm, aes_ccm)

Der Code auf Blockebene in aes_2015-09-14.zip enthält separate Units für Ver- und Entschlüsselung; der Quellcode für die Basisroutinen ist in mehrere Include-Dateien aufgeteilt. Auf der untersten Ebene findet man Typ-Definitionen und gemeinsame Hilfsroutinen. Es werden die Schlüssellängen von 128, 194 und 256 Bit unterstützt.

Aufbauend auf die Basisroutinen werden folgende Betriebsmodi implementiert: CBC, CFB128, CFB8, CTR, ECB, OFB sowie OMAC, CMAC, CCM, EAX, GCM, XTS. Alle Modi erlauben Klar- und Schlüssel-Textlängen, die nicht Vielfaches der Blocklänge sind (für ECB, CBC und XTS wird "cipher text stealing" für einen letzten kurzen Block benutzt; nur höchstens ein kurzer Block ist erlaubt und davor muß mindestens ein vollständiger Block vorhanden sein). Der CTR-Modus hat vier vordefinierte und erlaubt benutzerdefinierte Inkrement-Funktionen, außerdem Seek-Funktionen für wahlfreies Lesen.

Alle AES-Routinen sind in der AES_DLL.DLL vorhanden: Es gibt zwei Interface-Units für die DLL, eine für Virtual Pascal, die zweite für die anderen Win32-Compiler. Das Quell-Code-Archiv enthält viele Testprogramme, die die Übersetzung (sprich Syntax) verifizieren, die Ergebnisse mit bekannten Testwerten vergleichen usw.

Mit t_gsp128 wurden die CPU-Zyklen pro Block und die (theoretische) Verarbeitungs-Geschwindigkeit in MB/s für die verschiedenen Compiler gemessen (dieses Programm braucht den hochauflösenden Zeitmesser aus hrtimer). Hier sind die Ergebnisse für Pentium 4, 1.8 GHz, Win98, Schlüssellänge 128 Bit; die ersten Datenpaare (-F) sind für große Tabellen, die zweiten (-C) für komprimierte Tabellen (ausgerichtet auf 8-Byte-Grenzen bei 32-Bit-Compilern).

Compiler Cyc/Bl-F MB/s-F Cyc/Bl-C MB/s-C
TP5 6302 4.6 5356 5.4
TP55 6321 4.5 6980 4.1
TP6 1436 20.0 1762 16.3
BP7 1493 19.2 1927 14.9
Delphi2 365 78.6 398 72.1
Delphi3 373 76.9 398 72.1
Delphi4 386 74.3 398 72.1
Delphi5 375 76.5 398 72.1
Delphi6 380 75.5 398 72.1
Delphi7 380 75.5 398 72.1
Delphi9 381 76.3 397 72.3
Delphi10 380 75.0 398 72.1
VPC 426 67.3 425 67.3
FPC 2.2 -O3 416 69.0 417 68.8
FPC 1 GoV2 542 53.0 541 53.1

TP5 und 5.5 haben puren 8086 Pascal-Code, TP6/BP7 verwenden 16 Bit 80386 BASM-Code in der Kern-Verschlüsselungs-Prozedur; der Code für Delphi 2..7/9/10/12/17, VPC und FPC besteht aus 100% reinem 32 Bit Pascal.



In der folgenden Tabelle werden meine Routinen (WE/.., Programm t_aes_ws) mit anderen Opensource - Paketen verglichen. Der Quellcode für die Testprogramme zu diesen Paketen ist in aes_cmpsrc_2006-07-30.zip, der Quellcode der anderen Pakete wird selbstverständlich auch benötigt, die URLs sind auf der Linkseite zu finden. Die Zeiten sind in s, es wurden 512 MB (8000000 Blöcke mit 64 Bytes) mit 128-Bit-Schlüssel auf 1.8 GHz P4 unter Win98 verschlüsselt.

Paket/Compiler CTR CFB OFB ECB CBC OMAC
LibTom117/VC6 13.0 16.3 16.4 12.9 13.9 15.6
LTC117/GCC4.2.1 10.1 14.5 10.6 9.0 9.3 14.2
dcpcrypt2/D6 28.8 32.7 28.6 - 32.7 -
DEC5.1/D6 - 13.9 10.9 10.2 11.8 -
StrSecII/D6 9.0 11.5 9.1 7.7 9.3 -
WE/D3 9.0 8.1 8.1 7.7 9.1 9.1
WE/D6 9.0 8.0 8.0 7.7 8.4 9.1
WE/FPC 2.2 -O3 9.9 9.1 9.1 9.0 11.2 9.0
WE/VPC 2.1 10.4 10.2 10.3 9.3 13.9 12.0
WE/BP7 47.1 41.4 41.4 34.3 51.0 45.3


Der Vergleich mit einer der schnellsten bekannten Opensource-Implementation (Brian Gladmans C/ASM-Code) ist etwas ausführlicher. Mit dem Programm t_gspeed wurden die Zyklen pro Block der Ver- und Entschlüsselung für alle AES-Schlüssellängen bestimmt, und zwar mit der gleichen Methode, die Gladman in seinem aestmr.cpp verwendet. ASM ist Gladmans hochoptimierte NASM-Version, C++ seine optimierte Standard-Version, der Rest meine Versionen wie oben.

Fkt/Bit ASM C++ D6 VP FPC2 BP7
Enc/128 295 385 370 425 546 1490
Dec/128 293 376 382 405 551 1545
Enc/192 352 439 434 532 648 1768
Dec/192 346 443 451 476 653 1723
Enc/256 403 497 498 580 751 1948
Dec/256 407 507 518 549 755 1971


Beginnend mit der Ausgabe vom Juli 2006 gibt es Conditional defines zur Verwendung komprimierter Tabellen: Eine 2K-Tabelle (berechnet mit t_mkctab) für die Verschlüsselung ersetzt die vier 1K-Tabellen; analog für die Entschlüsselung, hier wird darüber hinaus die inverse SBox nicht mehr benötigt. Neben dem kleineren Speicherbedarf werden komprimierte Tabellen als Maßnahmen gegen Cachetiming-Angriffe verwendet.

Es scheint, daß moderne x86-Prozessoren die nicht ausgerichteten, überlappenden Tabellendaten aus dem Cache mit minimalem Zeitverlust verwenden, WENN (und das ist eine großes Wenn) die Tabellen als ganze auf 8-Byte-Grenzen ausgerichtet sind. Leider hat Delphi keine einfache Sprachmöglichkeit, diese Ausrichtung zu erzwingen. Deshalb gibt es ein paar weitere Definitionen und Variablen zum Erreichen der Ausrichtung (gesammelt in der Konfigurations-Datei aes_conf.inc). Wenn die komprimierten Tabellen nicht entsprechend ausgerichtet sind, verdoppeln sich bei 32-Bit-Code nahezu die Zeiten.

Eine weitere Maßnahme gegen Cachetiming-Angriffe ist das automatische Abschalten der Verwendung der speziellen großen Tabellen für die letzten Runden (die komprimierten Tabellen enthalten für diesen Zweck Kopien der SBox- und InvSBox-Bytes).

Komprimierte Tabellen sollten verwendet werden, wenn ein Angreifer Zugriff auf Zeitverlaufsdaten hat, er könnte bei einer ausreichenden Datenmenge Teile des oder den gesamten Schlüssel ermitteln. Hier sind einige Referenzen zu Hintergrundmaterial zum Thema Cachetiming-Angriffe auf AES:
Die AES-Basisroutinen werden benutzt für das einfache FCA-Demoprogramm zur Authentizität / Verschlüsselung und Verifikation / Entschlüsselung von Dateien (ein Dual-OS-Programm, das als 16-Bit-EXE unter DOS und als 32-Bit-Konsol-Applikation incl. Support für lange Dateinamen unter Win32 läuft). FCA unterstützt zwei Modi, der alte (angeregt durch Brian Gladmans encfile) benutzt 128 Bit AES-CTR-Mode mit HMAC-SHA1-128, der neue verwendet EAX. Das 96 Bit salt ist ein verkürztes SHA1-Hash über Datum, Zeit, randseed und TSC; Schlüssel und Passwort-Verifikator werden gemäß RFC 2898 aus dem verwendeten Passwort abgeleitet.

Seit Nov. 2006 enthält das Archiv die fcaes256-Unit, die von Giorgio Tani begonnen wurde: Sie benutzt den 256-Bit AES-EAX-Modus oder AES-CTR plus HMAC-Whirlpool-128; fcaes256 wird u.a. in Giorgios PeaZip-Projekt verwendet. fca256 ist das 256-Bit-Äquivalent zu FCA.

Im März 2016 hat Giorgio Tani analoge Units für die AES-Finalisten Serpent und Twofish beigesteuert, sie sind im Archive enthalten zusammen mit vier Testprogrammen.

Letzte Änderung:  Zusätzliche Units und Testprogramme basierend auf Serpent und Twofish.

Zum Selbstkompilieren des Quellcodes aus fca_2016-05-01.zip werden Units von aes_2015-09-14.zip, util_JJJJ-MM-TT.zip und crc_hash-JJJJ-MM-TT.zip benötigt; die Serpent/Twofish-Units zusätzlich die entsprechenden Archive. Das FZCA-Programm komprimiert optional die Daten vor der Verschlüsselung mit zlib.

Achtung: die Demoprogramme sollten nur auf Dateien mit weniger als 2 GB angewendet werden, wenn Delphi oder 16-Bit-Pascal als Compiler benutzt wird (Delphi eof-Fehler und/oder 32-Bit filesize Funktion). Neuere FreePascal-Versionen mit 64-Bit filesize Funktion können vielleicht mit solch großen Dateien korrekt umgehen.


Twofish

Der Twofish-Algorithmus wurde als Reaktion auf Anwenderwünsche als Alternative zu AES aufgenommen. Das Quellcode-Layout in tf_2013-01-07.zip für Twofish ist ähnlich zum AES-Layout: Es gibt Code für eine DLL und zwei Interface-Units, die Betriebsmodi CBC, CFB128, CTR, ECB, OFB, OMAC und EAX werden unterstützt. Alle Modi erlauben Klar- und Schlüssel-Textlängen, die nicht Vielfaches der Blocklänge sind, und sie unterstützen (ausgenommen OMAC/EAX) eine reset-Funktion, die nur die Verkettungs-Variablen re-initialisiert ohne die Rundenschlüssel neu zu berechnen. Für ECB und CBC wird "cipher text stealing" für einen letzten kurzen Block benutzt, und der CTR-Modus hat 4 eingebaute Inkrement-Funktionen, benutzerdefinierte Funktionen und Seek-Funktionen für wahlfreies Lesen.

Letzte Änderung:  D17/64-Bit-Anpassungen

Meine Implementation wird mit den gleichen bzw. aktualisierten Paketen wie im AES-Teil verglichen. Den Quellcode für die entsprechenden Testprogramme findet man in tf_cmpsrc_2006-06-15.zip. Die Zeiten sind in s, es wurden 512 MB (8000000 Blöcke mit 64 Bytes) mit 128-Bit-Schlüssel auf 1.8 GHz P4 unter Win98 verschlüsselt.

Paket/Compiler CTR CFB OFB ECB CBC OMAC
LibTom112/VC6 11.9 14.6 14.4 10.3 11.2 14.4
LTC112/GCC4.0.1 13.4 14.9 13.5 12.5 11.7 14.2
dcpcrypt2/D6 21.5 25.4 21.3 - 25.7 -
DEC5.1/D6 - 31.9 28.7 27.7 29.6 -
StrSecII/D6 13.0 14.7 13.0 10.7 12.1 -
WE/D3 14.8 14.0 13.9 13.8 16.0 16.3
WE/D6 15.2 14.0 13.9 13.9 15.6 15.0
WE/FPC2 20.4 20.4 20.3 19.5 21.9 20.1
WE/VPC 17.6 17.3 17.6 17.0 22.9 18.4
WE/BP7 72.0 68.5 67.9 61.6 76.0 72.2



Blowfish

Das Quellcode-Layout in bf_2013-12-02.zip für Blowfish ist ähnlich zum AES-Layout. Es gibt Code für eine DLL und zwei Interface-Units. Die Betriebsmodi CBC, CFB64, CTR, ECB, OFB, OMAC und EAX werden unterstützt. Alle Modi erlauben Klar- und Schlüssel-Textlängen, die nicht Vielfaches der Blocklänge sind (für ECB und CBC wird "cipher text stealing" für einen letzten kurzen Block benutzt). Der CTR-Modus hat 4 eingebaute Inkrement-Funktionen und erlaubt benutzerdefinierte Funktionen, außerdem Seek-Funktionen für wahlfreies Lesen.

Alle Modi (bis auf OMAC/EAX) unterstützen eine reset-Funktion, die nur die Verkettungs-Variablen re-initialisiert ohne die Rundenschlüssel neu zu berechnen (bei Blowfish sehr zeitaufwendig).

Letzte Änderung:  Neue BCrypt-Unit für OpenBSD-kompatibles Passwort-Hashing

Meine Implementation wird mit den gleichen bzw. aktualisierten Paketen wie im AES-Teil verglichen. Den Quellcode für die entsprechenden Testprogramme findet man in bf_cmpsrc_2006-06-15.zip. Die Zeiten sind in s, es wurden 512 MB (8000000 Blöcke mit 64 Bytes) mit 128-Bit-Schlüssel auf 1.8 GHz P4 unter Win98 verschlüsselt.

Paket/Compiler CTR CFB OFB ECB CBC OMAC
LibTom112/VC6 12.0 14.1 13.8 11.3 15.6 16.7
LTC112/GCC4.0.1 13.1 12.8 11.8 9.9 10.5 17.8
dcpcrypt2/D6 21.0 28.5 20.8 - 30.3 -
DEC5.1/D6 - 13.7 12.0 12.1 13.7 -
StrSecII/D6 14.1 15.1 14.0 10.9 13.5 -
WE/D3 14.0 12.2 10.8 10.2 12.4 11.5
WE/D6 14.1 12.3 10.8 10.6 12.4 11.4
WE/FPC2 18.2 17.4 18.8 14.5 16.8 16.5
WE/VPC 20.0 21.0 19.2 19.2 26.3 22.6
WE/BP7 64.8 57.1 57.1 40.7 72.8 58.3


Salsa20 / XSalsa20 / ChaCha

Salsa20 von D.J. Bernstein ist eine Stromchiffre, die in das abschließende eSTREAM-Portfolio aufgenommen wurde. Der Basis-Algorithmus von Salsa20 ist eine Hashfunktion mit 64 Bytes Eingabe und 64 Bytes Ausgabe, die Eingabeblöcke setzen sich u.a. aus dem 128- bzw. 256-Bit Schlüsselmaterial, dem Initialisierungs­vektor und der Blocknummer zusammen. Die Ausgabe der Hashfunktion wird als Pseudo-Zufalls-Bytefolge benutzt oder zum Verschlüsseln mit dem Klartext gexort.

Letzte Salsa-Änderungen:  Verbesserter PurPascal-Code (schnellere umgeordnete Salsa20_wordtobyte-Routine)

Die Original-ECRYPT-Spezifikation verlangt 20 Runden (bzw. 10 Doppelrunden) für die Hashfunktion, aber D.J. Bernstein selbst hat formal zwei Varianten mit 8 bzw. 12 Runden vorgeschlagen; die Portfolioversion hat 128-Bit-Schlüssel und 12 Runden. Meine Standardwerte sind 12 Runden für 128-Bit- und 20 Runden für 256-Bit-Schlüssel.

In der folgenden Tabelle werden meine Implementationen (Programm t_salwe, 1.8 GHz P4 unter Win98) mit dem Referenz-C-Code und dem ASM-Code von D.J. Bernstein verglichen. Es wurden die Zeiten in s für die Verarbeitung von 576 MB (1 Mio 576-Byte-Blöcke) gemessen: Die Spalten kx zeigen die Werte für die Pseudo-Zufallsstrom-Erzeugung mit x Runden, die ex-Spalten stellen die entsprechenden Zeiten für die Verschlüsselung dar (es wurden immer 128-Bit-Schlüssel verwendet). Der Referenz-C-Code ist nicht optimal, da der Zufallsstrom durch Verschlüsselung eines 0-Stroms erzeugt wird.

Compiler k8 k12 k20 e8 e12 e20 Bem.
ASM P4 F12 - - - 2.54 3.62 5.57 (1)
GCC 4.3.2 -O3 5.71 7.36 9.50 5.44 7.03 9.12 (2)
VC6 SP4 /O2 6.65 8.29 11.59 6.37 8.07 11.37 (2)
Delphi 3 3.57 4.93 7.93 6.16 7.53 10.23 -
Delphi 6 3.57 4.94 7.94 6.25 7.62 10.32 -
Delphi 10 3.57 4.93 7.94 6.12 7.48 10.21 -
VPC 2.1.279 4.40 5.77 8.51 6.89 8.25 10.98 -
FPC 2.2.4 -O3 4.57 5.93 8.66 7.92 9.33 11.92 -
BP7 Real 4.85 6.19 8.88 5.34 6.68 9.37 -

(1) Berechnet nach D.J. Bernsteins Zyklenzahl für 576 Bytes
(2) Modifizierter Referenzcode mit statischer rounds Variable

Meine Quellcode-Implementation im Archiv salsa_2015-09-14.zip benutzt BASM für die Basis-Hashfunktion (PurPascal bei BIT64, TP5.X verwendet Pascal mit inline rotate).

Salsa20 wird als kryptographischer Zufallszahlen-Generator in der salsar-Unit eingesetzt, mehr dazu im PRNG-Abschnitt auf der Sonstiges-Seite.

XSalsa20 benutzt 256-Bit-Schlüssel und 192-Bit-IVs, es gibt keine separaten Schlüssel/IV-Initialisierungen und die Paketverarbeitungs-Funktionen haben keinen Benutzer­kontext.

ChaCha ist eine von D.J. Bernstein vorgeschlagene Salsa-Variante mit verbesserter Diffusion pro Runde (und vermuteter erhöhter kryptanalytischer Resistenz). Meine Implementation erlaubt 128/256-Bit Schlüssel, die ChaCha-Funktionen sind exakte Gegenstücke zu den Salsa-Funktionen, mit der Ausnahme, daß chacha_xkeysetup jede gerade Anzahl > 0 von Runden erlaubt. Besonderer Dank geht an EddyHawk, der die Implementation der ChaCha-Variante nachgefragt und selbst Funktionen beigesteuert hat, und an Martok für seinen optimierten PurPascal-Quellcode.


Sosemanuk

Sosemanuk von C. Berbain et al. ist eine Stromchiffre, die in das abschließende eSTREAM-Portfolio aufgenommen wurde. Die Schlüssellängen variieren zwischen 128 und 256 Bit, IVs bis zu 128 Bit werden unterstützt (mein Code verlangt jedoch 128-Bit IVs). Für die Schlüssel- und IV-Initialisierung wird eine reduzierte Variante der Serpent-Blockchiffre eingesetzt. Der zentrale Stromgenerator arbeitet mit 80-Byte-Blöcken und benutzt u.a. ein LFSR (linear rückgekoppeltes Schieberegister) mit zehn 32-Bit Werten und ein FSM (endlicher Automat, Finite State Machine) mit 64 Bit.

Letzte Änderungen:  D17/64-Bit-Anpassungen

In der folgenden Tabelle werden meine Implementationen (Programm t_sosewe, 1.8 GHz P4 unter Win98) mit dem Referenz-C-Code aus dem eSTREAM-Archive verglichen (Zeilen GCC und VC6). Zeiten und Geschwindigkeiten für die Verarbeitung von 800 MB (1 Mio 800-Byte-Blöcke) wurden gemessen für die Strom-Erzeugung (Spalten k) und die Verschlüsselung (Spalten e); beide Werte sind unabhängig von der Schlüssellänge.

Compiler   k [s] k [MB/s]   e [s] e [MB/s]
GCC 4.3.2 -O3 7.253 110.3 10.220 78.3
VC6 SP4 /O2 7.520 106.4 10.930 73.2
Delphi 3 3.022 264.7 6.868 116.5
Delphi 6 3.013 265.5 6.897 116.0
Delphi 10 3.634 220.1 7.565 105.7
VPC 2.1.279 4.613 173.4 8.356 95.7
FPC 2.2.4 -O3 6.284 127.3 11.543 69.3
BP7 Real 5.490 145.7 7.679 104.2

Mein Quellcode im Archiv sosemanuk_2013-01-07.zip für die 32-Bit-Compiler und den 16-Bit-Stromgenerator basiert auf der eSTREAM-Datei sosemanukfast.java, die 16-Bit Schlüssel- und IV-Initialisierung verwendet eine Modifikation meiner Serpent-Implementation.


Weitere Blockchiffren

Letzte Änderungen:  Verifikation/Vergleich in konstanter Zeit für Camellias Komplettpaket-Funktionen (cam_eax, cam_ccm)

Das Quellcode-Layout ist wie üblich; die Betriebsarten CBC, CFB, CTR, ECB, OFB werden unterstützt; Anubis, Camellia, Serpent und SEED haben außerdem OMAC und EAX. Der CCM-Modus ist für Camellia implementiert.

Poly1305

Poly1305-AES (entworfen von D. J. Bernstein) ist ein Einmal-Authentifizierungs-Algorithmus, geeignet für eine Vielzahl von Anwendungen, er verwendet mit AES-128 erzeugte Schlüssel und Nonce (number used once, Einmal-Zahl).

Der allgemeine Poly1305-Algorithmus berechnet zu einer Nachricht und einem 32-Byte großen Einmal-Schlüssel eine 16-Byte Prüfgröße (engl. tag). Das tag wird dann benutzt, um die Nachricht zu authentifizieren. Unabhängig davon wie der Schlüssel erzeugt wird, wird er in zwei Teile unterteilt (bezeichnet mit "r" und "s"). Das Paar (r, s) sollte eindeutig und darf nicht vorhersehbar sein, allerdings kann "r" konstant sein.

Mein Pascal-Code im Archiv poly1305_2016-05-01.zip ist eine direkte Übersetzung zweier Variationen von Andrew Moons bekanntem Poly1305-donna-Code (von Github, unter MIT-Lizenz oder Publicdomain): Poly1305 ist standardisiert im RFC 7539 ("ChaCha20 and Poly1305 for IETF Protocols"), das Dokument enthält auch zusätzliche Testvektoren.
Start CRC/Hash Krypto Sonstiges Info Links English