Autor |
Beitrag |
hansdergott
      
Beiträge: 55
XP Mediacenter Edition; XP Home
Delphi
|
Verfasst: Sa 25.04.09 17: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 mal Moderiert 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 22: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 22: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 22: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 23: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 23:26, insgesamt 1-mal bearbeitet
|
|
jfheins
      
Beiträge: 918
Erhaltene Danke: 158
Win 10
VS 2013, VS2015
|
Verfasst: Sa 25.04.09 23: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 23: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 23: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 23: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: So 26.04.09 00: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 13: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 13: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 17: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 18: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 11: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 11: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.
|
|
|