Announcement

Collapse
No announcement yet.

Eigener Algorithmus - taugt er was?

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Eigener Algorithmus - taugt er was?

    Hallo Allerseits.

    Ich bin noch ziemlich neu hier im EF.
    Kurze Vorstellung meinerseits:

    Ich heiß Thomas, komm aus Freital bei Dresden, und bin begeisterter Hobby-Programmierer unter PASCAL.

    Naja, und weil ich mich sehr für Sicherheit interessiere hab ich mir mal den Spaß gemacht, und ein Programm
    zum Verschlüsseln von Dateien geschrieben.

    Ihr ahnt es schon, ich bin interessiert an eurer Meinung, ob der Algorithmus sicher erscheint.
    Ich werde ihn hier komplett beschreiben und eine damit verschlüsselte Datei anhängen.
    Wer möchte und Lust und Zeit hat ist gerne eingeladen, zu versuchen, sie zu entschlüsseln.

    Hier also die Beschreibung:

    Der User gibt einen (numerischen!) Chiffrierschlüssel ein, der jedoch als String gespeichert wird.
    Von diesem Schlüssel gelten nur die ersten 11 Zeichen!
    Zuerst wird das 11te Zeichen überprüft. Davon, welches es ist (0-9) entscheidet sich dann, wie die anderen 10 Zeichen aufgeteilt werden.
    Dabei wird aus den 10 verbleibenden Zeichen immer ein Zahlen-Triplett gebildet.
    Ein Beispiel zur Erläuterung:

    Es sei angenommen, der User gibt - als Telefonnummer wunderbar tarnbar - die Zahl 03514760346 ein.
    Das letzte Zeichen ist hier die 6.

    Für die 6 als Modus-Zeichen ist festgelegt (Triplett-Struktur): 4-3-3
    Daraus ergibt sich eine aufteilung der Zeichenkette zu: 0351 - 476 - 034 - 6
    Die 6 ist und bleibt die Modus-Ziffer und findet beim Schlüssel selbst keine Verwendung.
    Aus den anderen 3 Werten werden nun die drei Schlüsselwerte 351 - 476 - 34 gebildet (Umwandlung String zu Int).

    Mit diesen drei Werten beginnt nun die eigentliche Verschlüsselung.
    Das erste (351) sei X, das zweite (476) sei Y, und das dritte (34) sei Z.

    Nun erfolgt die Verschlüsselung wie folgt.

    Die Datei wird geöffnet, es wird ein einzelnes Byte eingelesen.
    Auf dieses Byte wird X addiert.
    Dieses manipulierte Byte wird danach in eine Temporär-Datei geschrieben.

    Nun ändert sich aber der Schlüssel auch noch! Nämlich wird alle Y Zeichen der Schlüssel durch eine Addition von Z erhöht.

    Die erste 476 Byte im Besipiel würde also um 351 erhöht, die nächsten 476 bereits um 351 + 34 = 385.

    Diese Prozedur erfolgt bis ans Dateiende der Originaldatei.

    Aber damit nicht genug.
    Beide Dateien werden erneut geöffnet, jetzt geht das ganze Spiel mit den selben Werten noch einmal los, allerdings wird jetzt aus der temporären
    zurück in die originale datei ein zweites Mal verschlüsselt!
    Demnach läuft die ganze Prozedur 2 Mal ab...

    Zu guter Letzt wird noch die temporäre Datei gelöscht.
    Es existiert also nach erfolgreicher Verschlüsselung kein unverschlüsseltes Original mehr!

    So... was meint ihr? Ist das sicher???
    Wenn ihr meint: Das geht auszuhebeln! dann versucht euch mal an der angehängten Datei. Zur Einfachheit mal "nur" eine *.txt
    Schreibt bei erfolgreicher Entschlüsselung auch den Schlüssel dazu, den ihr gefunden habt.
    Ich machs euch bissl einfacher. Er hat exakt 11 Stellen und ist NICHT die Nummer aus dem Beispiel oben.
    Und nu: Viel Spaß

    Greetz, Chudan
    Attached Files
    Zuletzt editiert von chudan; 04.06.2008, 19:22.
    Die drei natürlichen Feinde des Programmierers?
    Sonne... Frischluft... Und das elende Gebrüll der Vögel!
    =======================================
    A programer is just a toll wich converts coffein into a code.

  • #2
    Auch hallo,

    so aus dem Handgelenk ist der Algorithmus vielleicht nicht zu knacken.
    ABER: es gibt Regelmässigkeiten (Schlüssel mit 'nur' 11 Stellen, max. Zahlengrösse, nur Addition von Zahlen (ohne Modulorechnung ?)), die denselben angreifbar machen. So gesehen wird er wohl irgendwann geknackt werden können...
    MfG
    Cheat-Sheets for Developers / Programming Quotes

    Comment


    • #3
      Naja, ich sag mal, knackbar is ja irgendwie jeder Algo. Die Frage nach dem Aufwand und der benötigten Zeit steht aber totzdem. Und grade durch den sich in unbekannter häufigkeit wechselnden schlüssel halt ich den aufwand für arg hoch. oder?
      Die drei natürlichen Feinde des Programmierers?
      Sonne... Frischluft... Und das elende Gebrüll der Vögel!
      =======================================
      A programer is just a toll wich converts coffein into a code.

      Comment


      • #4
        So... was meint ihr? Ist das sicher???
        Sicherlich nicht, da du ja nun den Algo hier geschildert hast.

        Dein angeregter Versuch ist somit sicherlich sinnlos.

        Des Weiteren nützt es überhaupt nichts, etwas zu verschlüsseln. Wenn man damit anfangen will - programmtechnisch- dann muss man das auch entschlüsseln. Und da beginnt das Problem aller math. Verfahren: Der Algo ist im Programm und lässt sich durch disassemblieren ermitteln. Alles nur eine Frage es Aufwandes. Und somit ist der Aufruf zu deinem Versuch wie gesagt "sinnlos". Ein Anwender hat nichts von einer verschlüsselten Datei.

        http://www.ntecs.de/old-hp/s-direktn.../de/index.html
        Christian

        Comment


        • #5
          Des Weiteren:

          Was schreibst du in die Zieldatei? Die umgerechneten Werte als String?Binär?

          Ein Byte kann 256 Werte annehmen. Schreibst du wieder ein Byte?
          Christian

          Comment


          • #6
            selbstverständlich wieder ein byte.
            und was bitte bringt dir der aufwand, das progg zu disassemblieren, bzw was kannst du dir von dem algorithmus kaufen, wenn du nicht weißt, mit welcher zahl die datei verschlüsselt wurde???
            da gibt es immerhin nicht zu wenige möglichkeiten.^^
            außerdem ist es gängige praxis, die algorithmen von verschlüsselungen offen zu legen, zwecks des allgemeinen interesses, und das einzige geheimnis den schlüssel bleiben zu lassen^^
            schau mal bei google, wie viele verschlüsselungs algo´s offen liegen. ja und? deswegen zählen viele davon dennoch zu den sichersten überhaupt. weil ohne schlüssel kannst du mit dem algo nichts anfangen^^
            Die drei natürlichen Feinde des Programmierers?
            Sonne... Frischluft... Und das elende Gebrüll der Vögel!
            =======================================
            A programer is just a toll wich converts coffein into a code.

            Comment


            • #7
              und was bitte bringt dir der aufwand, das progg zu disassemblieren, bzw was kannst du dir von dem algorithmus kaufen, wenn du nicht weißt, mit welcher zahl die datei verschlüsselt wurde???
              Offenbar ist dir nicht geläufig wie Schlüssel gebildet werden. Dein Alo lässt sich zu rechnen ermitteln....

              Aber es gibt genug Links dazu....
              Christian

              Comment


              • #8
                ich weiß aber zumindest, wie meine schlüssel entstehen. und weiß auch, dass es da mehr als verdammt viele zahlen gibt.
                schau mal...
                du kannst alles von 1 bis 11 stellen nehmen. zählt alles anders.
                das sind schonmal 10^1 + 10^2 + ... + 10^10 + 10^11 möglichkeiten, welche zahl dort stehen kann. allein die alle durchzugehen dauern ne weile.
                und dann kommt noch dazu, dass ein außenstehender keinen plan von der aufteilung der 10 anderen ziffern hat. bei welcher 11ten ziffer der rest wie aufgeteilt wird und so. erst wenn er das beides raushat... wenn er die exakte zahl kennt, wie viele stellen und was für ziffern diese hatte, und wenn er weiß, wie diese zahl dann auf die drei schlüssel verteilt wird, dann hat er eine kleine chance, rauszukriegen, was da drin steht... und dann geht das auch noch nicht von hand, sondern benötigt wenigstens ein progg, was die rechenoperationen durchführt...
                ich hab zum spaß mal eine *.doc angehängt (gezippt, weil war zu groß). ich glaube fast, die *.txt sieht euch zu simpel aus...
                Attached Files
                Die drei natürlichen Feinde des Programmierers?
                Sonne... Frischluft... Und das elende Gebrüll der Vögel!
                =======================================
                A programer is just a toll wich converts coffein into a code.

                Comment


                • #9
                  Mir stellt sich die Frage, wass der Sinn von der Verschlüsselung ist. Es gibt einen Schlüssel für Ver/Entschlüsselung. Somit wird der ganze Zauber schnell problematisch, wenn der Verschlüsselungscode in die Hände des Angreifers fällt. Somit kann er nach Regelmäßigkeiten suchen und die wird es geben. Warum nicht einen getesteten Algorythmus nehmen, dessen Sicherheit bestätigt ist bzw. dessen Grenzen man kennt?
                  Schöne Grüße, Mario

                  Comment


                  • #10
                    Hallo,

                    vorweg möchte ich betonen das ich kein Krypto-Experte bin. Also bitte nicht steinigen wenn ich Mist erzähle...
                    Originally posted by chudan View Post
                    ...
                    Der User gibt einen (numerischen!) Chiffrierschlüssel ein, der jedoch als String gespeichert wird.
                    Von diesem Schlüssel gelten nur die ersten 11 Zeichen!
                    Zuerst wird das 11te Zeichen überprüft. Davon, welches es ist (0-9) entscheidet sich dann, wie die anderen 10 Zeichen aufgeteilt werden.
                    Dabei wird aus den 10 verbleibenden Zeichen immer ein Zahlen-Triplett gebildet.
                    Also nach meinem Verständnis erhöst du damit nicht die Sicherheit, sondern verringerst sie. Weil: Der Schlüssel um ein Zeichen gekürzt wird und der Schlüssel durch "mischen" nicht sicherer wird. Egal wie oft und beliebig der 10-Zeichenschlüssel anders angeordnet wird, er bleibt eine aus n Möglichkeiten.

                    Originally posted by chudan View Post
                    ...
                    Die Datei wird geöffnet, es wird ein einzelnes Byte eingelesen.
                    Auf dieses Byte wird X addiert.
                    Dieses manipulierte Byte wird danach in eine Temporär-Datei geschrieben.

                    Nun ändert sich aber der Schlüssel auch noch! Nämlich wird alle Y Zeichen der Schlüssel durch eine Addition von Z erhöht.
                    Eine einfache byteweise Addition eines beliebigen Wertes ist aus meiner Sicht nicht sicher. Die verschlüsselte Datei hat die gleiche Größe wie die Originaldatei. Die typografische Verteilung der Zeichen bleibt erhalten. Bei einer verschlüsselten Textdatei sollte es einem Angreifer relativ schnell möglich sein, die Größe der Blöcke (dort wo der Byte-Summand erhöht wird) zu erkennen. Um bei deinem Bsp. zu bleiben:
                    "normale" Zeichen bewegen sich im ASCII-Bereich 32-150. Bei einer Addition mit 351 ergibt das 383-551. Da du byteweise arbeitest muß es also wieder ein Byte werden sprich Subtraktion mit 256. Erster Block liegt also bei 127-295. Der zweite bei 161-279. Diesen Sprung kann man sicherlich erkennen - in etwa reicht bereits.
                    Innerhalb der erkannten Blöcke kann man jetzt nach "verräterischen" Zeichen suchen. Wiederkehrende Zeichen aller 3-10 Zeichen deuten z.B. auf ein Leerzeichen hin. Hab ich das erstmal erkannt, hab ich den gesamten ersten Block entschlüsselt und kenne damit X und gleichzeitig ziemlich genau Y. Mit dem zweiten Block kann ich analog verfahren und kenne danach auch Z.

                    Originally posted by chudan View Post
                    ...
                    Aber damit nicht genug.
                    Beide Dateien werden erneut geöffnet, jetzt geht das ganze Spiel mit den selben Werten noch einmal los, allerdings wird jetzt aus der temporären
                    zurück in die originale datei ein zweites Mal verschlüsselt!
                    Demnach läuft die ganze Prozedur 2 Mal ab...
                    Das könntest du X-mal wiederholen, das Verfahren wird dadurch nicht sicherer. Der Angreifer muß nicht einmal wissen, wie oft du das gemacht hast. Nach o.g. Vorgehen braucht er eh nur einen Durchlauf.
                    Selbst anerkannt sichere Verschlüsellungsverfahren werden nicht noch sicherer indem man sie auf eine bereits verschlüsselte Datei anwendet!

                    Originally posted by chudan View Post
                    ...So... was meint ihr? Ist das sicher???
                    Ich würde sagen: Nein! Ein halbwegs begabter Hacker braucht wahrscheinlich nur wenige Stunden (wenn überhaupt), um einen damit verschlüsselten Text lesbar zu machen.

                    Gruß Falk
                    Wenn du denkst du hast alle Bugs gefunden, dann ist das ein Bug in deiner Denksoftware.

                    Quellcode ohne ein Mindestmaß an Formatierung sehe ich mir nicht an! Ich leiste keinen Privatsupport per Mail oder PN!

                    Comment


                    • #11
                      Hallo Thomas,

                      also wie gesagt, ich bin kein Kryptologe und auch kein Hacker ...

                      Dein Text fängt mit "Wenn Ihr das hier rausbekommt" an. Den Rest spar ich mir, es ist reine Fleißarbeit.

                      Wer es probieren will: X=92, Y=8 und Z=12.

                      Den ursprünglichen Schlüssel kann ich dir nicht sagen, aber wie du siehst ist der auch nicht wichtig!

                      Gruß Falk

                      P.S.: Kleines Script zu Hilfe genommen: "Wenn ihr das hier rausbekommt, dann habt ihr es echt verdammt nochmal gut drauf!!! Hut ab... Greetz, Chudan"
                      Zuletzt editiert von Falk Prüfer; 05.06.2008, 13:41.
                      Wenn du denkst du hast alle Bugs gefunden, dann ist das ein Bug in deiner Denksoftware.

                      Quellcode ohne ein Mindestmaß an Formatierung sehe ich mir nicht an! Ich leiste keinen Privatsupport per Mail oder PN!

                      Comment


                      • #12
                        Originally posted by Falk Prüfer View Post
                        Innerhalb der erkannten Blöcke kann man jetzt nach "verräterischen" Zeichen suchen. Wiederkehrende Zeichen aller 3-10 Zeichen deuten z.B. auf ein Leerzeichen hin.
                        Ich glaub ich hab es noch nicht oft genug wiederholt...
                        der schlüssel ändert sich!!! ständig!
                        das heißt, jedes leerzeichen kann völlig anders aussehen^^

                        Und ja, Hut ab, dass du die *.txt geknackt hast. und jetzt: versuch dich an der *.doc.
                        Oder meinst du echt, man würde echt wichtige dokumente, die der verschlüsselung dürftig sind, als *.txt schicken? wohl kaum^^
                        Die drei natürlichen Feinde des Programmierers?
                        Sonne... Frischluft... Und das elende Gebrüll der Vögel!
                        =======================================
                        A programer is just a toll wich converts coffein into a code.

                        Comment


                        • #13
                          Wozu soll Falk dass machen? Die txt-Datei war doch offensichtlich in kurzer Zeit entschlüsselbar. Nur weil es bei einer doc länger dauern wird, ist es nicht sicherer. Ausserdem plagt die wenigsten hier Langeweile...

                          Die Frage war, ob der Algo. sicher ist. Er ist es offensichtlich nicht. Das kannst Du einsehen, oder auch lassen.
                          Schöne Grüße, Mario

                          Comment


                          • #14
                            Nun ja... aber eben nur weil es eine *.txt war, hatte er etwas, was er auf regelmäßigkeiten und andere typische strukturen untersuchen konnte. das geht bei höheren dateiformaten, die irgendwelche formatierungen auch noch abspeichern meiner ansicht nach nicht...
                            naja wie auch immer... ich werd mir mal was überlegen...
                            Die drei natürlichen Feinde des Programmierers?
                            Sonne... Frischluft... Und das elende Gebrüll der Vögel!
                            =======================================
                            A programer is just a toll wich converts coffein into a code.

                            Comment


                            • #15
                              ich werd mir mal was überlegen...
                              Da man sich dabei mathematischer Hilfsmittel bedient, ein paar Schlagworte:
                              -Multiplikation
                              -Modulo Rechnung
                              -Falltürfunktion
                              -http://www.cacr.math.uwaterloo.ca/hac/ ("Handbook of Applied Cryptography")
                              MfG
                              Cheat-Sheets for Developers / Programming Quotes

                              Comment

                              Working...
                              X