Nikx schrieb:

wie das bei Verschlüsselungen mit Salt-Werten ist.

Die heißen Initialization Vector, kurz IV ...
(Verwendung je nach Cipher-Mode)

Soll ich dann ohne Salt-Wert entschlüsseln?

Ent?
Das entschlüsseln erfolgt wie der VERschlüsseln, sonst gibt es gfgergtertgrgsdvdskfuewiour

Oder soll ich einen festgelegten, langen String

Verschlüsselungsalgorithmen arbeiten mit Bytes oder Bits, aber nicht mit "String".

Tip: Wenn man nicht weiß, WAS man tut, sollte man nicht gerade Kryptographie anfassen ...

Nikx schrieb:

Übrigens: Es gibt da eine .GetBytes Methode

Die ist aber für den Iv ungeil. Der muss eine definierte Länge haben, also nimmt man besser einen Hash(of) oder gleich das:
msdn.microsoft.com/en-us/libra…y.rfc2898derivebytes.aspx

Wenn kein Salt verwendet werden soll (Anwender entscheidet) dann nimmt man halt keinen!
Du schreibst vermutlich ne Lib?
Was wenn jemand damit einen Text verschlüsselt und den auf einem Linux-System mit PHP wieder entschlüsseln will? Wenn dein Lib dann einen "unbekannten" IV verwendet, hat der Anwender wohl die Arschkarte?

Wenn dein Rotz nur für dein eigenes Programm entscheidend ist und nie von Fremdprogrammen angeschaut wird, kannst du natürlich tun, was du willst.

Zum Entschlüsseln muß sowohl der verschlüsselte Text als auch das Salt (unverschlüsselt) vorliegen.
PasswordHandling

vbarchiv.net/tipps/tipp_1351-t…rschluesselung-vbnet.html

Nikx schrieb:

Wie kann ich AES ohne Salt verschlüsseln?

Den IV (byte array) auf ein leeres Array setzen ...

ich muß zugeben, mir fehlt auch noch ein Stück Verständnis, dieser Password - Salt/IV - Geschichte.

Verstehe ich das richtig, dass durchs Salt bewirkt werden soll, dass jeder Verschlüsselungs-Vorgang gewissermaßen sein eigenes Passwort hat?

Also die Umformung verläuft jedes Mal anders, auch wenn dasselbe Passwort verwendet wird.
Selbst die "Wiederholung" der Verschlüsselung desselben Textes mit demselben Passwort ergibt ein ganz anneres Crypt.

Ist das das Ziel von "Salt"?

Nächste Frage: Warum arbeitet man die Salt-Generiererei nicht gleich in die Algorithmen ein? Es wäre doch kein Kunststück, das Salt automatisch zu generieren, die Daten zu verschlüsseln, und am Crypt den IV eben noch anzuhängen?
Dann bräuchte man sich als Programmierer nicht mehr mit diesem bisserl unlogisch erscheinenden Kram zu befassen, und jede Verschlüsselung wäre halt automatisch richtig gesaltet (wenn das denn richtig wäre, wo ich ja nichtmal sicher bin).

ErfinderDesRades schrieb:

Ist das das Ziel von "Salt"?

So in etwa

Warum arbeitet man die Salt-Generiererei nicht gleich in die Algorithmen ein?

Weil sie nicht "Teil" des Algorithmus sind? Der IV ist - wie der Key - ein Parameter. Den sollte logischerweise jeder wählen können, wie benötigt. Wer Automatismen benötigt, kann sich die ja leicht selbst bauen. Wer das nicht kann, weil er nicht weiß, was abgeht, sollte dann auch besser sich nicht mit Kryptographie beschäftigen.

AES basiert auf dem Rijndael-Algorithmus, nur das bei AES ist die Blockgröße fix vorgeschrieben ist.

Hier mal der Rijndael-Algorithmus in .NET
Bei mir wird der IV zufällig erzeugt und das sollte auch so bleiben. Aber man kann es dahingehend erweitern, dass man den Text mit einem eigenen Salt verknüpft (xor).

z.B.: Einfach vor der Verschlüsselung und nach der Entschlüsselung alle Zeichen mit dem Salt XOR verknüpfen.


Der IV sowie der Salt sorgen dafür, dass die Ciphertexte sich immer etwas unterscheiden um somit eine Known-Plaintext-Attacke zu erschweren.

@ErfinderDesRades: Der Salt dient dazu das niemand so einfach ohne ihn ein PW Hash Faken kann. Würden z.B. SQL Injections möglich sein und der Angreifer wissen dass das PW nur mittels md5() gehashed wird, dann könnte er sich seinen wunsch Hash von einem ihm bekannten Passwort erstellen z.B.



diesen würde er dann in der Datenbank bei einem User ersetzten und könnte sich somit einloggen. Nutzt man jedoch zur generierung des Passwort Hashs ein Salt, der natürlich NICHT bekannt ist, so kann ein Angreifer kein Hash mehr erstellen, weil die eigentliche Login oder Hash Generierungsmethode z.B. so aussieht



und dies muss natürlich vom Benutzer frei wählbar sein, weil sie ja ansonsten keine zusätzliche Sicherheit bietet um den Hash zu individualisieren.

BiedermannS schrieb:

Einfach vor der Verschlüsselung und nach der Entschlüsselung alle Zeichen mit dem Salt XOR verknüpfen.

Das bringt aber irgendwie nicht viel, da das dann eine einfache 1:1 Beziehung ist.

Grundsätzlich sollte man die Begriffe "Salt" und "IV" immer unterscheiden:

Salt: Wird üblicherweise bei der Password-Generierung verwendet. Der Klartext wird mit dem Salt "verknüpft" (versch. Verfahren sind möglich) und daraus wird ein Hash gebildet. Das ganze wird ggf mehrfach wiederholt und ggf mehrfach fließt dabei auch das "Salz" mit ein.

IV: Wird im Prinzip bei allen Ciphermodes benötigt, die irgendeine Art von "Feedback" unterstützen. Dh. das Ergebnis des vorherigen Verschlüsselungsvorgangs (eines Blocks!) fließt in die Verschlüsselung des folgenden Blocks mit ein. Da der 1. Block aber ja keinen "Vorgänger" hat, verwendet man hier den Initialization Vector. Der IV wird dann genau einmal verwendet, nämlich nur beim ersten Block. Bei Cipher Modes OHNE Feedback (zb ECB) wird ein IV nicht verwendet - weil er ja keinen Sinn macht.

@Dodo:

Nutzt man jedoch zur generierung des Passwort Hashs ein Salt, der natürlich NICHT bekannt ist, so kann ein Angreifer kein Hash mehr erstellen

Da bringst du was durcheinander. So wie du es beschreibst, wäre der Salt ein zweites (geheimes) Passwort. Das ist er aber gerade nicht und der Salt kann/soll immer "öffentlich" sein, genau wie der IV. "Frei wählbar" sollte er hingegen nicht sein, da es sinnvoller ist, den IV durch einen guten Generator erstellen zu lassen und es auch nicht wirklich Sinn macht, ihn zu "wählen" ... beim VERSCHLÜSSELN. Beim entschlüsseln muss natürlich immer der (bekannte) IV verwendet werden. Deswegen wird dieser üblicherweise dem Ciphertext vorangestellt.

@picoflop: so habe ichs mal gelernt und bei Wiki steht auch was ähnliches
de.wikipedia.org/wiki/Salt_%28Kryptologie%29

nur dort wird der Salt immer mit gespeichert. Aber das Prinzip bleibt doch das selbe oder? Das eigentliche PW wird noch mit etwas erweitert. Würde der Salt öffentlich und bekannt sein, könnte ja doch wieder jeder den Hash nachbilden O.o

Dodo schrieb:

Würde der Salt öffentlich und bekannt sein, könnte ja doch wieder jeder den Hash nachbilden

Ja. Aber auch das funzt dann nicht über Tabellen etc, sondern nur noch über Bruteforce auf den "unbekannten" Teil (also das eigentliche Passwort). Damit liegt wieder alles bei der "Stärke" des Passworts. Wäre es ein absolutes Erfordernis, dass der Salt unbekannt ist, könnte man genauso gut fordern, dass jedes Passwort eine Stärke von zb 90 Bit haben müsste. Es macht auch keinen Sinn, zu fordern, dass der Salt immer geheim sein muss, denn selbiges gilt natürlich für den erzeugten Hash. Wir betrachten aber ja Situationen, in denen ein Angreifer BEIDES hat (weil er zb Zugriff auf die DB hat). Da ist der Salt dann wegen oben (Tabellenlösungen!) immer noch sinnvoll, bzw zwingend notwendig.


EDIT
Aus dem Wikilink:

Da die verwendeten Salts einem Angreifer bekannt sind, erhöhen sie nicht die Sicherheit bei einem Angriff auf ein einzelnes Passwort. Ein schwaches Passwort kann also ebenso leicht mithilfe von Wörterbuch- oder Brute-Force-Angriffen entschlüsselt werden.

Wie ich also bereits sagte

picoflop schrieb:

Das bringt aber irgendwie nicht viel, da das dann eine einfache 1:1 Beziehung ist.

Sollte auch nur als einfaches Beispiel dienen.

Der IV wird benutzt um bei mehrmaliger verschlüsselung des selben Plaintext mit dem selben Passwort verschiedenen Ausgaben zu Produzieren und sollte diesbezüglich immer zufällig generiert werden.

Und die Verknüpfung der vorigen

picoflop schrieb:

IV: Wird im Prinzip bei allen Ciphermodes benötigt, die irgendeine Art von "Feedback" unterstützen. Dh. das Ergebnis des vorherigen Verschlüsselungsvorgangs (eines Blocks!) fließt in die Verschlüsselung des folgenden Blocks mit ein. Da der 1. Block aber ja keinen "Vorgänger" hat, verwendet man hier den Initialization Vector. Der IV wird dann genau einmal verwendet, nämlich nur beim ersten Block. Bei Cipher Modes OHNE Feedback (zb ECB) wird ein IV nicht verwendet - weil er ja keinen Sinn macht.

Das ist der sogenannte Cipher Feedback Mode, und dieser verknüpft die Werte der vorigen Runde mit der der aktuellen Runde über XOR
de.wikipedia.org/wiki/Cipher_Feedback_Mode