Hauptseite Dokumentation Forum Tracker Herunterladen

Unterstützte Algorithmen

Cumulus4j verwendet standardmäßig sehr schnelle und hochsichere Algorithmen. Daher empfehlen wir Ihnen, einfach die Standardeinstellungen zu verwenden. Doch abhängig von Ihrer Hardware oder Ihren persönlichen Vorlieben bervorzugen Sie vielleicht eine andere Konfiguration.

Zum Beispiel verwendet Cumulus4j standardmäßig TWOFISH mit einer Schlüssellänge von 256 Bit. Diese Schlüssellänge grenzt an Paranoia und vielleicht möchten Sie ja auf nur 128 Bit wechseln, um etwas mehr Leistung zu gewinnen.

Mit 256-Bit-Schlüsseln ist TWOFISH sicherer als AES. Außerdem ist Twofish auf der meisten Hardware schneller. Mit bestimmten CPUs jedoch oder mit nur 128 Bit Schlüssellänge ist AES etwas schneller als Twofish. Und bei nur 128 Bit Schlüssellänge sind beide Algorithmen auch etwa gleich sicher.

Im Folgenden finden Sie eine Liste aller unterstützten Möglichkeiten. Aber:

Wichtig: Änderungen an den Einstellungen der Verschlüsselung können dazu führen, daß Cumulus4j nicht mehr funktioniert oder - noch viel schlimmer - daß es nicht mehr sicher ist!!! Ändern Sie daher nur dann die Einstellungen, wenn Sie wirklich verstehen, was Sie da tun!

Wenn Sie unsicher sind, bleiben Sie besser bei den "empfohlenen Möglichkeiten"!

Symmetrische Verschlüsselung

Symmetrische Verschlüsselung wird verwendet, um die Daten in Ihrer Datenbank sicher abzulegen. Da hierfür geheime Schlüssel notwendig sind, bietet Cumulus4j einen Schlüsselspeicher (auch "Key-Store" genannt), der seinerseits wiederum mittels symmetrischer Verschlüsselung die geheimen Schlüssel geschützt abspeichert (für den Fall, daß Sie Ihren Key-Store verlieren - z.B. auf einem USB-Speicher-Stick - oder daß jemand ihn stiehlt).

Empfohlene Möglichkeiten

Obgleich Sie aus zahlreichen Algorithmen für Verschlüsselung, Block-Modus, Füllung (auch "Padding" genannt) und Nachrichtenauthentifizierungs-Code (auch "MAC" genannt) wählen können, funktionieren nicht alle Kombinationen mit Cumulus4j. Einige funktionieren vielleicht, ergeben jedoch keinen Sinn; z.B. einen authentifizierenden Block-Modus mit einer MAC gemeinsam zu verwenden, bedeutet 2 (redundante!) Nachrichtenauthenfikationen zu benutzen, was das System nur unnötig ausbremst, ohne zusätzliche Sicherheit zu bringen.

Daher bieten wir Ihnen hier eine kleine Auswahl von sinnvollen Möglichkeiten, die Sie vielleicht gegenüber den Standardeinstellungen bevorzugen:

VerschlüsselungsverfahrenBlock-ModusFüllungMAC
AESGCMNoPaddingNone
AESCFBNoPaddingHMAC-SHA1
AESCBCPKCS5HMAC-SHA1
TwofishGCMNoPaddingNone
TwofishCFBNoPaddingHMAC-SHA1
TwofishCBCPKCS5HMAC-SHA1

"Verschlüsselungsverfahren", "Block-Modus" and "Füllung" werden üblicherweise zusammen in eine Zeichenkette wie "AES/GCM/NoPadding" geschrieben (also mittels "/" separiert). Der Nachrichtenauthentifizierungs-Code (MAC) wird meist separat konfiguriert.

Auf der Seite Persistenz-API ist dokumentiert, wie Sie dies für den eigentlichen Datenspeicher konfigurieren und auf Schlüsselspeicher sehen Sie, wie Sie die verschiedenen Verschlüsselungs-/MAC-Einstellungen auf den Key-Store anwenden.

Blockchiffre-Verfahren

Blockchiffren sind die meist-verwendeten Verschlüsselungsalgorithmen. Sie kombinieren sehr hohe Sicherheit mit guter Leistung.

Stromchiffre-Verfahren

Stromchiffren können anstelle von Blockchiffren verwendet werden. Sie sind üblicherweise schneller, jedoch auch anfälliger für ernste Sicherheitsprobleme, wenn sie inkorrekt verwendet werden. Allerdings glauben wir, daß Cumulus4j sie korrekt verwendet - z.B. indem lange IVs zur Anwendung kommen - und Sie können sie daher gern ausprobieren, wenn hohe Leistungen essentiell für Sie sind (wenn Sie Leistungsmessungen vornehmen, senden Sie sie uns bitte!).

Der Hauptgrund, weshalb wir sie (noch) nicht empfehlen, ist, daß wir die Vielzahl an unterstützten Algorithmen nicht intensiv testen und untersuchen können. Wenn Sie uns dabei behilflich sein möchten, dann bitte probieren Sie sie! Hier sind die derzeit unterstützten Stromchiffren:

Asymmetrische Verschlüsselung

Asymmetrische Verschlüsselung wird verwendet, um den Austausch der geheimen Schlüssel (die von der symmetrischen Verschlüsselung benutzt werden) zu schützen.

Der Schlüsselspeicher liegt auf dem Client oder auf einem separaten Schlüssel-Server (siehe Deployment-Szenarien), aber die geheimen Schlüssel werden auf dem Applikations-Server benötigt, um dort die eigentlichen Daten zu ent- bzw. zu verschlüsseln. Das bedeutet, Schlüssel-Transfers sind notwendig.

Die Schlüssel werden auf ihrem Weg vom Key-Store durch das offene Internet zum Applikations-Server üblicherweise durch eine HTTPS-Verbindung geschützt. Wenn sie jedoch ein Applikations-Server-Knoten an einen anderen Knoten (in einer gängigen Cluster-/Cloud-Umgebung) weiterleitet, werden sie u.U. temporär in einer Datenbank gespeichert. Um die Schlüssel in diesen Situationen zu schützen, kommt asymmetrische Verschlüsselung zur Anwendung.

Jeder Knoten des (ggf. geclusterten) Applikations-Servers erzeugt ein Schlüsselpaar bestehend aus einem öffentlichen und einem privaten Schlüssel. Wann immer er einen geheimen Schlüssel (für die symmetrische Verschlüsselung) benötigt, sendet er seinen öffentlichen Schlüssel zusammen mit der Anforderung nach einem geheimen Schlüssel an den Schlüssel-Verwalter. Der geheime Schlüssel wird dann mit diesem öffentlichen Schlüssel verschlüsselt und das Ergebnis zurück geschickt. Nur der originale Applikations-Server-Knoten kann (mit seinem privaten Schlüssel) den geheimen Schlüssel entschlüsseln. Ein Administrator, der das Medium ausliest, welches für die Knoten-zu-Knoten-Kommunikation genutzt wird, kann mit den ausgelesenen Daten nichts anfangen.

RSA//OAEPWITHSHA1ANDMGF1PADDING wird standardmäßig verwendet. Momentan gibt es noch keine Einstellung, mit der dies umkonfiguriert werden kann. Doch diese Konfigurationsmöglichkeit wird in absehbarer Zeit geschaffen.

Asymmetrische Verfahren

Die folgenden Verfahren stehen zur Verfügung:

Blockchiffre-Modi

Blockchiffren arbeiten - wie der Name sagt - mit einem Datenblock fester Länge (normalerweise 64 oder 128 Bit). Jedoch sind die zu verschlüsselnden Daten meist länger als nur ein Block. Daher werden Blockchiffren immer mit einem Operations-Modus kombiniert. Der Modus implementiert einen sicheren Weg, mehr Daten als nur einen Block zu ver- bzw. zu entschlüsseln.

Cumulus4j unterstützt die folgenden Modi:

Füllung (Padding)

Symmetrisch

Bei der Verschlüsselung mit einem symmetrischen Blockchiffre-Verfahren paßt die Größe der zu verarbeitenden Daten meist nicht genau auf die feste Block-Größe. Daher muß bei den meisten Blockchiffre-Operations-Modi der letzte Datenblock mit so vielen zusätzlichen Bytes aufgefüllt werden, daß er die benötigte Größe erreicht.

Asymmetrisch

Bei asymmetrischer Kryptographie bedeutet Padding (Füllung) die Vorbereitung der Daten für die Verschlüsselung durch einen ausgefeilten Algorithmus. Ursprünglich war die "Füllung" tatsächlich nicht mehr als das Auffüllen der Nachricht mit zufälligen Bytes. Da dies jedoch eine unsichere Form des Paddings ist, wird sie nicht mehr verwendet. Moderne Füllungsalgorithmen sind weiter fortgeschritten und bieten Schutz gegen zahlreiche mögliche Angriffe.

Nachrichtenauthentifizierungs-Code (MAC)

Ein Nachrichtenauthentifizierungs-Code (oder MAC von "Message authentication code") dient dazu, Datenmanipulation oder -korruption zu erkennen. Er ist daher einer Prüfsumme ähnlich, jedoch kann ein Angreifer im Gegensatz zu einer einfachen Prüfsumme nicht einfach ein paar weitere Bits ändern, um wieder die gleiche Summe wie die der originalen Nachricht zu erreichen.

Dokumentation
Über uns
Projektdokumentation
Babel
Versionen