[HaBo]

jmc

Anzeige

Hallo,

Ich wollte fragen, ob der Schlüssel der Dateien im Anhang leicht herausgefunden werden kann. Es ist jeweils die Originaldatei und dazu noch die verschlüsselte Entsprechung.
Als zweites möchte ich gerne noch wissen, wie ich eine Datei als verschlüsselt markieren könnte ohne in die Datei zu schreiben.

Vielen Dank für die Antworten.

Angehängte Dateien

	file1.txt (26 Bytes, 34x aufgerufen)
	file2.txt (26 Bytes, 11x aufgerufen)
	file1_encrypted.txt (38 Bytes, 30x aufgerufen)
	file2_encrypted.txt (38 Bytes, 12x aufgerufen)

Mechanius

ich hab auf dem Gebiet zwar nur wenig Ahnung aber bei der länge deiner Information könnte ich mir vorstellen das dein Schlüssel gleichlang wenn nicht sogar länger als die Nachricht ist und wenn das der Fall ist denke ich ist der Schlüssel nur sehr mühsam zu finden

Elderan

Hallo,
achja, mal wieder einer dieser Threads.
Bitte die Suchfunktion nutzen, hier gabs schon diverse Themen rund um selbst geschriebene Algorithmen.


Kurz gefasst: Du kannst deinen Algorithmus, sofern selbst entwickelt, vergessen. Bietet keinen Schutz.
Warum dein Bytestring für den Arsch ist

Deswegen, bitte die SuFu nutzen, wurde hier schon diverse mal diskutiert und es kommt immer das selbe dabei herum.

jmc

Der Schlüssel ist in diesem Fall 11 Zeichen lang.

Die Suchfunktion habe ich schon benutzt, aber ich wollte insbesondere auch sehen, ob es jemandem gelingt den Schlüssel zu erhalten.
Um dem der es versucht zu helfen habe ich deswegen sowohl die verschlüsselte Variante, als auch die entschlüsselte geschrieben. Bei zwei verschiedenen Strings mit dem selben Schlüssel verschlüsselt.
Die Anzahl wichtiger Zeichen bei der Ausgabe entsprechen der Anzahl Zeichen bei der Eingabe.
Dass jeder selbst gemachte Algorythmus schlecht sein muss ist ja wohl auch nicht sicher.
Ausserdem ist es eine Erweiterung von rc4 und rc4 ist bereits nicht sehr einfach zu knacken.

Mechanius

@Elderan warum kann er seinen Algorithmus vergessen das kapier aufgrund der von dir verlinkten Diskussion nicht, sorry.

jmc

Ich glaube er hat in einem früheren Beitrag einmal geschrieben es sei eh niemand hier im Forum intelligent genug für einen guten Algorithmus oder so.

zero-9

was bist denn du für ein troll?

hast dud ir den link mal angeschaut? es geht darum, dass man keinen string der welt entschlüsseln kann, sofern man nichtmal weiss, womit man es zu tun hat.
es wäre sinnvoller, wenn du deinen algorithmus öffentlich machen würdest. denn dann könnte man dir sagen, wo du ausbessern kannst und wo nicht.
indem du hier deine dateien reinsetzt und nicht den algo veröffentlichst, setzt du auf "security by obscurity". und da ist die sicherheit nunmal nur eine frage der zeit und der motivation.

Elderan

Hallo,
naja mit Intelligenz hat das nicht unbedingt etwas zu tun. Einstein hätte auch keinen sicheren (nach heutiger Definition) Algorithmus schreiben können.
Aber ansonsten gibts hier im Forum sicher keinen, der soetwas kann.

Ansonsten Themen aus der SuFu:
Wie programmiere ich einen Algorithmus
Eigene verschlüsselung sicher!?

Oder ein älterer Thread (mit 101 Antworten)
Neues Verschlüsselungsprogramm (selbst gecodet)

Wer nur einen bytestring postet (bzw. Klartext-Geheimtext Paare), wird keine Ahnung auf dem Gebiet haben (ist nichts persönliches gegen jmc).
Und wer keine Ahnung auf dem Gebiet hat, wird keinen ansatz sicheren Algorithmus schreiben können.

Soweit nachvollziehbar, oder?


Um einen Algorithmus zu entwerfen, der evt. sicher ist, muss man Jahre sich eingehend mit Kryptographie beschäftigen.
Ein Studium der Mathematik ist schon fast pflicht, man muss alle aktuellen kryptoanalytischen Ergebnisse kennen und beweisen können, dass der Algorithmus dagegen sicher ist. Zum Beispiel kann man beweisen, dass Algorithmen absolut sicher gegen die einfachere Variante der differentiellen Kryptoanalyse sind und man deswegen davon ausgeht, dass dieser sicher auch gegen erweiterte Angriffe mittels differentielle Kryptoanalyse ist.


Ich bezweifel einfach mal, dass der Algorithmus von jmc, sofern er ihn selbst entworfen hat, auch nur den simpelsten Tests wiedersteht.


Einen Algorithmus, der evt. sicher ist, zu entwerfen, dass können extrem wenige Personen. Es gibt erheblich mehr Leute (um den Faktor 1000, 10k, 100k?) die Treiber für Linux programmieren können als Experten, die evt. sichere Algorithmen entwerfen können.
Selbst diese Experten machen dies nicht in einer Woche. Meistens, sofern es notwendig ist, setzen sich mehrere (echte) Experten zusammen und stecken sehr sehr viel Zeit in den Entwurf des Algorithmus.

Twofish wurde z.B. von 6 wirklichen Experten (Bruce Schneier, Niels Ferguson, John Kelsey, Doug Whiting, David Wagner und Chris Hall) entwickelt. Diese haben ihn dann 9 Monate später beim NIST eingereicht, damit dieser von einer unglaublich hohen Anzahl an Personen, mit vielen Experten, eingehend für mehrere Jahre untersucht werden konnte.

Deswegen wird es hier im Board (leider) keinen gegen, der auch nur einen halbwegs sicheren Algorithmus selbst entwerfen kann.


Achja, und wie wirkliche Experten einen Algorithmus vorstellen, lässt sich im Twofish paper ansehen.
Dort wird nicht einfach ein Klartext - Geheimtext Paar veröffentlicht mit dem Aufruf das zu knacken, auf wird nicht einfach nur ein Quellcode in C veröffentlicht.

Was alles notwendig ist, damit ein Algorithmus evt. sicher ist, lässt sich an dem Paper gut entnehmen? Und wer ist in der Lage einen Algorithmus auf diese Sachen zu untersuchen bzw. Abschätzungen über die Entwicklung der Kryptoanalyse zu treffen?

Und nur weil man so ein tolles Paper veröffentlicht und die darin gemachten Untersuchungen anstellt, heißt dies nicht, dass der Algorithmus auch sicher ist, wie man es am Fall Magenta gesehen hat

jmc

Ich hätte es vieleicht etwas genauer formulieren müssen, aber ich wollte in diesem Thread insbesonder fragen, ob jemand einen möglichen Schlüssel findet (nur für diese zwei Vorgaben und es dürfen maximal 32-bit Blöcke sein).
Es geht auch nicht darum den Schlüssel, sondern einen Schlüssel zu finden. Bei praktisch jeder Verschlüsselung (ausser z.B. bei one-time pad) gibt es ja mehr als einen Schlüssel. Noch mehr gibt es natürlich bei so kurzen Strings ohne Algorithmus.
Die Links, die du gepostet hast Elderan kannte ich schon (mit Ausnahme des twofish papers, aber den Algorithmus dort kenne ich auch bereits).
Wir habe keine Jahre für die Verschlüsslung gebraucht, aber immerhin ca 2 Monate Entwicklung und einen Monat Cryptanalysis bis anhin.

Die Verschlüsselung ist, wie ich heute Abend von einem Kollegen erfahren habe, sehr wahrscheinlich relativ sicher, denn ein Teil davon entspricht beinahe der ISAAC Verschlüsselung.
Niemand von uns kannte ISAAC vorher und wir haben das deswegen nie realisiert. Wir hatten eigentlich nur die Absicht RC4 besser gegen einen KPA zu schützen.

Falls es noch jemanden interessiert, werde ich den Algorithmus hier reinstellen, sobald er noch etwas besser ausgereift ist und noch ein paar Tests durchgeführt worden sind.

menace

Es ist schon mal eine ganz andere Sache, wenn man auf bestehenden Strukturen aufbaut, das sollte man statt so einem hingeklatschtem Text, das zur KnownPlainText-Attacke halt nicht ausreicht schon sagen.
Ausserdem.. "relativ" sicher.. ich kann auch einen Algorithmus nach der Art des DES machen, der unsicher ist. Ich wähle halt zufällig leider lineare Substitutionsboxen.
Wenn ihr Angriffe drauf fahrt und Erfolgsquoten habt, würde man (ich zb) schon eher drauf ansetzen, ob man das "Loch" evtl noch ausweiten kann. Dann würde man das auch ernster nehmen.

Deswegen mag ich hier auch mal auf https://www.buha.info/board/showthread.php?t=27119 hinweisen.

Wenn ihr die Analyse anderer und ernst genommen werden wollt, dann macht es ihnen so leicht wie möglich, ansonsten interessiert es sowieso nicht.

jmc

Leute, die das Design des Algorithmus analysieren haben wir genug und ich habe auch nicht darauf gehofft jemanden hier anzutreffen, der die Zeit dazu hat.
Wie gesagt ich war nur auf der Suche nach jemandem, der Lust und Zeit hat eine KPA durchzuführen, denn solche Lösungsversuche, auch bei so kurzen Strings, können Zusammenhänge aufzeigen, die zuvor nicht einberechnet wurden.

menace

Was ist es denn bitte anderes als Kryptanalyse, wenn man eine KPA durchführt?
Und ohne jetzt eine KPA durchgeführt zu haben, aber ...
das ist, entschuldige ein bisschen die Wortwahl, Bockmist. Wenn ihr euer Design auf RC4 aufbaut, und dann bei kaum 30 Byte schon Zusammenhänge erkenntlich werden, habt ihr das Design mehr als nur verhunzt. Das hättet ihr so derbe gegen die Wand gefahren, dass das u.U. schon im Pseudocode zu sehen ist.

Irgendwie ist mir deine Intention nicht so ganz klar. Entweder Hosen runter oder es lassen. Das wurde doch jetzt schon in vielen Boards und Newsgruppen zur Genüge durchgekaut.

jmc

Eine Kryptanalyse muss, wenn ordentlich durchgeführt sehr viel weiter gehen als eine KPA und bei einem Schlüssel von 11 bytes gibt es bei stream ciphers bei denen zur initialisierung alle bytes verwendet werden auch bei 12 bytes schon Zusammenhänge.
Die mögen nicht klar ersichtlich sein, können aber in der Kryptanalyse benutzt werden.
Zusätzlich entstehen durch den Aufbau des algorithmus noch weiter zusammenhänge zwischen Schlüssel und Plaintext. Dazu kann ich dir den Aufbau vieleicht etwas genauer darlegen, wir werden aber den algorithmus nicht veröffentlichen bevor er weiter getestet worden ist. Ich hoffe du hast Verständnis dafür, wie auch ich Verständnis dafür habe, dass du keine KPA machen willst ohne den Algorithmus. Hier noch eine Pseudobeschreibung des Algorithmus:

Elderan

Hallo,

hey, ich habe einen Schlüssel gefunden: ABRAKADABRA
Mit EUA ('Elderans Unbreakable Algorithm') bekomm ich aus den Geheimtexten direkt die Klartexte 'abcd...xyz' bzw. 'ABC...XYZ' herraus.
Wahnsinn!


Das hat leider nichts zu bedeuten.

Hätte man DES mit zufälligen S-Boxen ausgestattet, dann wäre DES sehr wahrscheinlich unsicher geworden, selbst wenn man nicht den Worst-Case von linearen S-Boxen erwischt.

Dieser kleine Unterschied, zufällige S-Boxen gegen speziell gewählte S-Boxen, machen den Unterschied aus, ob ein Algorithmus sicher oder unsicher ist. Selbst eine falsch gewählte SBox kann katastrophale Auswirkunden haben.

Deswegen reicht es nicht aus, sich an bekannten Algorithmen zu orientieren. Gut, einen reihnen Ciphertext Angriff wird man dann hoffentlich nicht mehr durchführen können, aber gegen alle anderen Attacken bringt das meistens relativ wenig Schutz.
Bei Algorithmen muss das Gesamtkonzept stimmen und es reicht nicht aus, irgendwelche Bestandteile von anderen Algorithmen zu übernehmen.
Das macht ja die ganze Angelegenheit so schwierig.


Es wäre schon sehr fatal, findet man bei eine Stromchiffre irgendwelche Zusammenhänge bei so kurzen Strings.


Eine Stromchiffre gewinnt ihre Sicherheit daraus, dass der Keystream nicht von einer (absolut) zufälligen Quelle unterschieden werden kann.
Deswegen, wenn man Stromchiffren analysiert, analysiert man eigentlich niemals Plain-Ciphertext Paare (oder nur Ciphertext) sondern immer den Keystream.
Macht auch keinen Sinn Plain-Ciphertext Paare zu analysieren, denn Ciphertext XOR Plaintext = Keystream.

Ansonsten sind Stromchiffren meistens erheblich schwieriger zu analysieren als Blockchiffren, was unter anderem dazu führt, dass eher selten noch irgendwelche Stromchriffren heutzutage benutzt werden.
Wenn man die Charakteristik einer Stromchiffre benötigt, dann greift man oft auf Blockalgorithmen (z.B. AES), die man dann im z.B. Counter Modus betreibt. Hat auch den Vorteil, dass man den selben Key häufiger verwenden kann, sofern eine Nonce im Spiel ist.
In eingebetteten System, z.B. RFID Chips, Smart Cards o.ä., findet man aber weiterhin oft noch Stromchiffren, da sich diese oft gut, einfach und vorallem günstig über Schieberegister realisieren lassen (je nach Algorithmus/Design). Das sind aber dann entsprechend wirtschaftliche bzw. technische Gründe.


Deswegen sollte man, sofern man den Algorithmus untersucht, den Keystream untersuchen.
Das erste was einem dazu einfällt, ist die FIPS Testbox bzgl. zufälligkeit (im verlinkten Thread schon beim Random Oracle Model beschrieben).
Damit kann man die ersten Tests machen, wie der Keystream so ist bei bestimmten schwachen Schlüsseln, bei verwandten Schlüsseln etc.
Wenn eure Chiffre bei z.B. einem 8 Bit Key keinen zufälligen (nach FIPS Testbox) Keystream generiert, dann ist diese unsicher und so nicht verwendbar.

Mir fallen dazu extrem viele Tests ein (man muss bei der Kryptoanalyse eben etwas kreativ sein), wie man Keystreams variieren kann und diese dann alle die FIPS Testbox bestehen müssen, um im Ansatz als evt. sicher betrachtet zu werden.


Ansonsten, wenn ihr schon soviel Arbeit reingesteckt habt, warum veröffentlicht ihr das nicht?
Wie du am Twofish Paper siehst, ist nicht die Beschreibung des Algorithmus (aus deiner Beschreibung werde ich nicht schlau) das wichtige, sondern eben die selbstangestellten Analysen, wie verhält sich der Algorithmus gegen xyz, wodurch wird dieses erreicht etc.





PS: ISAAC orientiert sich selber sehr stark an RC4, mit dem großen Unterschied dass ISAAC entweder 32 oder 64 Bit Wörter generiert, während RC4 nur 8 Bit / ein Byte Wörter generiert.
ISAAC eignet sich dementsprechend sehr gut, um schnell Zufallsdaten o.ä. auf 32/64 Bit Architekturen zu erhalten.

Mechanius

@Elderan: Danke für den ausführlichen Post .
Ich hab nach deinem ersten Post gemeint du könntest nur aufgrund dieser mageren Informationen auf den Algorithmus kommen und diesen dann sofort als unsicher widerlegen, jetzt verstehe ich langsam das die Anforderungen an einen möglicherweise sicheren Algorithmus einfach zu hoch sind.

MfG Mechanius

edit: Wenn ich mich in diese Materie einarbeiten wollte hättet ihr nen Tipp wo man da beginnt?