Kalle_B: Wettangebot: Verschlüsselung knacken

056

Wettangebot: Verschlüsselung knacken

  1. 0
    1. 0
  2. 3
    1. 0
  3. 0
    1. 0
      1. 0
        1. 0
          1. 0
        2. 0
          1. 0
    2. 0

      Was für ein Unsinn

  4. 0
  5. 0
  6. 0
  7. 6
  8. 2
  9. 0
  10. 0
    1. 7
      1. 0
        1. 6
          1. 12
            1. 0
            2. 30

              Wettangebot: Verschlüsselung geknackt - mit Erklärung

              1. 0
              2. 0
              3. 0
              4. 0
              5. 0
              6. 0
              7. 0
              8. 0
              9. 0

                MD5-basierte Verschlüsselung

                1. 2
                  1. 0
                    1. 1
                      1. 0
                      2. 1

                        Blowfish statt AES

                        1. 0
                  2. 2
                2. 0
                  1. 0
                    1. 0
                      1. 0
              10. 0
              11. 2
              12. 0
              13. 0
  11. 0

    Danke an Henryk

    1. 0
    2. 0
      1. 0
        1. 0
    3. 0

Hallöle,

gestern gab es einen sportlichen Disput, ob meine wenigen PHP- Zeilen zur Verschlüsselung einer zu übertragenden Datei sicher genug sind.
?t=169920&m=1110084

Hier ist eine verschlüsselte Datei nach meinem Muster:
aWRZYWpoZiBrMDsqJydvaVVPIE9IYiU6L1O1tcggtHkgVVnkFoz9SPpPP84eapS/pzTsc...(abgebrochen)

(hat die Forensoftware abgelehnt "Sie sind wohl etwas geschwätzig?")
also angegebene URL anschauen

Wer daraus bis zum 24. April 2008 24:00 Uhr als Erster wieder eine Datei machen kann und HIER IM FORUM seinen Weg beschreibt und sich den Zeitstempel holt, bekommt von mir 100 EUR in bar (Briefumschlag).

MfG Kalle   

  1. hallo Kalle,

    (...) bekommt von mir 100 EUR in bar.

    Überweise die 100 Euronen doch bitte gleich als Spende an SELFHTML.

    Grüße aus Berlin

    Christoph S.

    ss:| zu:) ls:& fo:) va:) sh:| rl:|

    -- Visitenkarte
    1. hallo Christoph,

      Überweise die 100 Euronen doch bitte gleich als Spende an SELFHTML.

      Wenn SELFHTML den Code knackt, kein Problem.

      Möchte mal wissen, ob hinter den Leuten mit der dicken Schreibe (große Schnauze kann ich ja nicht sagen) auch der entsprechende Grips steckt.

      Nix für ungut und gute Nacht.

      MfG Kalle

  2. Hi,

    Wer daraus bis zum 24. April 2008 24:00 Uhr als Erster wieder eine Datei machen kann

    Kann ich!

    und HIER IM FORUM seinen Weg beschreibt

    Ganz einfach: Copy & Paste, Einfuegen in neue leeres Dokument in meinem Editor, Abspeichern, fertig.

    (Damit habe ich "daraus wieder eine Datei gemacht", und von mehr war in deiner Anforderung nicht die Rede - von *sinnvollem* Inhalt schon gar nicht ...)

    und sich den Zeitstempel holt, bekommt von mir 100 EUR in bar (Briefumschlag).

    Ich bin auch dafuer, dass du die 100 EUR als Spende an SELFHTML e.V. ueberweist.
    Nachweis darueber haette ich aber gern, Danke.

    MfG ChrisB

    1. Hi,

      Ganz einfach: Copy & Paste, Einfuegen in neue leeres Dokument in meinem Editor, Abspeichern, fertig.

      Viel zu kompliziert!

      Rechtsklick auf den Link, "Save Link as", Dateinamen angeben, fertig.

      cu,
      Andreas

      Fachfragen unaufgefordert per E-Mail halte ich für unverschämt und werde entsprechende E-Mails nicht beantworten. Für Fachfragen ist das Forum da.

      -- Warum nennt sich Andreas hier MudGuard?
      O o ostern ...
  3. Hier ist eine verschlüsselte Datei nach meinem Muster:
    aWRZYWpoZiBrMDsqJydvaVVPIE9IYiU6L1O1tcggtHkgVVnkFoz9SPpPP84eapS/pzTsc...(abgebrochen)

    ein symetrischer algorithmus ist niemals sicher - sobald bekannt ist, wie er funktioniert ist er problemlos zurückzurechnen.

    ein asymetrisches verfahren kan sicher sein, allerdings lässt sich die sicherheit nur dann prüfen, wenn der algorithmus zugänglich ist.

    Was du betreibst, ist security through obscurity - und das ist potentiell gefährlich

    security through obscurity -> rot13 -> frphevgl guebhtu bofphevgl

    schon sieht das ganze "verschlüsselt" aus, ein mensch der den mechanismus hinter rot13 nicht kennt, wird sicher eine zeit benötigen, das ganze zu knacken - sobald aber bekannt wird, wie das ganze funktioniert ist das ganze wertlos und nur eine frage der zeit

    1. Hier ist eine verschlüsselte Datei nach meinem Muster:
      aWRZYWpoZiBrMDsqJydvaVVPIE9IYiU6L1O1tcggtHkgVVnkFoz9SPpPP84eapS/pzTsc...(abgebrochen)

      ein symetrischer algorithmus ist niemals sicher - sobald bekannt ist, wie er funktioniert ist er problemlos zurückzurechnen.

      Als ich mir diesen und die beiden damit verbundenen Threads durchgelesen habe, dachte ich ja noch bei mir, dass, wenn eine Unsicherheit bereits von schlauen Leuten nachgewiesen wurde, nicht jeder, der (wie Hendryk und Vinzenz) darauf hinweist, dies auch selbst nochmal demonstrieren muss.

      Aber offen gesagt: Kalles Funktion ist bekannt. Entweder, du (oder Vinzenz oder Hendryk) rechnest das jetzt mal "problemlos zurück", für dein "problemlos" erwarte ich ein entschlüsseltes Ergebnis innerhalb der nächsten Stunden, oder du hältst dich in Zukunft mit solchen vorlauten Äußerungen zurück.

      Hendryk kann man noch zu Gute halten, dass er darauf hingewiesen hat, dass eine XOR-basierte Verschlüsselung nicht zu entschlüsseln ist, sofern der Schlüssel so lang wie der Klartext ist und mit einem ordentlichen Zufallsgenerator erzeugt und nicht mehrmals verwendet wurde. Aber ansonsten wird hier von "problemlos zurückrechenbar" bis zu "ekelhaft unsicher" so getan, als handelte es sich um base64. Falls Kalle einen Schlüssel verwendet hat, der auch nur halb so lang ist wie der Klartext, schaut ihr allesamt vermutlich problemlos dumm aus der Wäsche.

      1. Hendryk kann man noch zu Gute halten, dass er darauf hingewiesen hat, dass eine XOR-basierte Verschlüsselung nicht zu entschlüsseln ist, sofern der Schlüssel so lang wie der Klartext ist und mit einem ordentlichen Zufallsgenerator erzeugt und nicht mehrmals verwendet wurde. Aber ansonsten wird hier von "problemlos zurückrechenbar" bis zu "ekelhaft unsicher" so getan, als handelte es sich um base64. Falls Kalle einen Schlüssel verwendet hat, der auch nur halb so lang ist wie der Klartext, schaut ihr allesamt vermutlich problemlos dumm aus der Wäsche.

        den schlüssel einer symetrischen verschlüsselung geheimzhalten ist nicht nicht sicher - das system muss auch dann noch sicher sein, wenn der schlüssel bekannt ist

        die sicherheit eines verschlüsselungsalgorithmus lässt sich nur dann testen, wenn alle faktoren bekannt sind, die auf dem verschlüsselnden oder auf dem entschlüsselnden system vorliegen

        bei asymetrischen verfahren kann eine der beiden stellen kompromitiert sein und es ist theoretisch kein problem

        bei symetrischen verfahren ist es ein problem

        1. Hallo suit,

          den schlüssel einer symetrischen verschlüsselung geheimzhalten ist nicht nicht sicher - das system muss auch dann noch sicher sein, wenn der schlüssel bekannt ist

          nein, das ist Unsinn.

          bei asymetrischen verfahren kann eine der beiden stellen kompromitiert sein und es ist theoretisch kein problem

          ein typisches Vorgehen für eine sichere und gleichzeitig ressourcenschonende verschlüsselte Datenübertragung ist das Übertragen des Schlüssels (ein One-time-pad, d.h. ein einmalig zu verwendender Schlüssel) über eine asymmetrische Verschlüsselung und die anschließende Übertragung der Daten mit einem symmetrischen Verfahren.

          Eine ausgezeichnete Quelle, um sich grundlegend über Kryptographie zu informieren, ist CrypTool, siehe auch Wikipedia, CrypTool, mit der dazugehörigen Dokumentation. Sehr empfehlenswert!

          Freundliche Grüße

          Vinzenz, den das "Wettangebot" von Kalle nicht betrifft.

          1. Moin,

            ein typisches Vorgehen für eine sichere und gleichzeitig ressourcenschonende verschlüsselte Datenübertragung ist das Übertragen des Schlüssels (ein One-time-pad, d.h. ein einmalig zu verwendender Schlüssel)

            Nur damit keine Verwirrungen aufkommt: "One-Time Pad" != "einmalig zu verwendender Schlüssel". Das was du meinst ist ein Ephemeralschlüssel. Um als ein One-Time Pad durchzugehen muss der Schlüssel nicht nur nur einmal verwendet werden, sondern auch in einer sicheren Art die dafür sorgt dass jeder beliebige Schlüssel und jeder beliebige Klartext bei gegebenem Ciphertext möglich sind. Das ist am einfachsten bei XOR gegeben (wobei jede andere polyalphabetische Substitution auch gehen dürfte).

            Die übliche Vorgehensweise, einen Ephemeralschlüssel asymmetrisch verschlüsselt zu übertragen zeichnet sich dadurch aus, dass der Schlüssel eben *nicht* die gleiche Länge wie der Klartext hat, und *nicht* direkt in XOR (o.ä.) eingeht sondern mit einem symmetrischen Verfahren wie AES verwendet wird, was unter anderem ein Key Setup nach sich führt welches unter Umständen dafür sorgen könnte dass selbst wenn man nur eine 256 bit lange Nachricht mit einem 256 bit langen Schlüssel verschlüsselt nicht alle Schlüsselbits eingehen.

            --
            Henryk Plötz
            Grüße aus Berlin
            ~~~~~~~~ Un-CDs, nein danke! http://www.heise.de/ct/cd-register/ ~~~~~~~~
            ~~ Help Microsoft fight software piracy: Give Linux to a friend today! ~~

        2. bei asymetrischen verfahren kann eine der beiden stellen kompromitiert sein und es ist theoretisch kein problem

          bei symetrischen verfahren ist es ein problem

          was sagt uns das? Dass symetrische Verfahren schlechter sind?
          Bei asymetrischen mußt Du Deinen private key auch verheimlichen. Bei symetrischen darf nur der Partner auch den Schlüssel nicht weitergeben.
          Das hat aber alles nichts mit der Leistungsfähigkeit des Systems zu tun.

          Ansonsten: Fang an! Es winken Dir 100 Euro.

          1. Das hat aber alles nichts mit der Leistungsfähigkeit des Systems zu tun.

            natürlich hat das nichts mit der leistungsfähigkeit zu tun - nur führt geheimhaltung nur selten zum erfolg

    2. Hallo,
      tut mir leid, aber du redest totalen Müll.

      ein symetrischer algorithmus ist niemals sicher - sobald bekannt ist, wie er funktioniert ist er problemlos zurückzurechnen.

      Kompletter Unfug! AES, Twofish etc. sind symmetrische Algorithmen und ich wette mit dir, dass du diese nicht problemlos zurückrechnen kannst.

      Genauso das One-Time-Pad, dieses symmetrische Verfahren ist nachweisbar _absolut_ (100%!) sicher, knacken also unmöglich.

      Was du betreibst, ist security through obscurity - und das ist potentiell gefährlich

      Das stimmt.

      das system muss auch dann noch sicher sein, wenn der schlüssel bekannt ist

      Selten so einen Unfug gelesen.

      Da zitiere ich doch mal das Kerckoffs' Prinzip:

      „Die Sicherheit eines Kryptosystems darf nicht von der Geheimhaltung des Algorithmus abhängen. Die Sicherheit gründet sich nur auf die Geheimhaltung des Schlüssels.“

      bei asymetrischen verfahren kann eine der beiden stellen kompromitiert sein und es ist theoretisch kein problem

      Unsinn! Wenn beim z.B. Homebanking der Client kompromittiert ist, kann der Angreifer jede Nachricht lesen, egal ob nun symmetrisches oder asymmetrisches Verfahren benutzt wird.

      Ich glaub ich muss Dieter Nuhr mal zitieren:
      Klick

  4. echo $begrüßung;

    Wer daraus bis zum 24. April 2008 24:00 Uhr als Erster wieder eine Datei machen kann und HIER IM FORUM seinen Weg beschreibt und sich den Zeitstempel holt,

    Wie man eine Datei draus macht, ist ja schon beschrieben worden. Da nicht bekannt ist, wie der Inhalt aussieht, poste ich hier einfach mal die 256^47834 Möglichkeiten. Eine davon wird schon stimmen ... Du könntest das Forum aber auch vor diesem Müll bewahren und wenigstens eine Prüfsumme angeben, damit man weiß, dass es die richtige Lösung ist. Alternativ könntest du auch was anderes zum Inhalt verlauten lassen, denn jemand der an etwas Interesse hat, weiß im Allgmeinen, was das Ziel ist. (Nein, die 100 Euro sind es nicht, die kann ich mir effizienter verdienen.)

    echo "$verabschiedung $name";

  5. Hallo Kalle,

    die Meinungen der anderen Interessiert mich nicht und ich verstehe auch nicht warum sich hier soviele aufregen. Ich finde deine Idee sehr gut und es hat ja auch eine Welle geschlagen - ob es nun sinnvoll ist oder nicht -.

    Ich hingegen habe mich durch deine Aufgabe inspirieren lassen und habe Interesse am Thema "Cryptologie" gefunden und werde mich -soweit es meine Zeit zulässt- näher damit beschäftigen.

    Danke Kalle :)

    Rapsody

  6. http://remso.de/wette.php

    Wer daraus bis zum 24. April 2008 24:00 Uhr als Erster wieder eine Datei machen kann und HIER IM FORUM seinen Weg beschreibt und sich den Zeitstempel holt, bekommt von mir 100 EUR in bar (Briefumschlag).

    Es handelt sich um die ersten 64 kB der Forumshauptdatei. Meine Adresse findest du im Impressum.

    Roland

    --
    Top Fives // »Schlechte Werbung. Gibt es nicht.« // mitmachen

  7. Sup!

    Solange Du genau einen Ciphertext anbietest, ist Deine Verschlüsselung wohl "sicher", da sie quasi auf ein "1-time-pad" rausläuft.
    Sobald aber jemand mehrere Nachrichten abfangen kann oder auf den Typ der Datei schliessen, kann er den Schlüssel stückweise rekonstruieren.

    Z.B. wird eine HTML-Datei immer mit einem Doctype beginnen oder eine JPEG-Datei mit einem JPEG-Header.

    Du könntest die Sicherheit Deiner Methode einwenig erhöhen, indem Du z.B. jede Nachricht mit einem zufälligen, s.g. Initialisierungsvektor beginnen lassen würdest, der dann nach dem Empfang wieder weggeworfen wird. Dann würde der gleiche Geheimtext in viele viele verschiedene verschlüsselte Texte abgebildet werden.

    Bei Deiner aktuellen Verschlüsselung wird z.B. "Bio" (0x42 0x69 0x6f)immer gleich verschlüsselt.

    Ist der Schlüssel z.B. "abc" (0x61, 0x62, 0x63), kommt durch XOR 0x23, 0x0b, 0x0c raus.

    Verschlüsselst Du "Pia" (0x50, 0x69, 0x61), kommt 0x31, 0x0b, 0x02 raus.

    Jetzt weiss ich zwar den Schlüssel nicht, wenn ich das abfange, weiss aber, dass der zweite Buchstabe beider Nachrichten gleich ist, weil der gleiche Code 0x0b rauskommt.
    Ich kenne auch die Differenz zwischen den beiden ersten Buchstaben 0x50 xor 0x42 = 0x12, die gleich 0x31 xor 0x23 = 0x12 ist, denn 0x42 xor 0x61 xor 0x50 xor 0x61 = 0x42 xor 0x50 xor (0x61 xor 0x61) = 0x42 xor 0x50.

    Dadurch kann ich auf den Inhalt der verschlüsselten Dateien schliessen. Ist z.B. beim xor beider verschlüsselter Texte das MostSignificantBit selten gesetzt, sind die verschlüsselten Dateien ggf. beide (ASCII) Text. Sind die Unterschiede zufallsverteilt, ist eine Datei vielleicht komprimiert. Auf diese Weise und mit noch viel abgefahreneren Tricks haben Kryptologen Deine Verschlüsselung nach dem Abfangen weniger Nachrichten geknackt, auch wenn niemand aus dem Forum sie mittels eines Geheimtextes knacken kann.

    Gruesse,

    Bio

    -- Never give up, never surrender!!!
  8. Moin!

    Wer daraus bis zum 24. April 2008 24:00 Uhr als Erster wieder eine Datei machen kann und HIER IM FORUM seinen Weg beschreibt und sich den Zeitstempel holt, bekommt von mir 100 EUR in bar (Briefumschlag).

    Die Frage ist doch: Was ist damit bewiesen?

    Wenn jemand deine Nachricht knackt (die Frage ist, wie man das feststellen kann), weißt du, dass dein Mechanismus unsicher ist. Das wußtest du schon vorher - zumindest wurde es dir gesagt.

    Wenn niemand die Nachricht knackt, weißt du aber nicht, dass dein Mechanismus sicher ist - es könnte sich ja einfach nur niemand damit beschäftigt haben.

    Ansonsten verweise ich auch gern auf Bios Begründung: Eine einmalige Verschlüsselung ist relativ gesehen deutlich "sicherer", als eine immer wiederkehrende, gleichartige Kommunikation. Die diversen Unsicherheiten z.B. in der Verschlüsselung von älteren MS-Office-Dokumenten (Passwortschutz) ist nur deshalb aufgedeckt und gebrochen worden, weil mehr als ein Dokument analysiert wurden, und typische Dateistrukturen entdeckt wurden, die in der codierten Datei wiedererkannt wurden.

    Insgesamt ist die Kryptoanalyse ein interessantes, aber auch aufwendiges Feld. Ich glaube kaum, dass du einen Experten für 100 Euro hinterm Ofen hervorlocken kannst.

     - Sven Rautenberg

    -- "Love your nation - respect the others."
  9. Moin,

    Hier ist eine verschlüsselte Datei nach meinem Muster:
    aWRZYWpoZiBrMDsqJydvaVVPIE9IYiU6L1O1tcggtHkgVVnkFoz9SPpPP84eapS/pzTsc...(abgebrochen)

    Meine Glaskugel sagt mir dass das eine ZIP-Datei ist. Weiterhin: in http://tm3-fuhrpark.de/send_file.php?infile=send_file.php hast du bei

    $schl_kopie = substr( $schl_kopie, 5, strlen($schl_kopie)-5 ).substr( $schl_kopie, 0, 5 );

    eine Referenz auf die magische Zahl 5 verwendet. Hast du diese magische Zahl auch bei deiner Wettdatei verwendet oder hast du da eine andere Zahl verwendet? Wenn ja, welche.

    Im übrigen ist

    if (!strpos( 'x'.$input_file, 'send_file' ))

    eine *echt* blöde Idee um die Gültigkeit der Eingabe zu überprüfen. Und das sollte man schon gar nicht *nach* dem Öffnen der Datei tun.

    --
    Henryk Plötz
    Grüße aus Berlin
    ~~~~~~~~ Un-CDs, nein danke! http://www.heise.de/ct/cd-register/ ~~~~~~~~
    ~~ Help Microsoft fight software piracy: Give Linux to a friend today! ~~

  10. Hallöle,

    möchte nur mal eben bestätigen, dass ich die Nachrichten hier natürlich mit großem Interesse verfolge.

    Aber einen Kommentar werde ich nicht abgeben. Ihr kennt doch das Spiel, mit Fragen, die nur mit JA oder NEIN beantwortet werden, zum Ziel zu kommen.

    Da waren solche versteckten Fragen: Ist es eine ZIP- Datei? Kommt "Bio" drin vor?

    Mir fällt nur gerade ein, dass am Stichtag diese Diskussion schon im Archiv gelandet sein könnte und nicht mehr beantwortet werden kann. Wer die Lösung hat, macht dann bitte einen neuen Faden auf.

    Und bitte Info an meine Mail- Adresse.

    Ach ja, die Bemerkung, dass ein "Fachmann" nicht für 100 EUR hinterm Ofen vorzulocken ist, scheint mir ein Hinweis auf den doch nicht so trivialen Schwierigkeitsgrad zu sein. Die vorangegangene Diskussionen sah eher so aus, als ob jeder IT- Student mit ein paar Klicks das Ergebnis hat.

    Und für den sind 100 EUR schon was.

    Fröhliches Tüfteln wünscht euch Kalle

    1. Moin,

      Da waren solche versteckten Fragen: Ist es eine ZIP- Datei? Kommt "Bio" drin vor?

      Ja, ist es vermutlich (der Algorithmus leakt Informationen über die Struktur des Klartexts und das was leakt ist konsistent mit ZIP-Dateien, aber zum Beispiel nicht mit JPG-Dateien). Es ist auf jeden Fall eine Binärdatei und keine reine Textdatei.

      Du spielst ausserdem nicht vollständig fair und verwendest nicht direkt den Algorithmus von http://tm3-fuhrpark.de/send_file.php?infile=send_file.php (der übrigens einen Bug in dem Code den du eingebaut hast enthält der in meinem Originalcode nicht drin war). Der dort veröffentlichte Code hinterlässt eine spezifische Signatur in der verschlüsselten Datei und deine Wettdatei passt nicht ganz darauf, sondern auf eine leicht abgeänderte Variante. Meine Vermutung ist, dass du die 5 in dem Code nicht konstant hältst sondern veränderst, bzw. etwas tust was ungefähr äquivalent im Ergebnis ist.

      Kenntnis des richtigen Algorithmus führt in diesem Fall direkt (oder mit nur wenig Handarbeit) zum Schlüssel, da diese Art von Verschlüsselung extrem anfällig für known-plaintext-Angriffe ist, man aber säckeweise bekannten (oder zumindest geratenen) plaintext zur Hand hat. Zumal dein Schlüsselgenerierungsverfahren ("Finger auf Tastatur", aber hey, immerhin hast du Zeichen wie "á" und "ò" drin) extrem schwach ist.

      Übrigens ist quasi kein heute verbreitetes richtiges[tm] Verschlüsselungsverfahren für known-plaintext-Angriffe anfällig. Das dürfte auch für alle Algorithmen im mcrypt-Modul zutreffen.

      --
      Henryk Plötz
      Grüße aus Berlin
      ~~~~~~~~ Un-CDs, nein danke! http://www.heise.de/ct/cd-register/ ~~~~~~~~
      ~~ Help Microsoft fight software piracy: Give Linux to a friend today! ~~

      1. Moin,

        Da waren solche versteckten Fragen: Ist es eine ZIP- Datei? Kommt "Bio" drin vor?

        Ja, ist es vermutlich

        Oder auch nicht... An Offset 0xb8db vom wiederhergestellten Klartext der Datei steht der String "LAME3.96.1" und davor und dahinter sind eine Menge "U".

        (Damit ziehe ich auch meine Bemerkung zu "á" und "ò" zurück. Da war ich davon ausgegangen dass das konstante Zeichen eine binäre 0 ist, wie bei ZIP-Dateien üblich. Aber wenn das konstante Zeichen "U" ist, dann sind das natürlich "´" und "§".)

        --
        Henryk Plötz
        Grüße aus Berlin
        ~~~~~~~~ Un-CDs, nein danke! http://www.heise.de/ct/cd-register/ ~~~~~~~~
        ~~ Help Microsoft fight software piracy: Give Linux to a friend today! ~~

        1. Moin,

          Hier die Ingrid nochmal...

          der Anfang der Datei ist

          ['I', 'D', '3',  # Magic '\x03', '\x00', # Version 2.3.0 '\x00',  # Flags: 0 '\x00', '\x00', '\x00', '\x10', # ID3v2-Headerlänge (ohne header, mit padding) 0x10 = 16, 'T', 'C', 'O', 'N', # TCON-Frame: Content-Type (e.g. Genre)     '\x00', '\x00', '\x00', '\x06', # Länge: 6 (plus 10 byte Frame-Header)     '\x00', '\x00', # Flags: 0     '\x00', # Textkodierung: ISO-8859-1     'B', 'l', 'u', 'e', 's',  # Inhalt: Blues '\xff', '\xfa', # Sync word, mpeg 1, layer 2, keine crc ...]

          der Schlüssel ist

          '  jbjhf k oihioiUI OH IOJ JOP OH UZGTF DZOIFG15+\xa7$%&/()=?J;MJHGTRE xfghjuio67897856358 #+\xb4\xb42^^fghjkghujk ascdvbnm,\xdf0oizu57856'

          (als ASCII mit eingestreuten Escape-Codes für die Sonderzeichen) bzw. "  jbjhf k oihioiUI OH IOJ JOP OH UZGTF DZOIFG15+§$%&/()=?J;MJHGTRE xfghjuio67897856358 #+´´2^^fghjkghujk ascdvbnm,ß0oizu57856" als Text (Zeichencodierung beachten, der Originalschlüssel ist 125 Bytes lang und ISO-8859-1-codiert).

          --
          Henryk Plötz
          Grüße aus Berlin
          ~~~~~~~~ Un-CDs, nein danke! http://www.heise.de/ct/cd-register/ ~~~~~~~~
          ~~ Help Microsoft fight software piracy: Give Linux to a friend today! ~~

          1. Moin,

            Hier die Ingrid nochmal...

            Und wieder. Die vollständig wiederhergestellte Datei ist http://www.ploetzli.ch/forumtst/plaintext.decrypter-knownkey.try.b290ec282ee4fb1d5c09cb08b3b5497b8e099d5f
            sha1sum 9bb6bf454b48b1dce0b383520398a95c3ec7afc2,
            md5sum 4390284927d33dd283252dce139d3ca5.

            Der Entschlüsselungsalgorithmus geht ungefähr so, ausgehend von dem Schlüssel den ich schon veröffentlicht habe:
            + Man teilt die Datei in jeweils 126 Byte große Teile (Schlüssellänge + 1)
            + Für jeden Teil:
            +   Das letzte Byte ist mit \x00 verschlüsselt, also im Klartext, kann also ignoriert werden
            +   Die vorderen 125 Byte jedes Teils sind je byteweise ver-xor-t mit einer rotierten Variante des Schlüssels (key[offset:]+key[:offset]), offset-berechnung siehe unten

            def offset_generator(keylen):   offset=0   diff=119   while True:     yield offset     offset = (keylen+(offset-diff))%keylen     diff = diff-1     if diff < 45: diff = 120

            Detaillierte Beschreibung der Vorgehensweise (mit Grafiken in Farbe und Bunt) folgt noch.

            --
            Henryk Plötz
            Grüße aus Berlin
            ~~~~~~~~ Un-CDs, nein danke! http://www.heise.de/ct/cd-register/ ~~~~~~~~
            ~~ Help Microsoft fight software piracy: Give Linux to a friend today! ~~

            1. Hello Henryk,

              Detaillierte Beschreibung der Vorgehensweise (mit Grafiken in Farbe und Bunt) folgt noch.

              Alle Achtung, wenn ich Hut tragen würde, würde ich den jetzt vor Dir ziehen.

              Wäre wirklich schön, wenn Du den Enschlüsselungsgang an diesem Beispiel mal dokumentieren würdest. Man wiegt sich immer viel zu schnell in Sicherheit.

              Ich hatte mir da auch mal eine tolle "Verschlüsselung" ausgedacht, und wollte die immer schon mal mit jemandem mathematisch überprüfen. Nun ist sie aber leider verschwunden. Ist vielleicht auch besser so ;-))

              Ein harzliches Glückauf

              Tom vom Berg

              --
              Nur selber lernen macht schlau
              http://bergpost.annerschbarrich.de

            2. Moin,

              Also, wir fangen an mit dem "Geheimtext" (aWRZYWpoZiBrMDsqJydvaVVPIE9IYiU6L1O1tcggtHkgVVnkFoz9SPpPP84eapS/pzTsc...) von http://remso.de/wette.php: ciphertext. Relativ offensichtlich ist das BASE64-codiert, also erstmal [code]$ base64 -d < ciphertext > ciphertext.d64[/code] um ciphertext.d64 zu erhalten. Das wird die Datei sein mit der wir ab jetzt arbeiten.

              Wir wissen: Es ist eine einfache Polyalphabetische Substitution. Die übliche erste Vorgehensweise ist Autokorrelation: autocorr.c: [code] henryk@dawn ~/xorwette $ time ./autocorr ciphertext.d64 > ciphertext.autocorr

              real 0m6.487s user 0m6.080s sys 0m0.010s [/code]

              Oder als Graph: http://www.ploetzli.ch/xorwette/autocorr.png

              Wie wir sehen sehen wir nichts. Die Autokorrelation bringt uns in diesem Fall also nichts, nichtmal die Schlüssellänge. Nagut, nächste Standardvorgehensweise für unbekannte Dateien ist ein Hexdump ([code]hexdump -C ciphertext.d64 | less[/code]): http://www.ploetzli.ch/xorwette/hexdump-anfang.png und http://www.ploetzli.ch/xorwette/hexdump-ende.png

              Da sind mehrere ASCII-Zeichen am Dateifang was sehr verdächtig ist und bei einer verschlüsselten Datei nie passieren dürfte. Aber am Dateiende ist's noch viel schlimmer: viel ASCII-Text, der sich auch noch wiederholt (klassisch für polyalphetische Chiffrierungen wenn immer wieder das gleiche Zeichen verschlüsselt wird). Das war die Stelle an der mir klar war dass dieses Verfahren sehr einfach gebrochen werden können müsste. Wenn man sich die Verteilung der Byte-Werte ansieht (und vor allem das most significant bit) sieht man dass die Datei mit etwa 26 Bytes ohne MSBit gesetzt beginnt und mit etwa 600 bis 700 Byte mit nur wenigen MSBit gesetzt endet, dazwischen scheinen die Werte zufällig verteilt zu sein. Eigentlich[tm] sind zufällig aussehende Bytewerte ein Zeichen für ordentliche Verschlüsselung, bzw. andersrum: Wenn die Bytes nicht zufällig verteilt sind ist es nicht ordentlich verschlüsselt. Wir haben schon die nicht-zufällige Verteilung am Anfang und Ende festgestellt, also keine ordentliche Verschlüsselung, also werden das in der Mitte einfach komprimierte Daten sein.

              Was beginnt mit ein paar Bytes ohne MSBit gesetzt, enthält komprimierte Daten und endet mit relativ vielen gleichen (0) Bytes mit nur wenigen MSBit gesetzt? Theorie: ZIP. Eine ZIP-Datei würde mit den vier Bytes ['P', 'K', '\x03', '\x04'] beginnen, wir behalten das mal im Hinterkopf.

              Vielleicht erstmal die Schlüssellänge bestimmen. Dazu müssten wir die Wiederholungen am Ende der Datei quantisieren. Ein paar der auffälligen Muster suchen und Abstände bestimmen: "qpsz} " zu "qpsz} ", "<:cbmlbm" zu "<:cbmlbm" usw. Problem: Da kommen dauernd unterschiedliche Abstände raus. Eigentlich[tm] sollten die Abstände gleich sein und gleich der Schlüssellänge sein. Demnach hätten wir gleichzeitig Schlüssellängen von 49, 173, 172, 46, 47, 171, usw. Wir erinnern uns an http://forum.de.selfhtml.org/archiv/2008/4/t169920/#m1110125 mit dem Link zu http://tm3-fuhrpark.de/send_file.php?infile=send_file.php (jetzt defunct, konservierte Version hier). Dort wurde nicht die straight-forward Vigenère-Verschlüsselung verwendet sondern eine unmotivierte (und nur wenig sicherere) Variante: Statt den Schlüssel direkt zu wiederholen, wird er vor jeder Wiederholung um 5 rotiert. Nebenbei ist da noch ein Bug drin der pro Schlüssel-Wiederholung ein Zeichen Klartext unverschlüsselt in die Ausgabe schreibt (die Prüfung ist auf if ( $j > strlen($schl_kopie) ) statt auf if ( $j >= strlen($schl_kopie) ), was erlaubt dass auf $schl_kopie[strlen($schl_kopie)] zurückgegriffen wird, was "" ergibt und ord("") ergibt einfach 0 ohne Warnung. Mir ist das dann später beim programmieren meiner eigenen Version in Python aufgefallen weil Python eine Exception wirft wenn man ord auf "" anwendet.

              Mit diesen Erkenntnissen wenden wir jetzt mal noch ein neues und cooles Werkzeug an: Dotplots. Damit kann man Selbstähnlichkeiten in großen Strings graphisch darstellen.

              http://www.ploetzli.ch/xorwette/dotplot-mittendrin.png zeigt einen beliebigen Teil in der Mitte der Datei, ohne selbstähnlichkeit, alles sehr zufällig. Gut verschlüsselt oder gut komprimiert.

              http://www.ploetzli.ch/xorwette/dotplot-interesting.png vom Ende der Datei (die Achsenbeschriftungen sind falsch, da muss jeweils noch 47034 addiert werden) ist interessanter. Viel Selbstähnlichkeit. Um das zu filtern habe ich ein Tool (Vorsicht, da ist ganz viel anderer Code, teilweise mit if False auskommentiert drin) geschrieben was alle wiederholten Teile aus der Datei extrahiert (ein paar Strings werden bis zu fünfmal wiederholt) und den Dotplot nur für diese Teile malt. Das sollte direkt den Keystream geben (falls das konstante Zeichen 0x0 ist, wie bei ZIP zu vermuten). Wenn man dann zum Zwecke der Rauschunterdrückung den Dotplot nur für 4gramme malt, sieht das so aus:

              http://www.ploetzli.ch/xorwette/dotplot-keystream-ende-4gram.png

              Die Stellen wo die Hauptdiagonale fehlt sind die Stellen für die kein wiederhergestellter Keystream existiert (dort wurde also nicht das konstante Zeichen verschlüsselt). Das führt dazu dass auch alle Wiederholungen des keystreams an dieser Stelle unterbrochen sind. Ein Beispielkeystream, erstellt mit dem ursprünglichen Algorithmus von send_file.php, Schlüssellänge 175, Sprungweite 45 sieht so aus: http://www.ploetzli.ch/xorwette/dotplot-testdata.175.045.png

              Wir sind also ganz gut auf dem Weg.

              Durch Messen der Abstände der Nebendiagonalen zur Hauptdiagonalen müssten wir relativ direkt auf Schlüssellänge und Sprungweite kommen. Pustekuchen. Ich hab die Abstände der beiden wichtigsten Nebendiagonalen (die zusammen den Schlüssel repräsentieren sollten, die anderen sollten nur Spiegelungen sein) mal eingezeichnet: http://www.ploetzli.ch/xorwette/dotplot-keystream-ende-4gram-annotate.png

              Die Abstände sind nicht gleich, sondern verändern sich. Hier wird geschummelt. Ich habe dann relativ lange versucht auf halbwegs elegante und automatische Weise auf die Art der Veränderung zu kommen. Offenbar wird die Sprungweite die wir aus dem send_file-Algorithmus kennen bei jedem Sprung verändert. Dazu hab ich ein Programm geschrieben was alle Möglichkeiten durchgeht und Bilder generiert. Dann war mir das auswerten der Bilder zu viel und ich hab es die Abstände berechnen lassen und nach den gleichen Abständen gesucht. Da kamen zu viele false positives raus, und mir fiel ein dass ich ja gar nicht gleiche Abstände haben will, sondern identische Punkte. (In C programmiert und mit -O3 übersetzt dauert das übrigens nur 40 Sekunden.) Da kamen bloß noch zwei positives raus: Schlüssellänge 125 und Initialsprungweite 73, sowie 125 und 20. Die sind zwar beide unterschiedlich, erzeugen aber am Ende der Datei exakt das gleiche Bild wie die bekannten Schlüsselstromdaten (grün theoretische Daten, kaum zu sehen rot die echten Daten): http://www.ploetzli.ch/xorwette/dotplot-keystream-ende-10gram-vs-testdata.125.73.png

              Am Anfang der Datei sind die beiden aber unterschiedlich, und keines von beiden passt. Um wenigstens ein bisschen bekannten Klartext am Anfang der Datei zu generieren bin ich dann dazu übergegangen die ersten paar Bytes des Geheimtextes mit Bytefolgen vom Ende der Datei zu xoren. Die generierten Varianten habe ich dann dem file-Kommando vorgelegt um zu schauen ob es welche davon am Magic erkennt. Zu viele false positives: Von rund 5 Mio varianten hat file 500.000 nicht als "data" abgetan, aber die restlichen manuell zu durchsuchen war mir dann doch zu umständlich. Eins fiel aber auf: Da waren verdammt viele große "U"s (0x55) drin.

              Stellt sich raus dass der feste Klartext am Dateiende ein "U" ist. Wenn man die letzten ca. 600 Bytes mit 0x55 xort, kriegt man direkt den Schlüsselstrom, nur von wenigen anderen Bytes unterbrochen (da wo der Klartext nicht fest U war). Auf dieser Basis kann decrypter-final.py (nein, ist noch nicht final, ist bloss finaler als die Vorversion "decrypter.py") das Ende der Datei entschlüsselt. Es berechnet die Sprungwerte mit den Parametern von eben (125 und 20 oder 125 und 73), weiss dann welche Bytes im Geheimtext welchen Schlüsselbytes entsprechen, macht eine kurze Häufigkeitsanalyse um die Stellen wegzuwerfen wo das Klartextbyte nicht fest ist und wendet ausserdem noch den oben angesprochenen Null-Byte-Bug an um den exakten Wert des festen Klartextzeichens (U) zu ermitteln und einzubeziehen. Das liefert ciphertext.decrypter-final (die eigentlich plaintext.decrypter-final heissen müsste) wo man den String ...UUUUUULAME3.96.1UUUUU... in allerschönster Klarheit lesen kann, sowie den Schlüssel 'ZOIFG15+\xa7$%&/()=?J;MJHGTRE xfghjuio67897856358 #+\xb4\xb42^^fghjkghujk ascdvbnm,\xdf0oizu57856  jbjhf k oihioiUI OH IOJ JOP OH UZGTF D' (oder eine Rotation davon).

              Kurzes Googlen zertrümmert damit auch die ZIP-Theorie. Was wir sehen ist ein LAME-Tag, welches in MP3-Dateien vorkommt. Der Dateianfang ist leider auch nicht intakt, weder 125;20 noch 125;73 sind die korrekten Parameter (oder vielleicht ist der Algorithmus auch noch etwas unvollständig).

              Mit der neuen MP3-Theorie bewaffnet widmen wir uns nochmal dem Dateianfang. Unter Umständen könnte doch dort ein ID3v2-Tag sein, das würde sich durch die drei Bytes ['I', 'D', '3'] äussern. Wir versuchen also alle möglichen Rotationen des Schlüssels bis wir schliesslich herausfinden dass der Schlüssel mit [' ', ' ', 'j'] anfängt, danach dann halt der Rest. Das gibt uns 125 Bytes bekannten Klartext am Dateianfang, damit müsste doch was zu machen sein.

              Hauptaufgabe ist jetzt, die korrekte Variante der Schlüsseldrehungen zu finden, ausgehend von der Hypothese aus decrypter-final.py. Da wir zum Glück alle 126-Byte-Blöcke unabhängig voneinander behandeln können machen wir das iterativ. Den Offset für Block Teil 0 definieren wir als 0; die Offsets für die Blöcke 374 bis 379 kennen wir. Jetzt kommt die Stunde von decrypter-knownkey.py. Ausgehend von diesen vorgegebenen Offsets, der Theorie für die anderen Offsets, und mit Hilfe von mp3val gehen wir Schritt für Schritt vor, in der Art von: [code]for i in seq 0 125; do ./decrypter-knownkey.py _ 4 $i; done[/code] (dauert 13 Sekunden) und [code]mp3val plaintext.decrypter-knownkey.try..4.*[/code] um zu sehen dass 79 der beste Wert ist, 3: 79 im Source ergänzen, dann [code]for i in seq 0 125; do ./decrypter-knownkey.py _ 4 _ $i; done[/code] und [code]mp3val plaintext.decrypter-knownkey.try..4._.*[/code] was 30 liefert, usw.

              Irgendwann wird uns das manuell zu albern und wir automatisieren: decrypter-findoffsets.py (enthält Teillösungen in Kommentaren, sowie die vollständige Lösung). Das findet zwar nur ca. alle 4 oder 5 Offsets (dauert etwa 'ne dreiviertelstunde, mit Unterbrechungen alle 4 minuten wegen Zweideutigkeiten, die man aber auch noch automatisieren hätte können), nämlich genau die an den MP3-Frame-Grenzen, aber das muss genügen. Nachdem das durchgelaufen ist kann man die Datei sogar schon abspielen! http://www.ploetzli.ch/xorwette/plaintext.decrypter-knownkey.try.d86ba0c9d85198431471aa04b1be59dfa6d38f6d Klingt spooky, aber die Sprache ist verständlich. Erinnert an CSI.

              Jetzt wieder drüber nachdenken und versuchen das Schema der beobachteten Offsets zu generalisieren. Dieses Restklassengewurschtel verursacht bei mir jedesmal Kopfschmerzen. Also: Ausgehend von ~~~ python { 374:   5, # diff  50 375:  81, # diff  49 376:  33, # diff  48 377: 111, # diff  47 378:  65, # diff  46 379:  20, # diff  45 } ~~~ nehmen wir als Arbeitshypothese an dass von hinten gesehen die Differenz von 45 ausgehend jeweils um 1 steigt. Gesagt, eingegeben, den hinteren Teil der Datei wiederhergestellt. Das geht gut bis zu 303: 40, # diff 121. Zum Glück sind 302 und 301 zwei Blöcke deren Offsets wir von mp3val kennen: 85 und 6. Zusammen macht das eine Differenz von 46. Ausserdem ist 40 zu 84 eine Differenz von 45. Hier beginnt eine neue Straße! Also neue Theorie für die Offsets formuliert: Von Block 379 mit Offset 20 und Differenz 45 nach vorne steigt die Differenz je um 1, bis sie 120 erreicht hat, und fängt dann bei 45 wieder an. Das stellt die Datei vollständig wieder her: http://www.ploetzli.ch/forumtst/plaintext.decrypter-knownkey.try.b290ec282ee4fb1d5c09cb08b3b5497b8e099d5f

              Ergänzend könnte man noch einen alternativen Offset-Generator definieren, von vorne her. Subtraktion von 45 mod 125 ist nämlich Addition von 80 mod 125 und Subtraktion von 120 mod 125 ist Addition von 5 mod 125. Kalles Offset-Generator sah also vermutlich so aus, das liefert die gleichen Werte:

              def offset_generator(keylen):   offset=0   diff=5   while True:     yield offset     diff = diff+1     if diff > 80: diff = 5     offset = (offset+diff)%125

              Zusammenfassend: Algorithmus komplett vernichtet. Der Algorithmus ist so schwach und da war so viel erratbarer Klartext dass wir ihn brechen konnten, ohne den Algorithmus zu kennen, und nebenher noch den Algorithmus zu reverse engineeren. Mit nur einer gegebenen Ausgabe. Jetzt wo die Struktur des Algorithmus bekannt ist, bringt es auch nichts die Parameter zu ändern. Wie gesagt kann ich in C alle Schlüssellängen und alle Initialdifferenzen von 1 bis 250 (jeweils) in 40 Sekunden ausprobieren. Wenn man jetzt die magischen Zahlen 80 und 5 ändern würde, könnte man die bei bekannter Schlüssellänge, ebensoleicht alle durchprobieren. Und selbst wenn die Schlüssellänge nicht gegeben ist kann man sie entweder leicht erraten oder durchprobieren.

              Verstärkt wurden diese Probleme nur noch durch die prozeduralen Fehler: Kein zufälliger Schlüssel, Bug in der Implementierung.

              Also: AES nehmen, oder, wenn man konservativ sein will, 3DES, und alles wird gut. Selbstgebaute Verschlüsselsungsverfahren von Laien gehen immer schief. Selbst Profis machen gerne Anfängerfehler (lustige Anekdote http://www.trust-us.ch/ds/66/008_aes.html Abschnitt "Telekom sorgt für Heiterkeit"). Nur Verschlüsselungsalgorithmen die öffentlich bekannt sind und wenigstens ein paar Jahre lang von Kryptologen ergebnislos untersucht wurden sind vertrauenswürdig.

              -- Henryk Plötz Grüße aus Berlin ~~~~~~~~ Un-CDs, nein danke! http://www.heise.de/ct/cd-register/ ~~~~~~~~ ~~ Help Microsoft fight software piracy: Give Linux to a friend today! ~~

              Folgende Nachrichten verweisen auf diesen Beitrag:

              1. Moin!

                Zusammenfassend: Algorithmus komplett vernichtet. Der Algorithmus ist so schwach und da war so viel erratbarer Klartext dass wir ihn brechen konnten, ohne den Algorithmus zu kennen, und nebenher noch den Algorithmus zu reverse engineeren.

                GANZ GROSSES KINO! :)))))))))

                 - Sven Rautenberg

                -- "Love your nation - respect the others."
              2. Faszinierend! *applaus*

                Und danke für die sehr ausführliche Erklärung!

                Gruß, Samoht

                "Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd all be running around in darkened rooms, munching magic pills and listening to repetitive electronic music."

                (Kristian Wilson, Nintendo, 1989)

                -- fl:| br:> va:) ls:< n4:( ss:) de:] js:| mo:}
              3. Hallo Henryk.

                Starke Leistung, mein Respekt!

                Servus,
                Flo

              4. Gratulation Henryk,

                vom Feinsten! Beeindruckend!
                Mir fehlen einfach die Worte ...

                Freundliche Grüße

                Vinzenz

              5. Hi,

                Dafür müsstest du eigentlich mehr als die 100 Euro bekommen. :-)

                Hat sich Kalle_B denn schon gemeldet?

                Schönes WE

                --
                selfcode: ie:% fl:( br:> va:) ls:& rl:( n4:~ ss:| de:> js:( ch:? mo:} zu:)
                "Egal, ob ein Sandkorn oder ein Stein. Im Wasser sinken sie beide."

              6. Gratulation und Respekt!

                Gruß
                tox

              7. Tach auch Henryk,

                Sauber!

                Bookmarken, aufheben, immer nochmal lesen...

                Ich muß Dich nicht fragen, ob wir das in die Artikel-Sammlung aufnehmen können, oder?

                http://www.gruss-aus-essen.de

                Maik

                -- Diese Dauerleihgabe wird Ihnen präsentiert von ROMY!
                Maik. W. aus E. sagt Dankeschön ;-)
              8. Tach,

                ich sag mal danke für dieses großartige Beispiel auf das man gerne in zukünftigen Diskussionen verweisen kann.

                mfg
                Woodfighter

              9. Hi,

                Chapeau! :-)))

                Also: AES nehmen, oder, wenn man konservativ sein will, 3DES, und alles wird gut. Selbstgebaute Verschlüsselsungsverfahren von Laien gehen *immer* schief.

                Hmm, ich verwende (eine abgewandelte Variante von) MD5-based block cypher. Das es (deutlich) sicherer ist als Kalle_Bs XOR-Spielereien, davon gehe ich auch als Nicht-Kryptographie-Experte aus.

                Dachte auch, er wäre hinreichend sicher, aber nun ...

                ... frage ich dich mal lieber ;-): Für dich knackbar? Oder nur für Institutionen mit Arsch viel Rechenleistung? Oder eher gar nicht?

                Ich tippe ja auf letzteres ...

                Gruß, Cybaer

                --
                Man kann doch sehr leicht jenen tugendhaften Menschen begegnen, (...) die eine Art "unkrümmbaren Zeigefinger" besitzen, der ständig den kalten Wind des Rechthabens ausströmt. (Wolfgang Huber, Bischof)

                Die Tugend jagt nicht den Teufel, sondern den Sündhaften. Damit wird sie zum Terror. (Hans-Ulrich Jörges, Journalist)

                1. Moin!

                  Hmm, ich verwende (eine abgewandelte Variante von) MD5-based block cypher. Das es (deutlich) sicherer ist als Kalle_Bs XOR-Spielereien, davon gehe ich auch als Nicht-Kryptographie-Experte aus.

                  Warum gehst du davon aus?

                  Auch dieser Algorithmus verwendet als grundlegende "Verschlüsselung" eine XOR-Operation.

                  Er macht zwar gewisse Dinge "richtiger", aber in meinen Augen reicht das nicht aus - das Ding sieht eher aus, wie selbstgestrickt, und versucht durch Schlüsselworte wie "MD5" eine psychologische Sicherheit zu erzeugen - weil ja jeder weiß, dass MD5 unknackbar hasht.

                  Dinge, die "richtiger" gemacht werden, sind der zufällige Initialisierungsvektor (der wird allerdings - zwingend - als allererstes im Chiffre-String gespeichert), die Ausnutzung des gesamten Bytebereichs fürs XOR (das Resultat von MD5 wird als 16-Byte-Sequenz genutzt) und die rekursive Wiedereinspielung des vorherigen Blocks in den neuen Initialisierungsvektor.

                  Das halte ich aber nicht für ausreichend.

                  Bei Kenntnis des Algorithmus und eines Ciphertextes ist eine Known-Plaintext-Attacke immer zielführend. Und du hast ja gesehen, dass man da nur richtig raten muß, um auf ein Ergebnis zu kommen. Auch durch eine komplexe XOR-Operation "scheinen" interessante Dateiformat-Infos hindurch.

                  Dachte auch, er wäre hinreichend sicher, aber nun ...

                  ... frage ich dich mal lieber ;-): Für dich knackbar? Oder nur für Institutionen mit Arsch viel Rechenleistung? Oder eher gar nicht?

                  Ich tippe ja auf letzteres ...

                  Die Sache ist doch ganz einfach: Welchen Grund gibt es für dich, einen potentiell knackbaren Algorithmus einzusetzen, von dessen Sicherheit du dich selbst nicht überzeugt hast, und der aufgrund der Tatsache, dass er komplett in PHP implementiert ist, auch noch arschlangsam ist. Was spricht gegen die Nutzung des mcrypt-Moduls in Verbindung mit einem als sicher angesehenen Algorithmus wie AES? Alternativ könnte es auch PGP/GnuPG sein, das hätte sogar den großen Vorteil, dass der verschlüsselnde Server den Key zum Entschlüsseln gar nicht kennt.

                   - Sven Rautenberg

                  -- "Love your nation - respect the others."
                  1. Hi,

                    Warum gehst du davon aus?

                    Wie Du sagtest:

                    und versucht durch Schlüsselworte wie "MD5" eine psychologische Sicherheit zu erzeugen - weil ja jeder weiß, dass MD5 unknackbar hasht.

                    =:-}

                    Das halte ich aber nicht für ausreichend.

                    Danke für die Einschätzung!

                    Was spricht gegen die Nutzung des mcrypt-Moduls in Verbindung mit einem als sicher angesehenen Algorithmus wie AES?

                    Es gehört nicht zum Standardumfang, und steht folglich nicht immer zur Verfügung. :-/

                    Ich muß aber auch auf den (Massenhost-)Servern eine Verschlüsselung haben, auf denen mcrypt nicht installiert ist bzw. installiert werden kann! ("Dann wechsel halt den Provider" ist keine Alternative, da ich darauf keinen Einfluß habe - "wir" haben mcrypt ohnehin installiert.)

                    Und über die Verarbeitungsgeschw. muß ich mir keine Gedanken machen: Ich verschlüssel damit keine MP3s, sondern Datenmengen, die man i.A. noch als GET-Parameter übergeben kann ...

                    ... also eher als besserer Sichtschutz.

                    Trotzdem hätte ich natürlich gerne ein Verfahren, das sowohl sicher ist, als auch auf jedem PHP-Standard-Server funktioniert - selbst wenn es langsam ist.

                    Wenn es also besseres gibt: Ich bin dankbar für jeden Hinweis! :-)

                    Gruß, Cybaer

                    --
                    Man kann doch sehr leicht jenen tugendhaften Menschen begegnen, (...) die eine Art "unkrümmbaren Zeigefinger" besitzen, der ständig den kalten Wind des Rechthabens ausströmt. (Wolfgang Huber, Bischof)

                    Die Tugend jagt nicht den Teufel, sondern den Sündhaften. Damit wird sie zum Terror. (Hans-Ulrich Jörges, Journalist)

                    1. 你好 Cybaer,

                      Was spricht gegen die Nutzung des mcrypt-Moduls in Verbindung mit einem als sicher angesehenen Algorithmus wie AES?

                      Es gehört nicht zum Standardumfang, und steht folglich nicht immer zur Verfügung. :-/

                      Es gibt auch AES-Implementierungen in "reinem" PHP, dass du mit ausliefern könntest. Auf die Schnelle habe ich via Google (Stichworte: AES 256 php) z. B. http://www.phpaes.com/ gefunden.

                      再见,
                       克里斯蒂安

                      --
                      Bauer sucht Frau! | Ich bin ja eigentlich kein Serien-Junkie…
                      <g[oma]> peter lustig ist auf jeden fall besser als peter huth, obwohl der auch lustig ist.

                      http://wwwtech.de/

                      1. Hi,

                        Auf die Schnelle habe ich via Google (Stichworte: AES 256 php) z. B. http://www.phpaes.com/ gefunden.

                        Danke. Ist zwar Löhnsoft und kommt damit für mich eigentlich nicht in Frage (die Kunden, bei denen es wichtig ist, die sollen IMHO auch zu einem passenden Hoster), aber gut zu wissen. Die Seite gibt mir auch Anregungen, wonach zu googeln ist! :)

                        Gruß, Cybaer

                        --
                        Man kann doch sehr leicht jenen tugendhaften Menschen begegnen, (...) die eine Art "unkrümmbaren Zeigefinger" besitzen, der ständig den kalten Wind des Rechthabens ausströmt. (Wolfgang Huber, Bischof)

                        Die Tugend jagt nicht den Teufel, sondern den Sündhaften. Damit wird sie zum Terror. (Hans-Ulrich Jörges, Journalist)

                      2. Moin moin,

                        Es gibt auch AES-Implementierungen in "reinem" PHP, dass du mit ausliefern könntest. Auf die Schnelle habe ich via Google (Stichworte: AES 256 php) z. B. http://www.phpaes.com/ gefunden.

                        AES ist in PHP viel zu langsam, selbst wenn man nur 1 kb verschlüsseln möchte, wartet man schon eine halbe Ewigkeit (bei der Implementierung über 0,5 Sekunden).

                        Persönliche habe ich in einer Anwendung Blowfish  eingebaut, da dies der bisher schnellste Algorithmus ist, den ich für PHP gefunden habe und ich dort größere Datenmengen verschlüssen muss.
                        Die Blowfish-Implementierung schafft auf meinem Rechner 90-100 kb/Sek (okay, AES in C schafft >100 MB/Sek), wobei AES, DES oder ähnliche nur 1 bis 5 kb/sec schaffen, also deutlich weniger. PHP ist für solche Dinge einfach nicht geeignet.

                        Gut, Blowfish sollte man wenns geht eigentlich nicht mehr verwenden, da z.B. manche Funktionen nicht mit Blowfish funktionieren (Blowfish sollte man nicht in bestimmten Stromchiffren-Moden oder als Hash-Funktion benutzen), im normalen CBC Modus ist dieser aber nach wie vor sicher und wie gesagt, bei mir kam es auf Performance drauf an, es ist dem User nicht zumutbar, 5 Sekunden zu warten wenn dieser 20 kb verschlüsseln muss.
                        Und viele Algorithmen sind einfach extrem langsam in PHP und deswegen nicht einsetzbar, weswegen meine Wahl auf PHP viel.

                        Hoffe konnte weiterhelfen.

                        1. 你好 Klaus,

                          AES ist in PHP viel zu langsam, selbst wenn man nur 1 kb verschlüsseln möchte, wartet man schon eine halbe Ewigkeit (bei der Implementierung über 0,5 Sekunden).

                          Danke für den Einwand. Ich habe da keine Erfahrungen mit, ich arbeite (zum Glück) quasi nie mit PHP.

                          再见,
                           克里斯蒂安

                          --
                          Bauer sucht Frau! | Ich bin ja eigentlich kein Serien-Junkie…
                          Death is God's way of telling you not to be such a wise guy.

                          http://wwwtech.de/

                  2. Moin,

                    Auch dieser Algorithmus verwendet als grundlegende "Verschlüsselung" eine XOR-Operation.

                    Der Fairness halber: Das ist noch kein K.O.-Kriterium. XOR als grundlegende Operation ist auch in sicheren Algorithmen verbreitet, etwa RC4 (ja, das Beispiel ist doof weil RC4 ... launisch ist und unbedingt korrekt angewendet werden muss, unter anderem muss man die ersten paar Bytes des Schlüsselstroms wegwerfen), üblicherweise arbeiten alle Stromchiffren so.

                    Und ja, im Prinzip[tm] kann man mit einer Hashfunktion eine ordentliche Chiffre bauen. Schneller als dedizierte Verschlüsselungsalgorithmen wird das aber bestimmt nicht. Ausserdem muss man vorsichtig sein: MD5 ist bekannt kaputt. Die Angriffe beziehen sich zwar hauptsächlich auf Kollisionen (was verschiedene Schlüssel für die selbe Datei erlauben würde und schon schlimm genug ist), aber auch umkehren von MD5-Hashes wird immer mehr zum Volkssport. Das könnte (je nachdem wie man den Algorithmus auf MD5 aufbaut) direkt zu einer known-plaintext-Attacke führen die den Schlüssel oder wenigstens alle Blöcke hinter dem known plaintext liefert.

                    Er macht zwar gewisse Dinge "richtiger", aber in meinen Augen reicht das nicht aus - das Ding sieht eher aus, wie selbstgestrickt, und versucht durch Schlüsselworte wie "MD5" eine psychologische Sicherheit zu erzeugen - weil ja jeder weiß, dass MD5 unknackbar hasht.

                    Huh? Wer weiss das? :-) Leider ist SHA-1 auch auf dem absteigenden Ast, und überhaupt basieren alle heute gebräuchlichen Hashfunktionen auf dem selben angreifbaren Design. Hoffen wir mal dass das NIST uns bald Nachfolger geben kann.

                    Dinge, die "richtiger" gemacht werden, sind der zufällige Initialisierungsvektor (der wird allerdings - zwingend - als allererstes im Chiffre-String gespeichert),

                    Was auch korrekt ist.

                    Und du hast ja gesehen, dass man da nur richtig raten muß, um auf ein Ergebnis zu kommen. Auch durch eine komplexe XOR-Operation "scheinen" interessante Dateiformat-Infos hindurch.

                    Nicht wenn der Schlüsselstrom kryptographisch zufällig ist, das ist die ganze Funktionsweise von Stromchiffren.

                    --
                    Henryk Plötz
                    Grüße aus Berlin
                    ~~~~~~~~ Un-CDs, nein danke! http://www.heise.de/ct/cd-register/ ~~~~~~~~
                    ~~ Help Microsoft fight software piracy: Give Linux to a friend today! ~~

                2. Hallo Cybaer,

                  Hmm, ich verwende (eine abgewandelte Variante von) MD5-based block cypher. Das es (deutlich) sicherer ist als Kalle_Bs XOR-Spielereien, davon gehe ich auch als Nicht-Kryptographie-Experte aus.

                  Sofern du da keine Schwachstelle eingebaut hast (ob absichtlich oder unabsichtlich) dürfte das deutlich sicherer sein und zumindest hier im Forum nicht geknackt werden können. Immerhin verwendest du halbwegs sichere Verfahren und Methoden.

                  Dennoch wird auch das von "Experten" mit entsprechenden Mitteln möglicherweise knackbar sein. Und es gibt keinen wirklichen Grund keine herkömmlichen, erprobten Verfahren zu benutzen.

                  Sowas wie hier, indem man nur aus ein bisschen verschlüsseltem Text Klartext, key und den Alorithmus generiert, klappt aber nur bei extrem schwachen Verschlüsselungen. Alle halbwegs guten Verschlüsselungen liefern ein Ergebnis, das komplett zufällig aussieht, woraus dann erstmal keine weiteren Informationen gewonnen werden können.

                  Jonathan

                  -- Selfcode: ie:( fl:{ br:> va:) ls:& fo:) rl:? ss:} de:> js:| ch:? mo:} zu:)
                  1. Moin!

                    Hmm, ich verwende (eine abgewandelte Variante von) MD5-based block cypher. Das es (deutlich) sicherer ist als Kalle_Bs XOR-Spielereien, davon gehe ich auch als Nicht-Kryptographie-Experte aus.

                    Sofern du da keine Schwachstelle eingebaut hast (ob absichtlich oder unabsichtlich) dürfte das deutlich sicherer sein und zumindest hier im Forum nicht geknackt werden können. Immerhin verwendest du halbwegs sichere Verfahren und Methoden.

                    Auf welche Tatsachen stützt du diese Behauptung? Einfach nur, weil der Algorithmus komplex aussieht, oder gibt es typische Anhaltspunkte?

                     - Sven Rautenberg

                    -- "Love your nation - respect the others."
                    1. Hallo Sven,

                      Auf welche Tatsachen stützt du diese Behauptung? Einfach nur, weil der Algorithmus komplex aussieht, oder gibt es typische Anhaltspunkte?

                      Nen bisschen beschäftigt hab ich mich damit auch. So komplex ist der gar nicht. Ganz perfekt ist der da auch nicht, insbesondere weil der erste Block nur aus

                      Klartext XOR md5(Passwort XOR Ciphertext)

                      besteht und damit möglicherweise wesentlich einfacher zurückgerechnet werden kann als der Rest, insbesondere bei teilweise bekannten Klartext.

                      Auch sonst ist das alles andere als Optimal, es wird z.B. kein Salt benutzt. Dennoch denke ich, dass der Code einer normalen Forums-Attacke insbesondere wegen der deutlich schwereren "Zurückberechenbarkeit" von MD5-Hashes standhalten wird. Und wenn der Algorithmus unbekannt ist, sowieso, weil dieser Quellcode nämlich wirklich zufällig aussehende Resultate liefert.

                      Jonathan

                      -- Selfcode: ie:( fl:{ br:> va:) ls:& fo:) rl:? ss:} de:> js:| ch:? mo:} zu:)
                      1. Hi,

                        weil dieser Quellcode nämlich wirklich zufällig aussehende Resultate liefert.

                        Ja, das war einer der Gründe, warum ich diese Funktion als Basis verwendet habe.

                        Zwar mache ich meine tatsächlich "Funktion" nicht öffentlich, aber "Security by Obscurity" ist nun auch nicht gerade das, womit ich glücklich wäre. ;)

                        Gruß, Cybaer

                        --
                        Man kann doch sehr leicht jenen tugendhaften Menschen begegnen, (...) die eine Art "unkrümmbaren Zeigefinger" besitzen, der ständig den kalten Wind des Rechthabens ausströmt. (Wolfgang Huber, Bischof)

                        Die Tugend jagt nicht den Teufel, sondern den Sündhaften. Damit wird sie zum Terror. (Hans-Ulrich Jörges, Journalist)

              10. Hallo!!

                WAHNSINN!!

                Ich habe versucht, wenigstens ein bisschen zu folgen, mitzudenken, Fachbegriffe nachzulesen ... bis mir gnadenlos der Schädel brummte, und dann ... ja, dann kommt diese Stelle

                Jetzt wieder drüber nachdenken und versuchen das Schema der beobachteten Offsets zu generalisieren. Dieses Restklassengewurschtel verursacht bei mir jedesmal Kopfschmerzen. Also: ...

                Das ist der Brüller! LOL

                Danke für diesen Beitrag. Nicht nur fachlich interessant, sondern auch sprachlich ganz hervorragend präsentiert. RESPEKT!!!!!!

                Gruß vom foomaker, der sich jetzt ganz ganz ganz klein fühlt  ;-)

                --
                Natürlich glaube ich an die Existenz von Ausserirdischen. Schliesslich gibt es ja auch das PERFEKTE SCRIPT.

              11. Danke für das beste Posting seit Jahren. Zehn, um genau zu sein.

                Respekt!

                Roland

                --
                Top Fives // »Schlechte Werbung. Gibt es nicht.« // mitmachen

              12. Hallo Henryk,

                ich kann mich den anderen nur anschließen.
                Auch wenn ich zugegebenermaßen nicht alles völlig verstanden habe finde ich es doch überaus interessant, was Du da zusammengeschrieben hast. Und unterhaltsam ist Dein Text auch noch, und das bei einem an sich relativ trockenen Thema.

                ... sowas würde man gern öfter lesen ;)

                Grüße aus Stockholm,
                Götz

                --
                Losung für Montag, 28. April 2008
                David sprach zum HERRN: Ich habe schwer gesündigt, dass ich das getan habe. Und nun, HERR, nimm weg die Schuld deines Knechts. (2.Samuel 24,10)
                Jesus sprach: Die Starken bedürfen keines Arztes, sondern die Kranken. Ich bin gekommen, die Sünder zu rufen und nicht die Gerechten. (Markus 2,17)
                (zur aktuellen Losung)

              13. Hi Henryk,

                tut mir Leid, aber ich denke, im Interesse der oeffentlichen Sicherheit sollte man Leute wie dich™ sicher wegschliessen ... Moment, ich sag' mal eben dem Wolfgang Bescheid.

                Nein, im Ernst - klasse Analyse!
                Interessehalber: Wie lange hast du dafuer gebraucht?

                MfG ChrisB

  11. Hallo, Henryk,

    danke dir für deine Arbeit. War ein Klasse Beitrag.

    Gleich geht eine Mail an henryk@ploetzli.ch, um deine Adresse abzufragen.

    Bei deiner Mailadresse kommt ein uraltes Bild in mir hoch, auf einem Milchwagen standen drei Buchstaben und dahinter war das Schweizer Kennzeichen:

    MIL - CH

    Die Schweizer sparen eben, wo sie können. Und rechnen den Euro schon mal etwas leger zu ihren Gunsten um. Jedenfalls am Bodensee.

    LG Kalle_B

    1. Bei deiner Mailadresse kommt ein uraltes Bild in mir hoch, auf einem Milchwagen standen drei Buchstaben und dahinter war das Schweizer Kennzeichen:

      MIL - CH

      Die Schweizer sparen eben, wo sie können. Und rechnen den Euro schon mal etwas leger zu ihren Gunsten um. Jedenfalls am Bodensee.

      http://de.wikipedia.org/wiki/Autokennzeichen_(Schweiz)

      http://de.wikipedia.org/wiki/Liste_der_Kfz-Kennzeichen_in_Deutschland#M
      http://de.wikipedia.org/wiki/Landkreis_Miltenberg

    2. echo $begrüßung;

      Eine Empfehlung: Du solltest hier im Forum nicht immer nur Fragen zu deinen speziellen Probleme stellen sondern auch mal aufmerksam mitlesen, wenn Hinweise an andere gegeben werden. Bei jemandem, der grad zu programmieren angefangen hat, dann dieses Forum entdeckt und sein Problem beschreibt, bei dem die geübten Augen neben ebendiesem noch ein paar unbeachtete sicherheitsrelevante Lücken feststellt ist, ist das verständlich. Wenn man aber bei dir, der du doch auch zu den Stammusern gezählt werden kann, auf deiner Seite ebendiese hier sehr häufig angesprochenen Sicherheitslücken entdeckt, dann bleibt einem nur, sich stark zu wundern.

      Ein Lesetipp: http://www.heise.de/security/Sicherheit-von-Webanwendungen--/artikel/84149

      echo "$verabschiedung $name";

      1. Hallo, dedlfix,

        ich wünschte mir so manches berufsbegleitende Wochenend- oder Abendseminar, in dem man als Programmierer mal mit solchen Fachthemen konfrontiert wird. In den Volkshochschulen lernt man das Mäuseschubsen für Anfänger und ein bisschen Microsoft.

        Für mich als "Alleinunterhalter" ist mir das Forum eine wertvolle Hilfe, aber ich kann nicht ständig am Bildschirm kleben und mitlesen. Sitze pro Tag schon viel zu lange davor.

        Muss diese Faden noch auswerten. Beim Lesen bin ich nicht viel schlauer geworden, nur einer Illusion beraubt, was mir 100 € wert war.

        Kalle

        1. echo $begrüßung;

          Für mich als "Alleinunterhalter" ist mir das Forum eine wertvolle Hilfe, aber ich kann nicht ständig am Bildschirm kleben und mitlesen. Sitze pro Tag schon viel zu lange davor.

          Das ist nachvollziehbar, und den letzten Satz werden sicher nicht wenige hier genauso von sich sagen. Doch kann ich es mit gut vorstellen (ohne es jemandem zu wünschen), dass man die Zeit, die man nicht zum Erlangen sicherheitsrelevanten Wissens verwendet, eines Tages für das Aufräumen und Wiederherstellen des Systems und des Imageschadens nach dem Ausnutzen einer der Lücken durch Unwissenheit verwenden muss.

          echo "$verabschiedung $name";

    3. Moin,

      Bei deiner Mailadresse kommt ein uraltes Bild in mir hoch, auf einem Milchwagen standen drei Buchstaben und dahinter war das Schweizer Kennzeichen:

      MIL - CH

      Zur allgemeinen Information: Grade kam ein Einschreiben mit Rückschein von Kalle. Inhalt: zwei Fünfzig-Euro-Scheine, fein säuberlich an ein Stück von einem Milchtütenkarton getackert.

      Dank zurück.

      --
      Henryk Plötz
      Grüße aus Berlin
      ~~~~~~~~ Un-CDs, nein danke! http://www.heise.de/ct/cd-register/ ~~~~~~~~
      ~~ Help Microsoft fight software piracy: Give Linux to a friend today! ~~