Wettbewerb mit Belohnung!

Z

Zhavok

0
Hallo zusammen,ich bin recht neu hier und wie ihr ja vielleicht schon gelesen habt, interessiere ich mich etwas für Kryptographie. Ich habe nun mal einen kleinen Krypto-Algorithmus geschrieben an welchen ich ein paar Ansprüche stelle. Mir ist klar, dass ich nicht der beste Programmierer bin auch auch kein hochbegabter Kryptograph. Ich möchte hier auch keinen zweiten AES schreiben. Es soll ein simpler Algorithmus sein, welchen ich schnell in einfache Scriptsprachen implementieren kann. Zusätzlich soll er aber so sicher sein, dass ein durchschnittlicher IT-Techniker oder Systemadministrator ihn nicht knacken kann. Ebenso sollen auch Programmierer ohne kryptographische Kenntnisse dran verzweifeln. Und wer sich mit dem Thema auskennt sollte es zumindest nicht gleich in 5min rausbekommen. Ich habe euch dazu den Algorithmus (geschrieben in C++) hochgeladen. Zusätzlich bekommt ihr ein Chiffrat (in hexadezimaler Form). Schafft ihr es das Chiffrat zu entschlüsseln, bekommt der erste der es schafft einen PaySafeCard-Code im Wert von 20€. Bruteforce zählt natürlich nicht als gelöst. Außerdem möchte ich, dass ihr mir schreibt, wie ihr den Algorithmus geknackt habt und mir vielleicht ein paar Verbesserungsvorschläge gebt.Kleiner Tipp noch: Beim Compiler bitte unsigned chars als Standard einstellen, sonst könnte es Gemecker geben. Bei VS geht das mit dem Parameter /J.Ich hoffe es versuchen sich ein paar Leute dran. Ich wünsche euch viel Erfolg^^
 
Zuletzt bearbeitet:
Zhavok hat gesagt.:
Hallo zusammen,ich bin recht neu hier und wie ihr ja vielleicht schon gelesen habt, interessiere ich mich etwas für Kryptographie. Ich habe nun mal einen kleinen Krypto-Algorithmus geschrieben an welchen ich ein paar Ansprüche stelle. Mir ist klar, dass ich nicht der beste Programmierer bin auch auch kein hochbegabter Kryptograph. Ich möchte hier auch keinen zweiten AES schreiben. Es soll ein simpler Algorithmus sein, welchen ich schnell in einfache Scriptsprachen implementieren kann. Zusätzlich soll er aber so sicher sein, dass ein durchschnittlicher IT-Techniker oder Systemadministrator ihn nicht knacken kann. Ebenso sollen auch Programmierer ohne kryptographische Kenntnisse dran verzweifeln. Und wer sich mit dem Thema auskennt sollte es zumindest nicht gleich in 5min rausbekommen. Ich habe euch dazu den Algorithmus (geschrieben in C++) hochgeladen. Zusätzlich bekommt ihr ein Chiffrat (in hexadezimaler Form). Schafft ihr es das Chiffrat zu entschlüsseln, bekommt der erste der es schafft einen PaySafeCard-Code im Wert von 20€. Bruteforce zählt natürlich nicht als gelöst. Außerdem möchte ich, dass ihr mir schreibt, wie ihr den Algorithmus geknackt habt und mir vielleicht ein paar Verbesserungsvorschläge gebt.Kleiner Tipp noch: Beim Compiler bitte unsigned chars als Standard einstellen, sonst könnte es Gemecker geben. Bei VS geht das mit dem Parameter /J.Ich hoffe es versuchen sich ein paar Leute dran. Ich wünsche euch viel Erfolg^^Hier der Link: File-Upload.net - Wettbewerb.zip
Zum Vergrößern anklicken....

Der "Download" auf File-Upload.net ist nicht erreichbar. Häng doch einfach die Zip hier an.
 
Ich versuche mal CL hierauf aufmerksam zu machen, der hat doch immer Bock darauf seine Skillz zu demonstrieren :D
 
Klar gerne. Mir ists lieber jemand knackt das Ding und schreibt mir seine Meinung, als dass ich keine Ahnung habe wie sicher das überhaupt ist. Ich weiß nicht ob du schon mal reingeschaut hast, aber ich denke, wenn du es dir mal ne Minute anschaust wirst dus wohl auch schon hinbekommen :D
 
Shalec hat gesagt.:
Ich versuche mal CL hierauf aufmerksam zu machen, der hat doch immer Bock darauf seine Skillz zu demonstrieren :D
Zum Vergrößern anklicken....
yo shalec, danke für die props :D meine sk1illZ demonstriere ich zwar in der tat gerne, aber einen ciphertext zu knacken, ohne den genauen algorithmus zu kennen, geschweige denn die schlüssellänge, ist doch fast unmöglich oder? zhavok was du da tust nennt sich Security through obscurity - Wikipedia das bedeutet die sicherheit deines verfahrens beruht auf der annahme, dass niemand außer dir den algorithmus kennt und somit auch nicht das file entschlüsseln kann. es ist aber nicht zu empfehlen so vorzugehen, da dein algorithmus höchstwahrscheinlich extreme schwachstellen hat, die leicht ausgenutzt werden können sobald das verfahren irgendwie aufgedeckt wird (und sei es durch disassemblieren deines progs). deswegen sollten krypto algorithmen immer öffentlich sein und sollten schon von einigen experten, auf herz und nieren geprüft worden sein, bevor man sie verwendet. ps: wenn jemand dein chiffrat per brute force knacken können sollte, dann hätte er allein für die stromrechnung schon eine höhere entschädigung verdient, ihm dann nicht mal die 20 € zu gönnen, finde ich schon mies ;) frag dich mal wie und woran so ein brute force programm merken können soll, dass es das chiffrat richtig dekodiert hat. so etwas einigermaßen zuverlässig zu implementieren ist nicht so trivial, wie es der name brute force vielleicht vermuten lässt. im schlimmsten fall wartest du 100 jahre lang auf das ergebnis deines brute force programm und es findet keins. das heißt der korrekte schlüssel wurde gar nicht als solcher erkannt. edit: was ist denn mit dem forum los? meine enters werden einfach entfernt. edit2: ich sehe grad, du lieferst deinen algo ja mit. ich bin zwar selber noch ein anfänger (info 2. semester) abersehe es mir mal an :)
 
Zuletzt bearbeitet:
zhavok, kannst du mir als tipp sagen ob es sich beim plaintext um einen deutschen text handelt? oder ein einziges wort nennen was darin vorkommt?
 
Hahahaha, guten Abend CypherL0rd. Zwecks Security through obscurity geb ich dir vollkommen Recht. Deshalb hab ich doch auch den Algorithmus oben angehangen :D. Zwecks Bruteforce könnte man das (auch wenns eher schlecht ist) so machen, dass man einfach die 10 häufigsten Wörter aus dem Englischen und Deutschen nimmt und mit dem gestellten Algorithmus solange decryptet bis man auf eins der Wörter stößt. Ist natürlich nicht sehr zuverlässig, aber nen Glückstreffer kann man damit schonmal erzielen. Und da der Algorithmus sehr simpel ist, dürfte man auch relativ viele Keys pro Sekunde dort durch schießen. Die Schlüssellänge bleibt weiterhin geheim. Ich sag nur, dass er jetzt nicht besonders lang ist. Nicht länger als der Plaintext. Ich gebe die Schlüssellänge deshalb nicht bekannt, weil der Angreifer bei meinen Szenarien auch nicht die Länge kennt, aber vielleicht den Algorithmus.
 
Ich habe nochmal ein neues Chiffrat erstellt: 4a6f70743e897b753e5bcd698c7a81797bcc918e4a6ba2a0ae7598a87d6f75a06e657865b66e6fd0776f6f84c6728581738f90c9 Im Plaintext kommt das Wort reason vor.
 
@CL soweit ich das sehe, kannst du Chosen Plaintext Attacks (CPA) durchführen. Im Detail ist er wirklich nach dem Prinzip von Kerkhoff vorgegangen, alles zu veröffentlichen bis auf den Schlüssel. Also du darfst dich grundlegend nicht beklagen an dieser Stelle :D Tja die Key-length..sowas gibt dir aber auch niemand bekannt ;)Um Security by Obscurity geht es hier auch nicht wirklich. Es ist ein Zusammenspiel von Hashfunktionen und einer Stromcipher welche auch als Block verarbeitet werden kann -> XOR. XOR hat den Nachteil, dass das mehrfache Verwenden des gleichen SChlüssels dazu führt, dass dieser bekannt gemacht werden kann. Kleine Anekdote: Viele Coder setzen auf Security by Obscurity ihres Codes. Sie legen Fake-Traces und Dead-Codes in den Code und verwenden hash-values als Variablennamen. Dadurch wird das Lesen echt dreckig, und schützt den Code vor direkter Manipulation für eine gewisse Zeit. Beispiel: Encryption Funktion verwendet ganz vielen Dead-Code und zieht somit eine enorme Fake-Trace durch des Code. Sagen wir 90% des gesamten Codes wird durch diese Funktion verwendet. Die eigentliche Verschlüsselungsfunktion wird auf anderem Weg ausgeführt (relativer ASM-Jump ggf., sodass hier auch noch sowas einfließt). Der "Hacker" ist erstmal damit beschäftigt die 90% zu isolieren, um dann zu sehen, dass Tage seiner Bemühungen für die Katz waren :D AM Ende bietet es keine sinnvolle Schutzmaßnahme, aber einen Türsteher.
 
Zuletzt bearbeitet:
was habt ihr denn die ganze zeit mit der schlüssellänge? habe doch gar nicht danach gefragt :D ja, war unnötig von mir das mit dem security through obscurity in den raum zu werfen, hätte ich einfach erst mal die datei ansehen sollen. dachte er hat nur den ciphertext hochgeladen und habe deswegen security through obscurity in den raum geworfen. als ich dann meinen fehler eingesehen habe, habe ich mich ja dann auch dazu entschlossen mir das mal genauer anzusehen :) shalec, setzt die chosen plaintext attack nicht voraus dass ich beliebige chiffrate zu plaintext mit dem gesuchten key verschlüsseln (lassen) kann? ich habe zwar den algo, aber damit kann ich ja nicht ciphertexte erstellen, die mit dem gleichen key kodiert wurden wie zhavoks text, ohne diesen zu kennen. oder übersehe ich da etwas oder verstehe gar etwas falsch? gehe morgen für eine woche in den urlaub, danach wird "gehackt" wenn shalec noch ein paar tipps hier liegen lässt :D
 
Moin,
in dem Script vom HB hat sich was sehr negatives eingeschleust. Zeilenumbrüche nun einfach mit dem HTML "br" Befehl erzeugen.

Ich hatte noch keine Zeit einen genaueren Blick drauf zu werfen, allerdings ist das Konzept erstmal so, dass man analysiert, welche Funktionen wann eingesetzt werden um was zu bewerkstelligen. (Einfach)
-> Exploit suche.

ggf. mathematische Besonderheiten von XOR verwenden - Einzelfallabhängig. Leider fehlt mir die Zeit
 
Ich bin kein Crypto-Experte und habe auch wenig Erfahrung in dem Bereich. Nichts desto trotz habe ich mir den Algorithmus mal angeschaut. Zuerst möchte ich mich über das Ausgabeformat beschweren: führende Nullen werden weggelassen, sodass es nicht möglich ist auf die echten Bytes zurückzuschließen. Ich gehe davon aus dass das nicht beabsichtigt ist, da das auch eine Entschlüsselung bei bekanntem Key verhindert.

Wenn ich mich nicht täusche sieht der Algorithmus wie folgt aus:

Verschlüsselung:
e_i = (m_i XOR s_i) + s_i
s_i = (k_i + i + 1) XOR k_i

Entschlüsselung:
m_i = (e_i - s_i) XOR s_i

* m_i ist die unverschlüsselte Nachricht
* e_i ist die verschlüsselte Nachricht
* k_i ist der Key (beliebig oft wiederholt)

Alle Operationen sind Byte-basiert, also modulo 256.

s_i enthält nur relativ wenig Information über den Schlüssel, aufgrund der verwendeten Berechnung. Es enthält die Bits, die sich bei der Addition (k_i + i) ändern. Besonders schlecht: Jedes 256'te s_i ist immer Null, da wir mit Null addieren. Das wiederum heißt, dass jedes 256'te verschlüsselte Byte gleich dem Plaintext-Byte ist.

Zur Known-Plaintext-Attacke: was können wir schließen wenn wir sowohl e_i als auch m_i kennen?

Wir kennen einige der Bits in s_i, aber nicht alle. Die Kandidaten lassen sich leicht ermitteln indem man alle 256 Kandidaten ausprobiert. Es werden mal mehr, mal weniger Kandidaten in Frage kommen. Bei dem Schritt von s_i zu k_i gehen uns noch ein paar Bits verloren. Wenn der Schlüssel kurz genug ist und wir genug Plaintext kennen, dann sollten wir trotzdem auf den Schlüssel schließen können.

Von der anderen Seite betrachtet: vielleicht müssen wir den Schlüssel gar nicht kennen. Durch die beiden XOR-Operationen sind viele der Bits vorhersagbar. Beispiele:

* wenn i + 1 = 0: e_i = m_i
* wenn i + 1 = 1: s_i hat die Form 1^i (also 0, 1, 11, 111, 1111 etc.)
* wenn i + 1 = 2: s_i hat die Form 1^i0 (also 0, 10, 110, 1110 etc.)

Ähnliche Listen lassen sich auch für die anderen Indizes berechnen. Wir können also die Kandidaten für s_i (und damit für m_i) stark einschränken. Wenn wir jetzt noch davon ausgehen dass sowohl Schlüssel als auch Plaintext sich im druckbaren ASCII-Bereich befinden verringert sich die Anzahl Möglichkeiten noch deutlich weiter. Wenn wir das jetzt noch mit der Known-Plaintext-Attacke kombinieren sollten wir schon ziemlich nah am Schlüssel dran sein.

Das reicht noch nicht ganz um den Plaintext einfach auszurechnen, aber vielleicht kann ja jemand darauf aufbauen.
 
Guten Abend.

Ich bin auch relativ neu auf dem Gebiet der Kryptographie. Daher entschuldige ich mich schonmal, falls ich jetzt hier total daneben liege.
Hier mal meine Formel zum Algorithmus:

C = ((P XOR ((K + KC) XOR K)) + ((K + KC) XOR K))
P = ((C - ((K + KC) XOR K)) XOR ((K + KC) XOR K))

P = Plaintext
K = KeyK
C = KeyCounter
C = Cyphertext

Wie du schon richtig sagst, sind alle Operationen "Byte-basierend". Verloren gehen eigentlich keine Bytes. Ich habe mal eine 5MB Datei damit verschlüsselt und entschlüsselt. Da komme ich auf die gleiche Byte Anzahl.

Ich bin dennoch sehr gespannt, ob ihr es schafft :)
 
Zuletzt bearbeitet:
Zhavok hat gesagt.:
Guten Abend.Ich bin auch relativ neu auf dem Gebiet der Kryptographie. Daher entschuldige ich mich schonmal, falls ich jetzt hier total daneben liege. Hier mal meine Formel zum Algorithmus:C = ((P XOR ((K + KC) XOR K)) + ((K + KC) XOR K))P = ((C - ((K + KC) XOR K)) XOR ((K + KC) XOR K))P = PlaintextK = KeyKC = KeyCounterC = CyphertextWie du schon richtig sagst, sind alle Operationen "Byte-basierend". Verloren gehen eigentlich keine Bytes. Ich habe mal eine 5MB Datei damit verschlüsselt und entschlüsselt. Da komme ich auf die gleiche Byte Anzahl. Ich bin dennoch sehr gespannt, ob ihr es schafft :)
Zum Vergrößern anklicken....
Um sicher zu gehen kannst du vom Plain vor und nach dem Ver-/Entschlüsselungsprozess einen Hashwert bilden. (Unter Windows geht das sogar recht einfach in der Powershell..).Ich habe ja etwas mehr theoretische Erfahrung in der Kryptographie, aber meine Zeit is running :( Mittlerweile habe ich wieder Auswärtstermine bis zum 16. November inkl. 2 Flugreisen...
 
Ich denke mal du bist aber nicht über den Ausgabetext gegangen? Das sollte nämlich unmöglich sein. Schau dir das cout-Statement noch mal an: führende Nullen werden abgeschnitten. Wir haben also in der Ausgabe keine Möglichkeit mehr, z.B. die Hex-Strings "0x0f 0xff" und "0xff 0x0f" zu unterscheiden. Beide werden als "fff" ausgegeben.

Stattdessen habe ich gerade einen anderen String "entschlüsselt", mit den Vorschlägen die ich im letzten Post gemacht habe. Durch die Schwachstellen im Crypto-Algorithmus lassen sich die möglichen Ursprungsbuchstaben recht stark eingrenzen. Diese Liste gibt Index und mögliche Plaintext-Buchstaben an. Daraus den Plaintext zu erraten ist nicht mehr schwer. Bei längeren Texten kann man auch mit recht hoher Sicherheit das Passwort erraten.

encrypted: [118, 105, 110, 108, 111, 48, 50, 135, 111, 138, 142, 132]
0 ['H', 'h', 'p', 't']
1 ['U', 'e']
2 ['L', 'P', '`', 'h', 'l']
3 ['L', 'l']
4 ['O', 'o']
5 [',']
6 [' ', ',']
7 ['w']
8 ['O', 'o']
9 ['b', 'j', 'r']
10 ['`', 'h', 'l', 'p']
11 ['d', 't']
 
Zuletzt bearbeitet:
Ich würde mich zumindest gerne mal daran versuchen. Vorher müsstest du aber die Challenge-Texte so Posten dass ich sie auch einlesen kann. Ich habe schon mehrfach versucht das Problem zu erklären. Es ist unmöglich bei deinem Ausgabeformat herauszufinden wo die Bytes anfangen/aufhören. Du könntest z.B. nach jedem Byte ein Leerzeichen ausgeben. Oder du benutzt std::setw(2) und std::setfill(‚0‘) damit alle Bytes immer durch zwei Zeichen dargestellt werden.
 
meinst du so?

4a 6f 70 74 3e 89 7b 75 3e 5b cd 69 8c 7a 81 79
7b cc 91 8e 4a 6b a2 a0 ae 75 98 a8 7d 6f 75 a0
6e 65 78 65 b6 6e 6f d0 77 6f 6f 84 c6 72 85 81
73 8f 90 c9
 
Um antworten zu können musst du eingeloggt sein.
Zurück
Oben