Zitat:
Das heißt für mich mit SHA-1 und AES also, dass mein System mit maximal 160 Bit arbeitet. Würde ich einen anderen Hash (MD5 oder so) verwenden, dann könnten das auch 256 Bit sein. Ist das korrekt?
Jain
Ein Cipher initialisiert sich selber immer so das er den Inputkey durch eine Transformation auf seinen kompletten Schlüsselraum verteilt. Im Prinzip wohlgemerkt. Es gibt aber hier Abweichungen von Cipher zu Cipher. Einige nehmen das Passwort direkt ohne Keyshedduling, andere wiederum initialisieren sich abhängig von der Länge des Inputs und die neueren spreizen das Keymaterial auf deren maximale Keylänge auf. D.h. ein Passwort "Test" würde in Rijndael auf 256 Bit's gestreckt und eine andere Initialisation als "Test1" erzeugen. Wie gesagt dies ist abhängig vom Cipher. Generell hängt es, egel ob gutes oder schlechtes Keyshedulling, aber nur von der Länge des Passwortes ab.
Nun, würdest du ein 256 Bit Zufallspasswort mit SHA1 und Rijndeal nehmen so würde SHA1 dieses gute Passwort in ein weniger gutes 160 Bit Passwort transformieren und Rijndael damit seine 256 Bit Initialisierung machen. Dazu werden die 160Bit mit Nullen am Ende expandiert auf 256 Bits.
Nun, angenomen 256 Bit AES heist 2^256 mögliche Passwörter und eines von diese wäre 160Bit Hash + 96Bit 0 ! Somit wäre die Sicherheit dennoch 256 Bits, aber nur 160Bit Passwörter * 2^96 würden benutzt.
Entscheidend bei solchen Größen ist dann nicht mehr der Cipher sondern NUR das er die Wahrscheinlichkeiten der Sicherheit extakt gleich auf alle möglichen Passwörter in seinem Schlüsselraum verteilt. Der Schlüsselraum bei AES ist 2^256, ein gutes Beispiel für Un-Gleichverteilung ist DES. In diesem gibt es 2^56 mögliche Schlüssel, aber viele dieser Schlüssel sind schwächer als die anderen. In Blowfish tritt das gleiche Phenomen auf. In AES nicht.
Ein Schlüsselraum von 2^128 gilt allgemein als sicher, aber ein Passwort wie "A" in diesem Schlüsselraum ist in jedem Falle unsicher.
Somit sind "kurze" Passwörter garnicht das Problem da ein zu kurzes Passwort aufgefüllt mit Nullen exakt in den Schlüsselraum hineinpasst. Problematischer sind zu lange Schlüssel da diese dann gutes Schlüsselmaterial verschwenden und eine Sicherheit suggerieren die nicht existiert. Auch eine 256Bit hashfunktion reduziert die Sicherheit eines 360Bit Schlüssels !
Zitat:
Was passiert denn mit den Leerstellen? Die bleiben doch nicht unverschlüsselt, oder? Bei Rijndael ja auf jeden Fall nicht, weil AES ja eine variable Keylänge hat.
Diese Frage verstehe ich nicht ganz, was sind Leerstellen ?
Alles in der Kryptographie läuft binär ab, eine Leerstelle im eigentlichen Sinne gibt es dann nicht, denn auf Byteebene = 256 mögliche Zeichen werden auch alle 256 Zeichen berücksichtigt und benutzt.
Zitat:
Wann gibt es denn das neue
DEC?
Die Grundlagen, Hashs, Formate, CRC's sind fertig. Es fehlen noch die Cipher. Diese werden von 40 Stück stark reduziert. Es wird also nur noch eine Auswahl geben. Allerdings dies ist nicht das eigentliche Problem. Viel problematischer ist die Frage wie die Cipher in Zukunft benutzt werden sollen. Ich streite mich noch mit mir selber über die Frage ob die Cipher nun Low-Level-Algos. oder Higher-Level-Algos. sein sollen. Im bisherigen
DEC sind es Low-Level-Algos. bei denen der Benutzer wissen muß wie er was mit den Cipher macht. Zb. Messagepaddings, Blocksize berücksichtigen, Header einfügen und rausnehmen, Progresscallbacks usw. D.h. die bisherigen Cipher sind nur die Algos. und ein bischen Interface. Da dies im
DEC nirgendswo implizit steht haben viele Benutzer falsche Vorstellungen entwickelt was z.B. Cipher.EncodeStream() wie macht.
Würde ich aber dies "benutzersicher" machen, dann hiese das aber das die Cipher nicht mehr universell nutzbar sind und alles was ver/entschlüsselt wird eben
DEC spezifisch ist.
Gruß Hagen