Einzelnen Beitrag anzeigen

Benutzerbild von negaH
negaH

Registriert seit: 25. Jun 2003
Ort: Thüringen
2.950 Beiträge
 
#7

Re: CNV-Encryption(Verschlüsselung)

  Alt 13. Aug 2006, 19:33
Zitat:
Zuerst bestimmt man ein Passwort, aus welchem das Programm ein Zahlenfolge erstellt, die man NICHT zurückrechnen kann. Anschliessend wird ein "Keyfile"(so nenn ich es bis jetzt, falls jemand eine bessere Idee hat bitte Posten) ausgewählt. Mittels diesem wird verschlüsselt und entschlüsselt, es wird dabei jedoch nicht verändert. Der Empfänger, bzw der der es Entshclüsseln will, muss jedcoh EXAKT die gleiche Keyfile haben(der Name ist glaub ich nicht Massgebend). Ich hoffe dass durch diese Kombination ein Bruteforce angriff wirkungslos ist.
Nein ist er nicht. Das "Keyfile", was ich eher als "SBox" bezeichnen würde, muß mit der verschlüsselten Datei auch übertragen werden, dh. es muß mit den Daten über eine unsicherer Datenübertragung ausgetauscht werden. Wir können also davon ausgehen das ein Angreifer dieses "KeyFile" kennt. Somit hat der Angreifer alle notwendigen Informationen bis auf das benutzte Passwort.

Nun gehen wir gedanklich einen Angriff durch der so bei sicheren Algorithmen garaniert unmöglich zum 1 zu 1 knacken einer Nachricht führen wird.

Wir erzeugen ein "KeyFile" als ANgreifer das aus lauter NULLEN besteht, und senden das derjenigen Person die wir angreifen wollen. Dein Algo selber benutzt die Bytes in "KeyFile" als einfachster Additions-Offset auf die Daten. Dh. steht im KeyFile ein Byte mit Wert 0 so wird 0 auf das Datenbyte addiert um es zu verschlüsseln. Da wir mit 0 addieren ist unverschlüsselte Daten == verschlüsselte Daten.

Das heist, durch simples Austauschen des "KeyFiles" mit einem speziell präpariertem KeyFile wird deine Verschlüsselung absolut untauglich.

Probleme die ich mit deinem Verfahren sehe:

1.) generell arbeitest du mit viel zu vielen String-Umwandlungen. Aussser einem Performanceverlust hat das noch den Nachteil der unnötigen Nachrichtenexpansion. Dh. dein Algo. vergrößert die Nachrichtengröße in Bytes OHNE das daraus ein Vorteil in Punkto SIcherheit, Geschwindigkeit oder Useablity erwächst.


2.) Keyshedullung -> das ist das wo du das Passwort in deren Primzahlfaktoren zerlegst. Nette Idee aber mathematisch golt die Regel: Eine natürliche Zahl lässt sich EINEINDEUTIG über deren Primzahlzerlegung in Parimzahlpotenzen darstellen. Ergo: deine Primzahlfaktoren des umgewandelten Passwortes beschreibt eineindeutig dieses Paswort und kann somit sehr wohl in das Originalpoasswort zurückgerechnet werden.

Frage? Wie muß eine Funktion aussehen die bestimmte Eingangsdaten so auf Ausgangsdaten mappt das man nicht mehr von den Ausgangsdaten eineindeutig zu den Eingangsdaten zurückrechnen kann ?

Jede Funktion die ohne Informationsverlust eine Menge X auf Y abbilden kann, wird auch die Menge Y auf X zurück abbilden können. Exakt das macht dein Keyshedulling.

Du benötigst aber eine Funktion die einen Informationsverlust beim Mappen von X nach Y enthält. Das heist es gibt theoretisch zu einer Menge Y ganz viele verschiedene Mengen X'. Man kann also eine Menge Y auf eine Menge X' mappen aber es gibt viele verschiedene Mengen X' die ein gleiches Y erzeugen würden.
Durch den Informationsverlust beim Mappen entsteht also eine "Einweg-funktion", eine Funktion die eindeutig njur in eine Richtung mappen kann, und in der Gegenrichtung eben nicht mehr eindeutig mappen kann.
Solche Funktionen sind Hash-Funktionen, oder Secure One Way Function.

3.) deine kryptographisch relevante Funktion die du benutzt ist die ADDITION. Das ist bei weitem viel zu wenig komplex. Du benutzt keinerlei Substitutionen oder ähnlich annerkannte Grundalgos. sondern nutzt nur die einfachste TRansposition die es gibt. Transpositions-verschlüsselungen sind die am leichtesten brechbaren Cipher, zb. Cäsar.


Gruß Hagen
  Mit Zitat antworten Zitat