| 
| Autor | Beitrag |  
| hansdergott 
          Beiträge: 55
 
 XP Mediacenter Edition; XP Home
 Delphi
 
 | 
Verfasst: Sa 25.04.09 16:11 
 
hallo zusammen
 ich weiß xor verschlüsselung wurde schon x Trillion mal besprochen
 aber hier mal eine andere frage bz. xor
 ich habe einen schlüssel der sich aus den eingaben bzw den textlängen 
 von allen eingabefeldern errechnet
 hier ein beispiel:
 		                       Delphi-Quelltext 
 									| 1:2:
 3:
 4:
 5:
 6:
 7:
 8:
 9:
 10:
 11:
 12:
 13:
 14:
 15:
 16:
 17:
 18:
 19:
 20:
 21:
 22:
 23:
 24:
 
 | const key[1]=0.452;
 key[2]=6.930;
 
 for r:=1 to 10 do
 begin
 c1=edit1.gettextlen * sin(edit2.gettextlen) +key[1] / key[2];
 
 if (r=4) or (r=9) then
 begin
 c2=edit3.gettextlen * round(cos(edit2.gettextlen) + key[2]);
 end;
 
 end;
 
 tmp:=floattostr(c1*c2);
 
 for i:=1 to length(tmp) do
 begin
 schluessel:=schluessel + IntToHex(Ord(zeilentext[i]),2);
 end;
 |  das ganze halt mit allen edit eingaben und dann  10 runden hintereinader
 bei mit kommt dann irgendwann das raus nach dem umwandeln ins hex:
2D33303933312C3933323130383533333853746965722D313230343332322C343938333539363653636872616D6265726736 das wäre also eine schlüssellänge von 800bit  (100 zeichen mal 8bit) 8bit=1byte=1Zeichen
 ich verrechne das was verschlüsselt werden mit : 
 		                       Delphi-Quelltext 
 									| 1:
 | input[x]:=chr(ord(input[x]) + ord(schluessel[u]));					 |  wie stark ist also die verschlüsselung? weil mit diesem verfahren immer nur 8bit + mit 8bit verrechet wird
 aber wiegessagt die schluesselstärke bei 800bit liegt
 vielen dank schon malModeriert von  Narses: Topic aus Dateizugriff verschoben am Sa 25.04.2009 um 18:47_________________ User haften für Rechtschreibfehler
 |  |  |  
| jfheins 
          Beiträge: 918
 Erhaltene Danke: 158
 
 Win 10
 VS 2013, VS2015
 
 | 
Verfasst: Sa 25.04.09 21:14 
 
Das was du da mit sinus und cosinus machst ist vergebene Liebesmüh.
 Dein Schlüsselraum berechnet sich aus den möglichen Eingabewerten.
 
 D.h. wenn du 3 Eingabefelder hast und die Stringlänge nimmst hast du einen theoretischen Schlüsselraum von maxint^3 = 2^96 = 96 bits
 
 Praktisch nutzt du diese aber lange nicht aus (Da du wahrscheinlich nicht 2 Milliarden Zeichen in dein Edit schreibst)
 
 ==> Angenommen der Edit-Inhalt ist typischerweise 10 Zeichen lang. Zur Sicherheit nehmen wir mal 20 Zeichen an. Dann hast du mit deinen 3 Edits 4,3 * 3 = 13 Bits Schlüssellänge.
 
 Das kann man noch gut per Bruteforce knacken!
 
 
 Btw.: Die Schlüsselstärke ist nie im Leben 800 Bit. Das was du da ioben hast ist ein Hex-String. Das heißt, dass ein Zeichen nicht 8 bit sind sondern 4 bit.
 |  |  |  
| Sirke 
          Beiträge: 208
 Erhaltene Danke: 2
 
 
 
 
 | 
Verfasst: Sa 25.04.09 21:37 
 
Der "Schlüsselstärke" für eine XOR-Verschlüsselung ist an sich wirklich die Anzahl der Bits des Schlüssels, wobei man dabei von einem echt zufälligen Schlüssel(strom) ausgehen muss.
 In deinem Fall verwendest du jedoch keinen echt zufälligen Schlüsselstrom, sondern einen extrem schlechten pseudozufälligen Schlüsselstrom! Der Schlüsselraum bzw die Stärke des Schlüssels misst man an dem Geheimnis, was in deinem Fall die beiden Fließkommazahlen wären. Dazu kommt jedoch, dass dein PRNG kein wirklich guter ist, da du eine sehr große Anzahl an 0x3 in deinem Schlüssel hast und eine geringe Anzahl an 0xA-0xF!
 
 Weiterer Nachteil ist, dass wenn du das ganze zehn mal anwendest du eine Aneinanderreihung von zehn gleichen Schlüsseln hast, sodass dies den Schlüsselraum effektiv gegen Null gehen lässt!
 |  |  |  
| BenBE 
          Beiträge: 8721
 Erhaltene Danke: 191
 
 Win95, Win98SE, Win2K, WinXP
 D1S, D3S, D4S, D5E, D6E, D7E, D9PE, D10E, D12P, DXEP, L0.9\FPC2.0
 
 | 
Verfasst: Sa 25.04.09 21:41 
 
Ferner kommt dazu, dass Du einen Float in ASCII wandelst und diesen String zusammenpackst. Damit hast Du nicht 8 Bit pro Zeichen, sondern 4. Auf den Gesamtstring übertragen heißt das, dass Du 5 Bit je 2 Zeichen im Hex-String hast, wenn man die Zahlen bruteforcen müsste, aus denen sich der Hex-String zusammensetzt.
 Nimmt man jetzt noch hinzu, dass Du diese Zahlen mit Sin\Cos berechnest, kann man sogar vorhersagen über die Position der Kommas und Vorzeichen im String machen --> es bleiben nur die Ziffern übrig.    ~4 Bit je 2 Zeichen.
 Dadurch, dass Du c1 und c2 nicht miteinander verrechnest, erlaubst Du sogar die direkte Berechnung des Schlüssels:
 Dazu vereinfachen wir mal deinen Source:
 		                       Delphi-Quelltext 
 									| 1:2:
 3:
 4:
 5:
 6:
 7:
 8:
 9:
 10:
 11:
 12:
 13:
 14:
 15:
 16:
 17:
 18:
 19:
 
 | const key[1]=0.452;
 key[2]=6.930;
 
 e1 := edit1.gettextlen;
 e2 := edit2.gettextlen;
 e3 := edit3.gettextlen;
 
 c1=e1 * sin(e2) + key[1] / key[2]; c2=e3 * round(cos(e2) + key[2]);
 tmp:=floattostr(c1*c2);
 for i:=1 to length(tmp) do
 begin
 schluessel:=schluessel + IntToHex(Ord(zeilentext[i]),2);end;
 |  Also für tmp werf ich mal 2^10-2^11 als Entropie in den Raum. Wirklich gut Bruteforcebar  _________________ Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.
 |  |  |  
| hansdergott  
          Beiträge: 55
 
 XP Mediacenter Edition; XP Home
 Delphi
 
 | 
Verfasst: Sa 25.04.09 22:22 
 
hallo zusammen 
 danke für die antworten
 mir war halt wichtig das sobalt sich etwas in den eingaben ändert der 
 ganze schlüssel sich komplett ändert
 also die gesammt procedure für den schlüssel ist folgende
 > 11 eingabefelder und 3 const wurde alle mit einander und das ganze 15mal<
 												| 1:2:
 3:
 4:
 5:
 6:
 7:
 8:
 9:
 10:
 11:
 12:
 13:
 14:
 15:
 16:
 17:
 18:
 19:
 20:
 21:
 22:
 23:
 24:
 25:
 26:
 27:
 28:
 29:
 30:
 31:
 32:
 33:
 34:
 35:
 36:
 37:
 38:
 39:
 40:
 41:
 42:
 43:
 44:
 45:
 46:
 47:
 48:
 49:
 50:
 51:
 52:
 53:
 54:
 55:
 56:
 57:
 58:
 59:
 60:
 61:
 
 | const key1=0.62;key2=1.38;
 key3=5.02;
 
 procedure TForm1.checksumme;
 var er:array[1..5] of real;
 i:integer;
 immertext:string;
 z:char;
 fertig:string;
 tmp:string;
 runde:integer;
 maxrunden:integer;
 begin
 immertext:='';
 fertig:='';
 schluessel:='';
 runde:=1;
 maxrunden:=15;
 
 wert[1]  := vorname.GetTextLen +1;
 wert[2]  := nachname.GetTextLen +1;
 wert[3]  := strasse.GetTextLen +1;
 wert[4]  := hausnummer.GetTextLen +1;
 wert[5]  := postleitzahl.Value +1;
 wert[6]  := wohnort.GetTextLen +1;
 wert[7]  := telefon.GetTextLen +1;
 wert[8]  := handy.GetTextLen +1;
 wert[9]  := status.ItemIndex +1;
 wert[10] := kundenart.ItemIndex +1;
 wert[11] := memo1.GetTextLen +1;
 
 er[1]:=1; er[2]:=1; er[3]:=1;
 er[4]:=1; er[5]:=1;
 
 for runde:=1 to round(maxrunden div 2) do
 begin
 er[1]:=er[1] + wert[1] * wert[3] / wert[2];
 er[2]:=er[2] - abs(round(cos(er[1]) + wert[4] *wert[5]));
 er[3]:=er[3] * wert[6] - key2*(wert[7] / wert[8]);
 er[4]:=er[4] / sin(wert[9] + wert[10] * wert[11]);
 
 if (runde=4) or (runde=7) then
 begin
 er[2]:=er[2] + round(sin(er[1]+er[2])) - er[3] / er[4];
 er[5]:=sin(er[5] * cos(er[5]) - key1 * er[3] / key3 / wert[2]);
 end;
 end;
 
 immertext:=floattostr(er[5]) + floattostr(er[2]);
 immertext:=immertext + floattostr(wert[2]);
 
 for i:=1 to length(immertext) do
 begin
 tmp:=tmp+IntToHex(Ord(immertext[i]),2);
 end;
 
 schluessel:=tmp;
 immertext:='';
 fertig:='';
 end;
 |  und meintet ihr das mit 4 bit\zeichen statt 8bit\Zeichen
 ich dachte das immer 8bit 1byte ergeben egal zahl buchstabe oder zeichen
 ich dachte auch das die schlüsselstärke sich dadurch berechnet dieviele zeichen der schlüssel enthält
 grüße_________________ User haften für Rechtschreibfehler
 
 Zuletzt bearbeitet von hansdergott am Sa 25.04.09 22:26, insgesamt 1-mal bearbeitet
 |  |  |  
| jfheins 
          Beiträge: 918
 Erhaltene Danke: 158
 
 Win 10
 VS 2013, VS2015
 
 | 
Verfasst: Sa 25.04.09 22:26 
 
Ach ja, nochmal etwas grundsätzliches: Du kannst nicht aus wenig Information/Zufall mehr  Information/Zufall machen    Wenn du z.B. eine Zufallszahl zwischen 1 und 10 (diskret, also 1, 2, 3 usw.) hast, kannst du den Bereich zwar vergrößern, indem du z.B. dfie Zahl mal 2 nimmst. Aber du wirst nie mehr als 10 verschiedene Ergebnisse haben können !
 Genausowenig kannst du aus ein paar kleinen Zufallszahlen einen echten 800bit Schlüssel bilden. Du kannst sie aufblähen, sodass es aussieht als wären es 800 bit, aber die "Menge an Zufall" bleibt dabei gleich    Was du natürlich amchen kannst, ist Information/Zufall zu veringern. Wenn du z.B. eine (reelle) Zahl zwischen 0 und 5 hast und den Sinus darauf anwendest, hast du eine (weniger zufällige) Zahl zwischen -1 und 1.
 Weniger zufällig deshalb, weil in diesem Intervall mehr Positive Ergebnisse herauskommen als negative. Außerdem hat sich das Intervall verringert (dadurch ist "Zufall verlorengegangen").
 P.S. Wenn du eh nicht mehr die Orginaldaten brauchst, kannst du auch eine Hashfunktion wie MD5  benutzten.
 Die sind extra so gemacht, dass ein wenig andere Eingabedaten komplett andere Ausgabe liefern.
 P.P.S.: Das mit den 8 bit pro Zeichen stimmt zwar grundsätzlich schon, aber hier ist es wichtig, wieviel Information da eigentlich drin steckt.
 z.B. das hier: 100011100101011010 verbraucht 8 bits pro Zeichen. Aber (da ja nur 0 und 1 vorkommen) enthält es nur 1 bit Information pro Zeichen   
 Zuletzt bearbeitet von jfheins am Sa 25.04.09 22:32, insgesamt 1-mal bearbeitet
 |  |  |  
| BenBE 
          Beiträge: 8721
 Erhaltene Danke: 191
 
 Win95, Win98SE, Win2K, WinXP
 D1S, D3S, D4S, D5E, D6E, D7E, D9PE, D10E, D12P, DXEP, L0.9\FPC2.0
 
 | 
Verfasst: Sa 25.04.09 22:31 
 
Du nutzt IntToHex, was 1 Byte in zwei Zeichen abbildet. Dadurch schaffst Du nicht etwa 16 Bit an Information, sondern teilst die vorhandene Information auf zwei Zeichen auf, womit jedes Einzelzeichen (vorausgesetzt, die Eingabewerte sind gleichverteilt) die Hälfte der Information, nämlich 4 Bit) trägt. Siehe Begriff Entropie,
 Deine jetzige Routine ist nur unwesentlich besser als die erste Version, da ich die Berechnung des Schlüssels IMMER noch Loop Unrollen kann, und dabei eine Vereinfachung erhalte    @MD5: Lieber SHA1 oder besser SHA256\SHA512 benutzen.
 Ansonsten ACK meinem Vorposter ..._________________ Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.
 |  |  |  
| hansdergott  
          Beiträge: 55
 
 XP Mediacenter Edition; XP Home
 Delphi
 
 | 
Verfasst: Sa 25.04.09 22:43 
 
hi
 aber md5 macht auch nichts anderes als wie glaub 4oder 5 constanten mit
 den text zu verrechnen
 md5 macht halt das was ich auch mache an verschiedenen stellen runden
 oder auch nicht und das entstandene ergebnis mit anderen verrechnen
 
 oder
 _________________ User haften für Rechtschreibfehler
 |  |  |  
| Sirke 
          Beiträge: 208
 Erhaltene Danke: 2
 
 
 
 
 | 
Verfasst: Sa 25.04.09 23:35 
 
Der MD5 und die Hash-Algos seiner Familie unterteilen einen String in Blöcke, welche rekursiv einer Funktion übergeben werden, in der der Block aufgebläht und reduziert wird: h = HASH( Block_i, h )
Dabei ist gerade die Funktionen zum Aufblähen und Reduzieren so gewählt, dass die Hash-Funktion gewisse Voraussetzungen erfüllt! (stark gekürzt)
 Schaue dir den MD5 mal genauer an, was dort genau passiert und dass dort nur Bitmanipulation und Addition verwendet werden.
 |  |  |  
| hansdergott  
          Beiträge: 55
 
 XP Mediacenter Edition; XP Home
 Delphi
 
 | 
Verfasst: So 26.04.09 12:09 
 
hallo noch mal zusammen
 also meint ihr das es ein viel sicherer schlüssel wäre wenn ich
 zb
 1. mit den anfangsbuchstaben und/oder den endbuchstaben arbeiten würde statt die textlänge
 2. das umwandeln mit floattostr() sein lassen würde
 3. die information nicht auf 2 werte sprich ins hex wandeln / teilen würde?
 
 hab ich das richtig verstanden?
 
 ich hab jetzt den schlüssel mit hilfe der anfangsbuchstaben und endbuchstaben aller 11
 eingabemöglichkeiten berechnet
 
 wie sicher ist das jetzt
 
 grüße
 _________________ User haften für Rechtschreibfehler
 |  |  |  
| BenBE 
          Beiträge: 8721
 Erhaltene Danke: 191
 
 Win95, Win98SE, Win2K, WinXP
 D1S, D3S, D4S, D5E, D6E, D7E, D9PE, D10E, D12P, DXEP, L0.9\FPC2.0
 
 | 
Verfasst: So 26.04.09 12:22 
 
	  |  hansdergott hat folgendes geschrieben  : |  	  | hallo noch mal zusammen 
 also meint ihr das es ein viel sicherer schlüssel wäre wenn ich
 zb
 1. mit den anfangsbuchstaben und/oder den endbuchstaben arbeiten würde statt die textlänge
 | 
 Nein, wenn die gesamte Eingabe in den Schlüssel eingeht, nicht nur eine Teil-Information
 	  |  hansdergott hat folgendes geschrieben  : |  	  | 2. das umwandeln mit floattostr() sein lassen würde | 
 Jap.
 	  |  hansdergott hat folgendes geschrieben  : |  	  | 3. die information nicht auf 2 werte sprich ins hex wandeln / teilen würde? | 
 Jap.
 	  |  hansdergott hat folgendes geschrieben  : |  	  | hab ich das richtig verstanden? | 
 Naja, gibt halt bereits bekannt Verfahren, mit denen man sowas realisieren kann, die für sowas wesentlich besser ist ...
 Zudem lassen sich bei einer festen Schlüssellänge immer gewissen Dinge über den Schlüssel aus dem Chiffrat herausfinden. Siehe Caesar-Verschlüsslung und wie man die bricht. Wenn da ein Angreifer weiß, dass Du einen Schlüssel von 800 Bit Länge nutzt, kannst Du ganz einfach für jedes Schlüsselbit herausfinden, wie dieses sein muss, um die Häufigkeitsanalyse mit den vermutlich verschlüsselten Daten hinzubekommen.
 Beispiel: Jedes 8. Bit (nämlich genau Bit 7 jedes Bytes) wird bei Plaintext meißtens 0 sein (weil ASCII), das Bit 6 aber vermutlich meist 1 (abgesehen von Leerzeichen und Interpunktion. Siehe Häufigkeitsanalyse.
 	  |  hansdergott hat folgendes geschrieben  : |  	  | ich hab jetzt den schlüssel mit hilfe der anfangsbuchstaben und endbuchstaben aller 11 eingabemöglichkeiten berechnet
 
 wie sicher ist das jetzt
 
 grüße
 | 
 theoretisch 256^22 = 2^176, rein praktisch aber wahrscheinlich eher 64^22 = 2^132, weil die meisten dort nicht alle Zeichen verwenden werden. Beides jetzt rein theoretische, obere Schranken. Aber wie gesagt: Schwachpunkt ist hier die mögliche Häufigkeitsanalyse des verschlüsselten Datenblocks, weshalb ein Angreifer über diesen wahrscheinlich mehr Erfolg haben wird und daher diesen verwendet ..._________________ Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.
 |  |  |  
| hansdergott  
          Beiträge: 55
 
 XP Mediacenter Edition; XP Home
 Delphi
 
 | 
Verfasst: So 26.04.09 16:18 
 
hi ich noch mal
 ein problem hab ich immer noch und das seit anfangan
 wenn ich mit
 		                       Delphi-Quelltext 
 									| 1:2:
 3:
 4:
 5:
 6:
 7:
 8:
 
 | input:=edit1.text;
 for i:=1 to length(input) do
 begin
 input[i]:=chr(ord(input[i]) xor ord(schluessel[x]));
 if x>length(schluessel) then begin x:=1; end;
 end;
 edit2.text:=input;
 |  arbeiten tue ist ja alles schön ung gut
 aber wenn ich das wieder rückgängig machen will
 kommt der text richtig wieder raus SOLANGE kein zeichen aus dem schlüssel
 im verschlüsselten text vorkommt
 sobald aber ein zeichen gleich ist sagen wir einfach mal das "x"
 dann decodiert er bis zu diesem "x" und alles danch ist falsch entschlüsselt
 habs schon statt xor mit "-" , "+" , "or"  "not or"  versucht geht aber alles solange wie
 kein zeichen gleich ist aber wehe wen doch 
 1. wie kommt das?
 2. wie kann man das umgehen?
 grüße_________________ User haften für Rechtschreibfehler
 |  |  |  
| BenBE 
          Beiträge: 8721
 Erhaltene Danke: 191
 
 Win95, Win98SE, Win2K, WinXP
 D1S, D3S, D4S, D5E, D6E, D7E, D9PE, D10E, D12P, DXEP, L0.9\FPC2.0
 
 | 
Verfasst: So 26.04.09 17:27 
 
0-Bytes haben in Strings eine Sonderbedeutung, was bei manchen Aufrufen der RTL zu netten Fehlerchen führt ... Daher nimmt man für sowas auch meist PChars, und regelt die Länge selber. Delphi macht da einfach manchmal zu viel Müll  _________________ Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.
 |  |  |  
| hansdergott  
          Beiträge: 55
 
 XP Mediacenter Edition; XP Home
 Delphi
 
 | 
Verfasst: Mo 27.04.09 10:38 
 
hi
 danke für den tipp
 
 ich schreib es jetzt um und benutze einen schlüssel mit 128bit
 und eine blocklänge von 128 bit mit dem aes rythmus
 ist glaube ich das sicherste
 und unkomplizierteste
 
 dank euch allen für die infos
 _________________ User haften für Rechtschreibfehler
 |  |  |  
| BenBE 
          Beiträge: 8721
 Erhaltene Danke: 191
 
 Win95, Win98SE, Win2K, WinXP
 D1S, D3S, D4S, D5E, D6E, D7E, D9PE, D10E, D12P, DXEP, L0.9\FPC2.0
 
 | 
Verfasst: Mo 27.04.09 10:45 
 
_________________ Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.
 |  |  |  |