Entwickler-Ecke :: Thema anzeigen - Verkomplizierung eines Verschlüsselungsverfahrens

Entwickler-Ecke

Sonstiges (Delphi) - Verkomplizierung eines Verschlüsselungsverfahrens

-delphin- - Do 26.04.07 20:39
Titel: Verkomplizierung eines Verschlüsselungsverfahrens

Servus (;
Ich habe ein Verschlüsselungsverfahren programmiert, was auf RandSeed und der damit verbundenen Zahlenreihe basiert. RandSeed wird durch ein Passwort ermittelt, deren Rechnung im Moment wiefolgt aussieht:

Quelltext

1:	errechnet:=errechnet(countord(Passwort[count]))+(count*ord(Passwort[count]));

Count ist die Laufvariable - das ganze steht in einer for-do-to-Schleife.

Meine Frage lautet jetzt, ob jemand einen Vorschlag hat, die Errechnung des RandSeeds so schwer wie möglich zu machen und somit das Prog sicherer, vielleicht mit Wurzel oder so?
Wichtig ist eigentlich bloß, dass beim gleichen Passwort auch immer die gleiche Zahl für RandSeed ermittelt wird und, dass es eben möglichst schwer ist.

Gruß & thX for help :D,
delphin

Chryzler - Do 26.04.07 21:02

Solange das Verschlüsselungsverfahren bekannt ist, nützt diese Art der Verschlüsselung gar nichts,
da ich locker per Bruteforce alle Möglichkeiten von Low(RandSeed) bis High(RandSeed) durchprobieren kann.

-delphin- - Do 26.04.07 21:14

Ja gut BruteForce kannste immer bringen...

Chryzler - Do 26.04.07 21:31

Okay, wie du meinst. Verfeinere die RandSeed-Generation so wie du willst, gib mir den Verschlüsselungsquelltext und ich entschlüssele dir einen deutschen Text, mit einem beliebigen Passwort, innerhalb von 5 Minuten. ;)

-delphin- - Do 26.04.07 21:39

der witz ist ja, dass du den quelltext nicht haben wirst Oo Dazu kommt, dass du normalerweise selbst die information mit randseed etc nicht hast....
Aber bitte:

Quelltext

1:	kSv(²—pÒñÝ‹ ‰Bec]Â-‘²HêYÿº€‰J4Ÿ²e>

gL, hF ;)

uall@ogc - Do 26.04.07 22:11

Es geht darum, dass man das Programm zum verschlüsseln hat -> debuggen oder einfach eingie sachen verschlüsseln.

JayEff - Do 26.04.07 22:14

Wie du hier zum Thema Verschlüsselung immer wieder finden kannst: Die Sicherheit eines Verfahrens DARF nicht auf der Geheimhaltung des Algorithmus basieren (da das unmöglich ist), sondern lediglich auf der Sicherheit des eingesetzten Passworts. Da dein Passwort immer genau EINE Zahl zwischen 0 und MaxInt ist, ist dein Verfahren ... naja ... von der Sicherheit her ganz weit unten ... ;)

-delphin- - Do 26.04.07 22:25

Das soll heißen? Müsste ich es in irgendeiner Form umschreiben oder ist das nicht möglich? Wie soll ein Passwort aussehen, das 'sicherer' ist?
Achja, gelöst hat es noch keiner :P

uall@ogc - Do 26.04.07 22:34

Benutze bitte die suche. Es wird hier keiner Versuchen das was du da gepostet hast zu entschlüsseln, aber für dich mach ich es mal:
Text: Delphi-Forum
Password: test

Und nu beweise mit mal, dass es nicht durch irgendeine Verschlüsselung möglich ist aus den beiden Daten oben genau das zu erzeugen was du unten als verschlüsseltene String stehen hast.

Gib mir das Programm, dann entschlüssel ich dir das...

-delphin- - Fr 27.04.07 14:43

uall@ogc hat folgendes geschrieben:

Und nu beweise mit mal, dass es nicht durch irgendeine Verschlüsselung möglich ist aus den beiden Daten oben genau das zu erzeugen was du unten als verschlüsseltene String stehen hast.

Das ist nicht der Sinn des Verschlüsselns, dir zu beweisen, dass das, was du geraten hast, falsch ist. Übrigens, wie überflüssigerweise zu erwähnen, es ist falsch.

Im Anhang die .exe und die .sec-Datei.

Sirke - Fr 27.04.07 17:46

-delphin- hat folgendes geschrieben:

Das ist nicht der Sinn des Verschlüsselns, dir zu beweisen, dass das, was du geraten hast, falsch ist. Übrigens, wie überflüssigerweise zu erwähnen, es ist falsch.

Streng genommen ist genau das der Sinn der Kryptographie! Denn nur wenn du außschließen kannst, dass diese Lösung nicht die richtige Lösung ist, kannst du behaupten, dass dein Verfahren eindeutig ist! Alles andere wäre eh eine unsichere Verschlüsselung!

Letzlich wirst du mit Zufallszahlen die mit Delphi erzeugt werden wenig erreichen können! Denn du wirklich die Sicherheit steigern willst, dann solltest du einen Pseudozufallszahlengenerator [http://de.wikipedia.org/wiki/Pseudozufallszahlengenerator] mit diesen Zufallszahlen speisen! Bei einem solchen kannst du, wenn er gut ist (auch wenn ich bezweifel, dass du es schaffen wirst, weil sich daran momentan Genies die Köpfe einrennen), von Sicherheitsprechen!

Die Random()-Funktion von Delphi ist zwar auch ein solcher, doch hat er zu wenige Ausgangsituationen, die du mittels RandSeed festlegen kannst!

-delphin- - Fr 27.04.07 18:09

Soll heißen, wenn RandSeed bei Kommazahlen oder noch besser bei irrationalen Zahlen starten würde, wäre es sicher?

Wie bitte soll man ausschließen können, dass das nicht die Lösung ist? Gib mir 5 Minuten und man programmiert ein Programm, das genau das bei dem Quelltext zur Lösung hat...

Sirke - Fr 27.04.07 18:22

-delphin- hat folgendes geschrieben:

Soll heißen, wenn RandSeed bei Kommazahlen oder noch besser bei irrationalen Zahlen starten würde, wäre es sicher?

Wenn dazu kommt, dass es bei jeder unterschiedlichen Zahl auch unterschiedliche Ergebnisse liefert würde ich sagen: JA, wobei ich eher "ja, es isch sicherer, als ohne" sagen würde.

Wenn Randseed 2^256 (weil es heute Standard ist) unterschidliche Startpositionen hätte und daraus unterschidliche Zufallsreihen liefern würde und diese nicht zurück- oder weiterrechenbar sind, dann wäre es schon sehr sehr gut!

Silas - Fr 27.04.07 18:52

Ich weiß nicht, ob die Idee sinvoll ist, aber:
Man könnte Ja ein Passwort, z.B. "Hallo", nehmen und den ANSI-Code von "H" als RandSeed verwenden, dann die "a"-te Zufallszahl errechnen, als RandSeed einsetzen, dann die "l"-te Zufallszahl und so weiter. Und wenn man das "o" auch hat, die nächste Randseed dann tatsächlich verwenden.

Silas

//EDIT: Das würde aber auch nur dann funktionieren, wenn der Code an sich nicht die Schwachstelle ist, sondern das PW

Sirke - Fr 27.04.07 19:10

@Silas: Auch das ist nicht wirklich eine verbesserung der Sicherheit! RandSeed ist ein 32-Bit Integer, also verwendet man so zu sagen einen 32-Bit-Schlüssel. Wenn man den Start um n Stellen verschiebt, dann muss das um 2^32 Stellen sein, damit man einen 2^64-Bit-Schlüssel erhält... diese 2^32 Stellen durch zu laufen würde eine "Ewigkeit" dauern!

Durch das Verschieben um den ASCII-Wert, würde eine Verschiebung um 2^8 Stellen dabei heraus kommen! Das bedeutet man erhält einen 40-Bit-Schlüssel ... das ist immer noch nicht wirklich sinnvoll!

Eine verbessere Random()-Funktion ist hier [http://www.delphipraxis.net/post560523.html#560523] zu finden! Die Zahl 134775813 kann variiren, sollte aber bestimmte Bedingungen erfüllen.

-delphin- - Fr 27.04.07 19:29

was soll das bringen, das randseed einfach mit 134775813 zu multiplizieren? oder hab ich das falsch verstanden?

Horst_H - Fr 27.04.07 21:21

Hallo,

leider habe ich da kaum Ahnung, aber vom reinen Anblick her, werden bei dem Zufallsgenerator nicht mehr Zufallszahlen erzeugt
Input 32 bit output 32 bit die wieder input werden.
Das sind also wieder nut 32-Bit Schlüssellänge.
Erzeuge doch einen MD-5 oder SHA-1 Hash aus deinem Paßwort und nimm immer 32 Bit Abschnitte als Randseed für einen Generator.
Bei MD-5 sind 128 Bit ja 4 x 32 Bit.
Du kannst jetzt 4 normale Generatoren laufen lassen wo bei die erzeugten Werte als XOR Schlüssel dienen. Vielleicht bestimmt Geneartor 1 zusätzlich, welche Permutation der neuen Ranseed's genommen werden soll.
Soll heißen: es gibt 4! Möglichkeiten welcher Generator X mit dem Ergrbnis von Generator Y als neuem Randseed gefüttert wird.
Das heisst , das die Generatoren fast ständig (bei 1 von 24 nicht) Ihre Position wechseln.

Gruß Horst

-delphin- - Fr 27.04.07 21:38

das habe ich nich verstanden und werde es wohl auch nie verstehen ;)

BenBE - Sa 28.04.07 00:57

Mal Abgesehen davon, dass es falsch war ...

Wenn ich 4 verschiedene Vignere-Verschlüsslungen nacheinander mit der gleichen Schlüssellänge ablaufen lasse, so ist die Länge des Gesamtschlüssels nicht 4 mal die Ausgangslänge, sondern gleich dem kgV der Ausgangsschlüssellängen ...

Um die Schlüssellänge stark zu verlängern müsstest Du 4 Zufallsgeneratoren haben, die alle eine prime Wiederholfrequenz haben, deren Periodizität 4 aufeinanderfolgende teilerfremde Zahlen sind.

d.h. Längen 2,4,8,16 = schlecht (Periode 16 = 2^4)
Längen 3,5,7,11 = besser. (Periode 1155 = 2^10,173677)

Fazit: Lass die Finger von, wenn Du nicht mal die Grundlagen der Kryptographie verstehst!

tommie-lie - Sa 28.04.07 11:20

BenBE hat folgendes geschrieben:

Fazit: Lass die Finger von, wenn Du nicht mal die Grundlagen der Kryptographie verstehst!

Richitg. Es ist naiv, anzunehmen, daß man als Laie mal eben einen sichereren Algorithmus aus dem Ärmel schüttelt, wenn sich ganze Arbeitsgruppen von Mathematikern einige Jahre lang mit nur einem einzigen Verfahren beschäftigen.
delphin, nimm ein existierendes Kryptosystem, zum Beispiel DSA oder RSA. Beide sind um ein vielfaches sicherer als das, was jeder einzelne von uns hier in der Lage ist, sich auszudenken.

-delphin- - Sa 28.04.07 20:36

Hm, die Sache ist, dass ich nächste Woche Präsentation habe und eben über Verschlüsselung machen muss. Und da mein Lehrer nicht will, dass ich einfach bestehende Algorithmen nachprogrammiere, habe ich eben das gemacht. Außerdem habe ich euch gefragt, ob man das Programm dadurch noch etwas verbessern kann und nicht, ob man es dadurch zum sichersten unserer Zeit macht. Wenn als einziges Ergebnis dabei herausspringt, dass man es besser lassen sollte, wenn man nicht sofort alles zu Kryptographie versteht, dann ist das leider ein nutzloses Forum hier.
@uall@ogc: Schon ein Resultat?

JayEff - Sa 28.04.07 21:10

-delphin- hat folgendes geschrieben:

Wenn als einziges Ergebnis dabei herausspringt, dass man es besser lassen sollte, wenn man nicht sofort alles zu Kryptographie versteht, dann ist das leider ein nutzloses Forum hier.

Danke, das hören wir gern. Jemand der keine Ahnung vom Thema hat und ein Referat darüber halten muss. Super, reife Leistung. Von einer Präsentation über Verschlüsselung erwarte ich aber nicht nur irgendeine Beispielverschlüsselung, sondern auch Hintergrundwissen. Ich vermute, du willst keinen sicheren Algo sondern nur irgendeinen. Gut, den hast du. Dann solltest du dich informieren, was einen sicheren Algo auszeichnet und warum deiner weniger sicher ist. Soetwas gehört in eine anständige Präsentation über Verschlüsselungen. Aber wenn du lieber denen, die dir mit Rat und Tat bei Seite stehen Beleidigungen an den Kopf wirfst, brauchst du keine weitere Hilfe erwarten :motz: Viel Glück noch. :evil:

-delphin- - Sa 28.04.07 21:22

Ich werfe euch keine Beleidigungen an den Kopf, jedenfalls fällt mir keiner ein, bei dem es so gewesen sein sollte. Ich wollte lediglich betonen, dass zu sagen 'du verstehst den Sinn nicht - lass es' wohl nicht gerade eine pädagogische Glanzleistung ist, findest du nicht?
Hast du einen Vorschlag, wenn mein Lehrer keinen der anerkannten möchte wie AES, DES, Diffie-Hellman, RSA oder ECC? Ich bin weder ein Informatik- noch ein Mathegenius und trotzdem hätte ich gerne artgerechte Hilfe. Man könnte zum Beispiel ein zweites Passwort einbauen oder so, bloß, wenn man sie dann verknüpft, hat man wieder bloß eine Zahl zwischen 0 und MaxInt oder?

Chryzler - Sa 28.04.07 22:03

-delphin- hat folgendes geschrieben:

Man könnte zum Beispiel ein zweites Passwort einbauen oder so, bloß, wenn man sie dann verknüpft, hat man wieder bloß eine Zahl zwischen 0 und MaxInt oder?

Naja, es ist eigentlich vollkommen egal, wie du aus dem Passwort dein RandSeed berechnest, die Schlüssellänge (hier 32-Bit) ändert sich ja nicht. Du könntest höchstens mehrere Zufallsgeneratoren benutzen und die kombinieren, um die Verschlüsselung 'etwas' sicherer zu machen. Außerdem solltest du darauf achten, dass du das Passwort noch sonst irgendwie in die Verschlüsselung einbaust, als nur den Zufallszahlengenerator damit zu initialisieren. Du könntest zum Beispiel nach der jetzigen "Vorverschlüsselung" noch den Text mit dem Passwort XOR-Verschlüsseln. Das macht die Sache auf jeden Fall schonmal komplizierter.

PS: 32-Bit-Verschlüsselung ist nichts anderes als eine Verschlüsselung mit einem Passwort der Länge 4 Zeichen ;)

-delphin- - Sa 28.04.07 22:27

Und wo bekomme ich einen anderen Zufallsgenerator her?
XOR-Verschlüsseln?

Chryzler - Sa 28.04.07 23:45

Naja, das mit den mehreren Zufallsgeneratoren ist wohl eher Schwachsinn, denk ich. Mach lieber das mit der XOR-Verschlüsselung. Dazu findest du sehr viel hier. Suche in der Entwickler-Ecke

XOR VERSCHL?SSELUNG

Chryzler - So 29.04.07 00:06

-delphin- hat folgendes geschrieben:

@uall@ogc: Schon ein Resultat?

Passwort: A3fgh
Original-Dateiendung: .txt
Nachricht: zehn chinesen mit dem kontrabass

Okay, zugegeben, 5 Minuten waren es nicht. Aber du hast uns ja auch nicht den Quellcode gegeben. ;)

Comp-Freak - So 29.04.07 05:40

tommie-lie hat folgendes geschrieben:

BenBE hat folgendes geschrieben:

Fazit: Lass die Finger von, wenn Du nicht mal die Grundlagen der Kryptographie verstehst!

Richitg. ... bla bla ... aus dem Ärmel schüttelt, wenn sich ganze Arbeitsgruppen von Mathematikern einige Jahre lang mit nur einem... bla bla bla

Die mathematiker haben sicher auch mahl klein angefangen :).
Auserdem weiss man ja nie was rauskommt :). Einstein hat jeder am anfang auch nur ausgelacht ;).

btw. er hat ja nicht for gehabt einen weltberuehmten sicherheits algorithm zu erfinden und wenns im spass macht dan las in doch :).

-delphin- - So 29.04.07 09:42

Schön, schön ;) Darf ich fragen, wie du das angestellt hast, @chryzler? :)

Hmm, wenn ich das recht überblicke, dann ist bei XOR der Nachteil, dass der Schlüssel immer die Länge der zu überbringenden Nachricht haben muss, oder? Außerdem wüsste ich nicht, wie man das XOR noch nachträglich in meinen Algorithmus einbauen soll, aber wenn sich jemand bereit erklärt es zu machen, stelle ich gerne den Quelltext ein ;)

Comp-Freak - So 29.04.07 10:04

benuzt doch einfach dein algorithm und verschlussle das resultat dan mit xor :). geht das nicht? wen das password zu kurz ist multpliziere es doch einfach bei zwei.

Chryzler - So 29.04.07 11:33

-delphin- hat folgendes geschrieben:

Schön, schön ;) Darf ich fragen, wie du das angestellt hast, @chryzler? :)

Zuerst mal dein Programm debuggt, die Enkodierschleife gesucht, in Delphi-Code umgeschrieben, und dann die passende Dekodierfunktion geschrieben (Jo, hätte auch gleich die Dekodierschleife nehmen können ;)). Dann noch in einer Schleife alle RandSeeds von Low(RandSeed) bis High(RandSeed) durchlaufen lassen, jedesmal deinen Text entschlüsseln und automatisch prüfen, ob ein sinnvoller Text rauskommt (= wenn fast keine Sonderzeichen drin vorkommen). Alle vermutlichen Treffer in eine Datei reinschreiben lassen und 10 Minuten warten, bis das Bruteforcen fertig ist. Jetzt musst du nur noch mit dem Editor in der Datei einen lesbaren Text suchen. Da du das Passwort und die Dateiendung gleich mitspeicherst, war das natürlich auch kein Problem mehr. ;)

Sirke - So 29.04.07 11:41

Die XOR-Verknüpfung [http://de.wikipedia.org/wiki/XOR] solltst du, wenn du eine Verschlüsselung vorstellen sollts, auf jeden Fall einbauen, weil alle Verschlüsselungen (zumindest fallen mir gerade keine ein die nicht) diese Verknüpfung benutzten!

Auch S-Boxes [http://de.wikipedia.org/wiki/S-Box] könnte man vorstellen!

Der Algo RC4 [http://de.wikipedia.org/wiki/RC4] ist auch sehr gut um einen Einstieg zu finden, weil er S-Boxes enthält und gleichzeitig mit einem Pseudozufallsgenerator arbeitet, den du ja auch einbauen wolltest!

Vllt kann man eben alles einfügen, natürlich nicht einfach so, sondern wenn dann wohl überlegt, weil zu viel letztlich gar nichts an Sicherheit bewirken wird, sondern nur Geschwindigkeit kostet ODER man baut einzelne Teile ein unt enthäl am ende vllt drei verschiedene Verschlüsselungen und kann eben alle nach der Sicherheit betrachten!

Off-Topic: Ein Lehrer, der einen Schüler ein Referat über einen eigenen Algo halte lässt, kenn sich glaube ich wenig mit Verschlüsselungen aus! Gerade Security Through Obscurity [http://de.wikipedia.org/wiki/Security_through_obscurity] ist dabei nämlich ein Punkt, der in der Kryptographie sehr wichtig ist und hierbei total außer acht gelassen wird!

-delphin- - Mo 30.04.07 07:16

Die Sache ist, bei Musik, Videos oder Bildern geht das sicher nicht mehr so einfach zu entschlüsseln -> denn da wirst du mit deiner Wenig-Sonderzeichen-Überprüfung nicht weit kommen, die richtige Datei ist voll davon ;)

alzaimar - Mo 30.04.07 07:50

-delphin- Wie wäre es, wenn Du dich mit dem mathematischen Hintergrund von Kryptographie beschäftigst, und Dir eine Einführung in das Dechiffrieren verpasst?

Es gibt dermaßen viele Möglichkeiten, einen chiffrierten Text anzugreifen, das keiner von Uns (na, vielleicht einer ;-) ) auch nur im Ansatz einen einigermaßen sicheren Algorithmus (besser :Verfahren) entwickeln kann.

Mit GetTickCount verwurstete Zufallszahlen, wie z.B. der von Sirke gepostete Link, haben den Nachteil, das sie nicht deterministisch sind, ergo kann man damit verschlüsselte Texte auch nicht dechiffrieren.

Ein einfacher sicherer Chiffrierer verwendet einen Schlüssel, der am Besten genauso lang ist, wie der zu verschlüsselnde Text. Nimm Dir z.B. die Bibel (Ausgabe X von Y etc.) Wer nicht genau die gleiche Bibel hat, wird es nie schaffen, das zu knacken. Der dabei verwendete Algorithmus kann ruhig simpel sein (XOR z.B.) .

Wenn Du dann noch jedes Mal ein anderes Buch nimmst ('One-Time-Pad'), dann sieht die Sache noch besser aus.

Dabei ist die Schwachstelle aber, das Du der anderen Seite mitteilen musst, mit welchem Buch du gerade verschlüsselst.

Die Enigma-Story verlief so ähnlich: Da waren es keine Bücher, sondern Chiffrierräder (soweit ich weiss). Nachdem man eine Enigma (=Algorithmus) sowie die Sammlung der Räder (=Schlüssel) hatte, war der Rest ein Kinderspiel.

Ausgehend von diesen Überlegungen solltest Du in deiner Präsentation nochmal die Geschichte der Verschlüsselung, das o.g. Dilemma, sowie Auswege zeigen, die die moderne Mathematik liefert. Wenn Dein Lehrer das nicht will, dann sage eben, das es moderne Verfahren gibt, die dieses Problem gelöst haben, Du aber hier nicht weiter darauf eingehen willst/sollst/darfst.

Auch bei den derzeit besten Verfahren zeichnet sich ein Problem ab, denn auch die als extrehm sicher geltenden Verfahren lassen sich durch Brute-Force-Attacken knacken und spätestens mit den Quantencomputern muss man sich etwas Neues ausdenken.

Wie Du siehst, ist die Kryptographie ein ständiges Katz-Und-Maus-Spiel.

-delphin- hat folgendes geschrieben:

... dann ist das leider ein nutzloses Forum hier.

-delphin- hat folgendes geschrieben:

Ich werfe euch keine Beleidigungen an den Kopf

Äh doch, jedem Forums-Teilnehmer, der Anderen in den vergangenen Jahren geholfen hat.

Wie gesagt: Die einhellige Meinug hier ist, das Du einen einigermaßen sicheren Algo nur dann findest, wenn du die Grundlagen verstanden hast. Überhaupt ist es doch bescheuert, über so ein Thema ohne Hintergrundwissen heranzugehen.

Comp-Freak hat folgendes geschrieben:

Die mathematiker haben sicher auch mahl klein angefangen :).
Auserdem weiss man ja nie was rauskommt :). Einstein hat jeder am anfang auch nur ausgelacht ;).

Ludwig Wittgenstein hat folgendes geschrieben:

Wovon man nicht sprechen kann, darüber muss man schweigen

Alfred Tezlaff hat folgendes geschrieben:

Wenn man keine Ahnung hat, sollte man bescheiden das Maul halten

Dieter Nuhr hat folgendes geschrieben:

Wenn man keine Ahnung hat: Einfach mal Fresse halten.

:autsch: Da kann man ja gleich Algorithmen dadurch generieren, in dem man Codefragmente per Zufall aneinander reiht...

Chryzler - Mo 30.04.07 14:12

-delphin- hat folgendes geschrieben:

Kannst ja mal ne MP3-Datei verschlüsseln und mir geben, ich denk das krieg ich hin :)

-delphin- - Mo 30.04.07 20:46

Ich würde gerne, ist allerdings zu groß. Kann ichs dir per Mail schicken?

Chryzler - Mo 30.04.07 20:54

-delphin- hat folgendes geschrieben:

Ich würde gerne, ist allerdings zu groß. Kann ichs dir per Mail schicken?

Jo...

-delphin- - Di 01.05.07 01:45

habs dir an deine hotmail-addy geschickt.. viel spaß ;)

Comp-Freak - Di 01.05.07 10:25

was ist der unterschied zwischen text und music? in musik sucht er einfach nach einem header stat normalen woertern ... oder?

BenBE - Di 01.05.07 11:52

MP3s besitzen in dem Sinne keinen direkten Header; zumindest kann der Header an jeder Position auftauchen. Außerdem sind MP3s nahezu gleichverteilt in ihren vorkommenden Byte-Folgen (Besser sind nur einige komprimierte Datenformate).

Auch (aber so fieß schätz ich unseren Threadersteller mal nicht ein) kann man in MP3s beliebige Daten einbinden ;-)

Zwischen MP3s und Texten liegt also zumindest im zu erwartenden Zeichenvorrat ein kleiner Unterschied (und auch bestimmte Häufigkeitsanalysen sind etwas komplizierter anzuwenden.

Chryzler - Di 01.05.07 13:15

-delphin- hat folgendes geschrieben:

habs dir an deine hotmail-addy geschickt.. viel spaß ;)

Hab gedacht die Datei beginnt mit einem ID3-Tag. Ausserdem hätt ich nicht gedacht, dass das Password so lang ist. Und in meiner Dekodierfunktion war auch noch ein Fehler drin. Aber letzendlich hats dann doch geklappt.

Passwort: eintrachtfrankfurtdeutschermeister

Du siehst, du solltest deine Verschlüsselung unbedingt verbessern ;)

Comp-Freak hat folgendes geschrieben:

was ist der unterschied zwischen text und music? in musik sucht er einfach nach einem header stat normalen woertern ... oder?

Ja, das dachte ich auch, denn bei meinen MP3-Dateien kommt fast bei jeder der ID3-Tag am Anfang der Datei vor. Ausgerechnet bei user profile icon

-delphin-s MP3 nicht ;) Aber die meisten Bild-, Audio- und Videodateien haben einen schönen langen Header, das macht die Sache natürlich sehr einfach.

BTW @delphin: Hast du jetzt schon versucht, die Verschlüsselung zu verbessern? Weil so kann man das nicht lassen ;)

tommie-lie - Di 01.05.07 13:37

-delphin- hat folgendes geschrieben:

[x] /usr/share/file/* existiert
Es ist ebenso naiv anzunehmen, daß ein Angreifer nicht in der Lage ist, ein Unix zu bedienen. Auch Word-Dateien, MPEG-Videos und Bitmaps haben signifikante Merkmale, die man identifizieren kann.

-delphin- hat folgendes geschrieben:

Hm, die Sache ist, dass ich nächste Woche Präsentation habe und eben über Verschlüsselung machen muss.

Warum hast du das nicht von Anfang an gesagt?

-delphin- hat folgendes geschrieben:

Ich habe ein Verschlüsselungsverfahren programmiert,[...] Meine Frage lautet jetzt, ob jemand einen Vorschlag hat, die Errechnung des RandSeeds so schwer wie möglich zu machen und somit das Prog sicherer, vielleicht mit Wurzel oder so?

Das klingt nunmal nach "Ich hab' keine Ahnung, will aber den sichersten Algorithmus bauen wo gibt."
Du sollst also einen Vortrag halten, das ändert doch die gesamte Situation. Da solltest du nicht versuchen, einen möglichst komplizierten Algorithmus zu finden, den keiner deiner Mitschüler nachvollziehen kann, sondern einen möglichst einfachen, den jeder versteht und an dem du die Schwächen erläutern kannst. Zum Beispiel, daß du ihn theoretisch durch weitere Rechenoperationen bei der Schlüsselerzeugung hättest komplizierter machen können, aber daß das nur Security Through Obscurity ist, was in der Praxis keinerlei Rolle spielt. Am einfachen Algorithmus kannst du vielleicht auch den Assembler-Code zeigen, in dem man auch ohne Assembler-Kenntnisse die Rechenoperationen erkennen kann, damit die anderen ein Bild davon kriegen, wie einfach es ist, auch ohne den Programmquellcode noch an die mathematischen Grundlagen eines Verfahrens zu gelangen.
Als nächstes kannst du dann theoretische Verfahren vorstellen, die allesamt besser sind, als dein Verfahren, beispielsweise Blowfish, die Besonderheit von DES und warum 3DES tatsächlich besser ist als DES (was keinesfalls selbstverständlich ist).
Dann kannst du immer noch auf asymmetrische Kryptosysteme eingehen, die wieder eine ganz andere Art von Sicherheit bieten (Stichwort shared secret).
Es gibt so viele Möglichkeiten, einen Vortrag über Kryptosysteme zu halten, ohne einige Jahre lang Mathematik studiert zu haben.

Außerdem denke ich, daß zwischen:

-delphin- hat folgendes geschrieben:

Und da mein Lehrer nicht will, dass ich einfach bestehende Algorithmen nachprogrammiere, habe ich eben das gemacht.

und

-delphin- hat folgendes geschrieben:

Hast du einen Vorschlag, wenn mein Lehrer keinen der anerkannten möchte wie AES, DES, Diffie-Hellman, RSA oder ECC?

ein großer intentioneller Unterschied besteht. Du sollst dich vielleicht nicht nur auf einen bestehenden Algorithmus beschränken, auch weil sie in der Regel zu komplex sind, um sie in einer Schulstunde vor unterschiedlich mathematisch begabten Schülern vorzustellen. Aber ich denke, er wird sicherlich nichts dagegen haben, wenn du anhand dieser Algorithmen die einzelnen Vorteile bestimmter Verfahren erläuterst, ohne zu sehr in Implementationsdetails abzuschweifen.
Aber am besten fragst du ihn da nochmal genauer, nachdem du dir genaue Gedanken darüber gemacht hast, wie du deinen Vortrag am besten strukturierst, damit am Ende deine Mitschüler mit einem korrekten Verständnis von Kryptographie den Raum verlassen und nicht mit dem Gedanken "Boah ey, ich setz' mich jetzt auch 'ne halbe Stunde hin und bau voll den krassen Verschlüsselungsalgorithmus den niemand hacken kann".

-delphin- - Mi 02.05.07 09:11

Chryzler hat folgendes geschrieben:

Du siehst, du solltest deine Verschlüsselung unbedingt verbessern ;)

Nun, du entschlüsselst die Dinger ja.. Wäre es eine Verbesserung die Sache doppelt zu verschlüsseln, also gerade das ganze nochmal, damit man, wenn man das erste Mal entschlüsselt nur Sonderzeichen hat, obwohl man richtig entschlüsselt hat?

BenBE - Mi 02.05.07 13:23

Am besten nehme man hierfür eine doppelte ROT13-Verschlüsslung, bzw. eine doppelte XOR-Kodierung. ;-)

Auch immer gern verwendet wird eine Komprimierung vor der eigentlichen Verschlüsslung, was aber auch gewisse Spuren hinterlässt nach denen man suchen kann.

JayEff - Mi 02.05.07 17:19

Nun, ne doppelte Xor is ja schön und gut, aber bloß nicht mit dem selben Schlüssel :shock:
Ich hab im ersten Moment gedacht, eine doppelte Xor ist das selbe wie eine Xor mit einem anderen Schlüssel, was dann natürlich nix bringen würde (ausser das Schlüsselwort zu Sonderzeichen zu machen :gruebel: )

Quelltext

1:
2:
3:
4:
5:
6:
7:

    11001100=204      11001100=204      10101010=170
xor 10101010=170  xor 10001110=142  xor 00100100=36
============      ============      ============
    01100110=102      01000010= 66      10001110=142
xor 00100100= 36
============  
    01000010= 66

Damit hätte ich ja das selbe Ergebnis wie eine doppelte Verschlüsselung, mit nur einer Verschlüsselung. Der Punkt an dem sich der Sicherheitsgrad hierbei verbessert ist lediglich die Sicherheit des Passworts, wenn nicht bekannt ist, dass xor 2 mal mit verschiedenen Passwörtern angewandt wird. Ist das bekannt (was per Definition zutrifft), kann man aus Passwort1 xor Passwort2 das finale Passwort errechnen (siehe Beispiele).

Vielleicht erklärst du nochmal etwas genauer, was du mit doppelter xor meinst, BenBE :shock: ... Oder sollte der ;) Smilie soviel bedeuten wie "Nur 'n Scherz" ? :mrgreen:

tommie-lie - Mi 02.05.07 17:25

JayEff hat folgendes geschrieben:

Vielleicht erklärst du nochmal etwas genauer, was du mit doppelter xor meinst, BenBE :shock: ... Oder sollte der ;) Smilie soviel bedeuten wie "Nur 'n Scherz" ? :mrgreen:

Offensichtlich ist dir nicht klar, was ROT13 ist ;-)

BenBE hat folgendes geschrieben:

Am besten nehme man hierfür eine doppelte ROT13-Verschlüsslung, bzw. eine doppelte XOR-Kodierung. ;-)

Neee, lass mal, ROT26 ist doch viel sicherer, das ist schon lange bewiesen. :mrgreen:

JayEff - Mi 02.05.07 17:36

Jaaa das ROT13 ... :roll: Das hab ich glatt überlesen... Ich stimme aber tommie zu, ROT26 ist wesentlich sicherer :|

Sinspin - Mi 02.05.07 18:16

Ich habe mir vor einiger Zeit ein OTP basiertes Verfahren geschrieben bei dem sowohl der Schlüssel wie auch die Matrix über einen Zufallsgenerator (ISSAC) erzeugt werden. Zudem komprimiere ich die Daten vorher noch mit dem 7zip Algo.
Für die Initialisierung der Zufallsgeneratoren (die 256 Seed Werte haben) verwende ich mein Passwort aus dem ich eine Serie von MD5 Checksummen bilde in die ich zudem noch "Salz streue", also den MD5 mit verschiedenen Werten initialisiere.
Absolute, 100%-ige Sicherheit ist unmöglich. Aber ich denke einmal dass das ganze nicht allzu einfach zu knacken ist.

Das Programm dient mir als Passwortdatenbank und als Komprimierungs- und Verschlüsslungstool. Wer haben will, der kann.

Chryzler - Mi 02.05.07 18:50

Sinspin hat folgendes geschrieben:

Ja, warum nicht? Stells doch einfach mal rein, vielleicht kanns der ein oder andere brauchen, so wie ich :)
Ich werd jetzt auch mal mein eigenes Verschlüsselungsprog schreiben...

Sinspin - Mi 02.05.07 19:18

Danke für dein Interesse. Ich hatte vor einer ganzen weile schoneinmal versucht das Programm hier vorzustellen. Jedoch mit ziemlich geringem Erfolg.

Hier der Link zum Thread:
EDL Explorer [http://www.delphi-forum.de/viewtopic.php?p=392033]

Sirke - Sa 05.05.07 11:05

BenBE hat folgendes geschrieben:

Auch immer gern verwendet wird eine Komprimierung vor der eigentlichen Verschlüsslung, was aber auch gewisse Spuren hinterlässt nach denen man suchen kann.

Es muss ja noch nicht einmal Spuren hinterlassen, es beruht wieder auf Secority By Obsecurity und bringt daher keine praktische Sicherheit!

OffTopic: In diesem Thema wird vermehrt über eigene Verschlüsselungsverfahren gesprochen! Daher könnte man ja ein Gemeinschaftprojekt starten, in dem man ein eigenen Algo versucht zu entwickeln, d.h. nicht, dass ich auch nur annäherungsweise davon ausgehe, dass er sicher wird, weil ich glaube, dass es wenige in diesem Forum gibt, die wirklich Ahnung von der Materie haben. Aber vllt wäre das sowohl für Anfänger, weil diese einiges lernen könnten, als auch für Fortgeschrittene und Profis eine gute Sache!
Was haltet ihr davon?

Chryzler - Sa 05.05.07 11:48

Sirke hat folgendes geschrieben:

OffTopic: In diesem Thema wird vermehrt über eigene Verschlüsselungsverfahren gesprochen! Daher könnte man ja ein Gemeinschaftprojekt starten, in dem man ein eigenen Algo versucht zu entwickeln, d.h. nicht, dass ich auch nur annäherungsweise davon ausgehe, dass er sicher wird, weil ich glaube, dass es wenige in diesem Forum gibt, die wirklich Ahnung von der Materie haben. Aber vllt wäre das sowohl für Anfänger, weil diese einiges lernen könnten, als auch für Fortgeschrittene und Profis eine gute Sache!
Was haltet ihr davon?

OffTopic: Man könnte auch nen Algo-Wettbewerb machen. Jeder kann seinen eigenen Algo schreiben, und der wird dann nach Geschwindigkeit, Sicherheit und Komplexität bewertet. Fragt sich allerdings, wie man die Sicherheit eines Algos bestimmt. Oder haben wir hier einen Cryptoexperten im Forum? :)

tommie-lie - Sa 05.05.07 12:06

Sirke hat folgendes geschrieben:

BenBE hat folgendes geschrieben:

Auch immer gern verwendet wird eine Komprimierung vor der eigentlichen Verschlüsslung, was aber auch gewisse Spuren hinterlässt nach denen man suchen kann.

Es muss ja noch nicht einmal Spuren hinterlassen, es beruht wieder auf Secority By Obsecurity und bringt daher keine praktische Sicherheit!

Umgekehrt. Security Through Obscurity bringt keine theoretische (mathematische, beweisbare, cryptografische) Sicherheit, aber sehr wohl eine praktische. Obfuszierter Code und ein nicht-öffentliches Verfahren stellen rein praktisch eine sehr viel größere Hürde dar, als ein bekanntes, gut dokumentiertes Verfahren und öffentliche Implementationsdetails.

-delphin- - Di 08.05.07 07:10

Kann mir bitte jemand mal genau beschreiben, wie ich so einen Algorithmus entschlüssele und vll auch Links zu den Programmen dazu? Das könnte ich vll. in den Vortrag einbauen, wär vll ganz nett ;)

Chryzler - Do 10.05.07 17:04

-delphin- hat folgendes geschrieben:

Kann mir bitte jemand mal genau beschreiben, wie ich so einen Algorithmus entschlüssele und vll auch Links zu den Programmen dazu? Das könnte ich vll. in den Vortrag einbauen, wär vll ganz nett ;)

Jo, kommt bestimmt gut, wenn du zuerst deinen Algo vorstellst, und dann die anderen fragst, wie man denn den Algo angreifen könnte.
Es ist ja ganz einfach:
Du berechnest aus dem Passwort ja deinen RandSeed, also musst du folglich mit einem Programm, das du dir schreibst, alle Möglichkeiten von RandSeed durchprobieren, also von Low(RandSeed) bis High(RandSeed). Dann entschlüsselst du mit jedem RandSeed den verschlüsselten Text. Jetzt muss dein Programm nur noch rausfinden, ob das entschlüsselte einen Sinn ergibt, d.h. ob bei einer MP3-Datei ein ID3-Tag vorkommt, oder ob bei einer TXT-Datei nur sehr wenige Sonderzeichen vorkommen etc. Wenn es einen Sinn ergibt, dann hast du möglicherweise das Passwort geknackt, ansonsten einfach weitersuchen. Wenn du am Ende (also bei High(RandSeed)) angelangt bist, und immernoch keinen Treffer hast, dann haste Pech ;)
Wenn du willst, kannst du den Source von meinem Knack-Prog für deinen Algo haben, wenn dir das was nützt. Oder ist es schon zu spät?

-delphin- - Fr 11.05.07 14:59

ne gib mal den source, wäre ganz nett (; aus privatem interesse, hab 12 punkte auf das ganze bekommen ;)

Chryzler - Fr 11.05.07 16:22

Da. Das ist jetzt die MP3-Version. Die Text-Version sieht etwas anders aus, mit IsGerman.

-delphin- - Fr 11.05.07 17:03

mit was öffne ich das?

Chryzler - Fr 11.05.07 17:06

Ehm, mit WinRAR [http://www.winrar.com/] (was mittlerweile jeder haben sollte), 7Zip [http://www.7zip.org/] (die Anschaffung lohnt sich ebenfalls) oder anderen Packprogrammen.

-delphin- - Fr 11.05.07 17:20

incorrect command line.. hoffentlich bin ich für die sache zu blöd oO

Chryzler - Fr 11.05.07 18:00

-delphin- hat folgendes geschrieben:

incorrect command line.. hoffentlich bin ich für die sache zu blöd oO

Bei was? Kannst du das Archiv nicht entpacken oder läuft mein Prog bei dir nicht?
Hier haste ne Zip-Datei...

-delphin- - Fr 11.05.07 19:31

Was berechnet das Programm? Jede Menge RandSeed's, alle 2 Minuten einen, teilweise negative.. aber weshalb?oO und besser: für was?

Chryzler - Fr 11.05.07 19:47

Nochmal erklär ichs dir nicht.

Chryzler hat folgendes geschrieben:

Du berechnest aus dem Passwort ja deinen RandSeed, also musst du folglich mit einem Programm, das du dir schreibst, alle Möglichkeiten von RandSeed durchprobieren, also von Low(RandSeed) bis High(RandSeed). Dann entschlüsselst du mit jedem RandSeed den verschlüsselten Text. Jetzt muss dein Programm nur noch rausfinden, ob das entschlüsselte einen Sinn ergibt, d.h. ob bei einer MP3-Datei ein ID3-Tag vorkommt, oder ob bei einer TXT-Datei nur sehr wenige Sonderzeichen vorkommen etc. Wenn es einen Sinn ergibt, dann hast du möglicherweise das Passwort geknackt, ansonsten einfach weitersuchen. Wenn du am Ende (also bei High(RandSeed)) angelangt bist, und immernoch keinen Treffer hast, dann haste Pech ;)

Das Programm probiert genau 4294967295 RandSeeds durch, nicht alle 2 Minuten einen, sondern tausende pro Sekunde. Für was? Damit hab ich deine Verschlüsselung geknackt, falls du dich noch dran erinnern kannst. Zuerst fragst du wie ichs gemacht hab, dann erklär ich dir alles Schritt für Schritt, und dann fragst du, für was das Programm ist. :roll:
Wenn noch was unklar ist, dann könnte auch Wikipedia helfen: Suche in Wikipedia

BRUTEFORCE

-delphin- - Fr 11.05.07 20:06

Hm, Frage falsch gestellt. Was das Programm macht, ist mir klar, aber welche Datei versucht es zu entschlüsseln? Ich hab' sie in nem eigenen Ordner und lade da ja keine Datei rein oder so und trotzdem fängt das Ding an zu rechnen...

Chryzler - Fr 11.05.07 20:18

Achso.

Delphi-Quelltext

1:
2:
3:

M := HexToStr('D1 A0 8D 3E ED 3F 40 4F F5 71 FA 5C 9A 8A 30 49
               F6 FE 43 F1 AF AF 9A 9C CE 6A B7 85 6A F2 7A 93
               FD AF BB 13 FD 0A 30 FA 40 61 B7 1B 71 55 E6');

Die Funktion wandelt die einzelnen Hexwerte in einen String um. Die Hexwerte sind nichts anderes als der Anfang deiner verschlüsselten Datei. Da das Bruteforcen viel zu lange dauern würde, wenn ich jedesmal die komplette Datei entschlüssel, werden hier nur die ersten 47 Bytes der Datei entschlüsselt.
Übrigens: die Fortschrittanzeige geht zuerst von 100% zu 0% und dann wieder auf 100%. Dann isses fertig.

-delphin- - Sa 12.05.07 10:33

ist mein Programm dann sicherer, wenn ich ihm sage, er soll doch bitte die ersten z.B. 100 Byte mit irgendwelchen Zeichen füllen und bei der Entschlüsselung wieder löschen? Bzw. wahrscheinlich ist es nicht sicherer, aber unbequemer zu entschlüsseln...

Chryzler - Sa 12.05.07 10:58

Sicherer wird es dadurch ganz bestimmt nicht, denn mein Prog kann auch die ersten 100 Bytes löschen. Und das nützt dir auch nur was, wenn der Verschlüsselungsalgo nicht bekannt ist, was er bei dir aber ist, du hast uns ja die EXE geliefert. ;)

-delphin- - Sa 12.05.07 23:09

Hm joa, aber normal verteile ich die ja nicht - was zumindest für etwas mehr Arbeit sorgt. Nun war ja nur für ne Präsentation.

derDoc - So 13.05.07 00:50

Sirke hat folgendes geschrieben:

Fragt sich allerdings, wie man die Sicherheit eines Algos bestimmt.

Dazu gibt es diverse Möglichkeiten. Üblicherweise würde man zuerst nach schon bekannten Schwachstellen suchen. Darunter würde beispielsweise eine stream cipher (Stromverschlüsselung) wie bei RC4 fallen.
Die verbleibenden Algorithmen kann man dann mit anderen Methoden wie der differentiellen Kryptoanalyse (Chosen Plaintext), der Seitenkanalattacke (Power oder Timing Attack) oder der linearen Kryptoanalyse untersuchen und ihre Schwachstellen bewerten.
Sollten dann immer noch Algorithmen vorhanden sein, kann man sie noch auf theoretische Schwachstellen testen. Darunter fallen z.B. überbestimmte Gleichungssysteme wie bei Rijndael.

Im Endeffekt dürfte es auf eine Abwägung zwischen Geschwindigkeit und Sicherheit hinauslaufen. Insofern wäre ein solcher Wettbewerb sicherlich ganz nett anzuschauen und würde bestimmt einiges an lehrreichem Stoff liefern.

Entwickler-Ecke.de based on phpBB
Copyright 2002 - 2011 by Tino Teuber, Copyright 2011 - 2025 by Christian Stelzmann Alle Rechte vorbehalten.
Alle Beiträge stammen von dritten Personen und dürfen geltendes Recht nicht verletzen.
Entwickler-Ecke und die zugehörigen Webseiten distanzieren sich ausdrücklich von Fremdinhalten jeglicher Art!