Dateien verschlüsseln - aber wie?

[negaH]

@Luckie:

Zitat:

Ich warte, ehrlich gesagt, immer noch darauf, wie ich an die CipherID / HashID rankomme, bzw. wie ich sie dann nutzen kann.

Ich arbeite, arbeite und arbeite sehr hart daran. DEC version 3.0 erzeugt diese Identities als Word, was leider nicht ausreicht.
Momentan bin ich am ausmisten und "neuerschaffen" der DEC Formate/Hashs/Ciphers. Das Klassenkonzept wurde enorm stark reduziert, und somit wird einiges an Resourcen gesparrt. Zusätzlich habe ich mich gleichmal dazu entschlossen die optimierten und neuen Hash Sourcen von Tol einzubauen. Es wird also demnächst SHA256, SHA384, SHA512, bugfixed Haval, Panama, Whirlpool 0/1, Snefru 128/256 und bugfixed Sapphire geben. Im gesammten wurde die Performance alle Hashs um 80% gesteigert.

Im neuen DEC wird mit Stream.Write(Hash.Identity) ein Cardinal gespeichert. Mit HashByIdentity(Stream.ReadCardinal) wird die registrierte Hashklasse ermittelt.

Bis jetzt habe ich durch diese Reorganisationen ca. 100Kb an Code gesparrt.

Gruß Hagen

[Luckie]

Ach so, sorry, du arbeitets noch dran, ich dachte das wäre schon drin. Dann laß dir nur Zeit.

[daniel-volk]

@ Hagen:

Hi,

eine Frage ist mir noch unbeantwortet:
Mit welcher Schlüssellänge arbeitet Rijndael im DEC? 128 Bit oder 256 Bit?

Danke,
Daniel.

[negaH]

Cipher.MaxKeySize = Bytes der maximal nutzbaren Keylänge.
Wird mit Cipher.InitKey() gearbeitet so wird intern das Passwort mit hilfe von Cipher.HashClass in einen Sessionkey umgewandelt. Ist diese Funktion zB. MD4 dann würde somit mit 128 Bit Sessionkey gearbeitet.
Es gibt aber drei wichtige Größen eines Ciphers die die Eigenschaften bestimmen:
1.) MaxKeySize = maximal nutztbares Keymaterial, bei 128Bit sagt man es ist eine 128 Bit Verschlüsselung
2.) BlockSize = Datenbreite mit der der Algo. intern arbeitet, 1 Byte sind die meisten StreamCipher, 8-16 Bytes die meisten BlockCipher
3.) reale KeyBitSize / Wahrscheinlicheit für Password-Wörterbuch attacke IST die reale Sicherheit

Also, 1.) gibt die offizielle Sicherheit an, und es hört sich immer schön an wenn man behaupten kann das man einen 1024 Bit Algo. benutzt. Allerdings kann durch 3.) die Sicherheit des Algo. auf NULL gehen, nämlich wenn als Passort "A" benutzt wird. "A" stammt aus einen Alphabeth aus 256 Zeichen, wobei "A" selber aber mit 1/26 Wahrscheinlichkeit tatsächlich vorkommt. Nun noch diese 5 Bit durch die Wahrscheinlicht dividieren das eine Wörterbuchattack mit "A" beginnt und übrig bleibt 0 Prozent Sicherheit ! Selbst mit einen 13476 Trillion Bitcipher wäre eine simple 56 Bit DES mit echten 56 Bit Schlüssel weitaus sicherer.

Es ist also wichtig das wenn man eine 128 Bit Verschl. benutzten will das man auch ein echtes 128 Bit Passwort benutzt. Ein Passwort wie "Dies ist mein Passwort" hat bei weitem KEINE 128 Bit Datengehalt.

Im alten DEC wird zur Erzeugung des Sessionkeys einfach der Hashdigest vom übergeben Passwort benutzt. Dies bedeutet das entweder der Hashdigest kürzer als die mögliche Bitlänge des Passwortes des Ciphers ist, oder aber das der Hashdigest zu lang ist und Keymaterial abgeschnitten wird. Dieses Vorgehen ist besser als ohne Hashfunktion zu arbeiten und trotzdem nicht gut. Im neuen DEC wird dies eliminiert und eine sogenannte "KDF = Key Derviation Function" benutzt. Diese erzeugt aus dem Passwort per Hashfunktion exakt soviele Bytes wie der Cipher schlucken kann.

Rijndeal.MaxKeySize = 32, somit 256 bit.

Gruß Hagen

[daniel-volk]

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?
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.

Wann gibt es denn das neue DEC?

Gruß,
Daniel.

[negaH]

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

[daniel-volk]

Danke erstmal. Ich verwende jetzt SHA1 (also mit 160 Bit) und das soll mir dann an Sicherheit reichen. Man muss ja nur mal bedenken, dass Steganos lediglich 128 Bit verwendet. Und dann werden meine 160 Bit wohl mehr als genug sein.

Zitat:

Zitat:

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.

Du hast Sie schon in der ersten Frage beantwortet. Ich meinte mit Leerstellen einfach nur die unbelegten Bits, die dann mit Nullen aufgefüllt werden. (Also bei einem 160 Bit Hash und 256 Bit Cipher.) Ich hatte mir schon gedacht, dass die 0 werden, hab darin (bei meinem wenigen Wissen über diese Profi-Cipher) dann aber ein Sicherheitsrisiko darin befürchtet. Und das wäre es bei einfachen Algos ja auch.

Zitat:

Zitat:

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.

Die Frage kann ich dir einfach beantworten:
Mach beides. Ich persönlich hätte lieber die fertige Variante gehabt, aber mit der jetzigen bin ich auch ganz gut klargekommen.
Dennoch ist es sicherlich für den Anfänger immer sicherer, wenn der Cipher einfacher zu verwenden ist. Mach es doch so:
Du lässt es wie es jetzt ist, fürst dann aber noch Funktionen zu professionellen vorgegebenen Verschlüsseln etc ein.
Also z.B.:

Delphi-Quellcode:

//Die Funktionen zum vorgefertigten Verarbeiten von Daten (gleich mit speichern von Zufallsdaten, Hash etc)
function CompletelyEncodeString()
function CompletelyDecodeString(): boolean; //Ausgabe: Hash-Werte stimmen überein
function CompletelyEncodeFile(CipherClass, HashClass, Passwd...)
function CompletelyDecodeFile() //Cipher und Hash sind im Header gespeichert und werden automatisch verwendet

// Und natürlich noch die normalen Funktionen, wie sie jetzt existieren

Ich fände es so am besten. Dann kann man nämlich, wenn man selbst nicht so viel Ahnung hat, deine Funktionen verwenden und kann sich dennoch sicher sein, dass es professionell verschlüsselt ist.

Aber ich weiß natürlich auch, dass es kein unerheblicher Arbeitsaufwand ist das so zu gestalten, dass die Leuts das dann auch vernünftig verwenden können.

MfG,
Daniel.

[Luckie]

Mal eine dumme Frage: Wie lautet im DEC die CipherClasse zu Rijndael? TCipher_Rijndael ist es nicht. Ich wollte mich jetzt auch von BlowFish verabschieden.

Du verschlüsselts den Header mit, wenn ich da sin deiner Hilfe richtig gelesen habe.

[daniel-volk]

Für Rijndael musst du zusätzlich zur Unit Cipher auch noch Cipher1 implementieren.
Dann ist es TCipher_Rijndael!

MfG,
Daniel.

[Luckie]

Hm, das soll mal einer wissen. Besten Dank.