128 Bit Verschlüsselung proggen
-
Original erstellt von tenim:
hey, ich hab einen wirklich unknackbaren algorythmus entworfen und implementiert ! ist ganz einfach: ich hab statt eines keys eine datei die ich zum veschlüsseln benutze. die sollte mehrere mb haben und im idealfall >=der zu verschlüsselnden datei sein. so addiere ich einfach jedes byte der quelldatei mit jedem der zeildatei und fertig.
weil die schlüssellänge nicht bekannt ist kann man das ding auch nicht knacken.Klar, das geht.
Aber die Angriffe sind ja die:
Der ANgreifer hat das Chiffrat eh vorliegen.
Der Angreifer kriegt zufällig oder duch Bestechung oder Menschenraub mit Erpressung auch einen Klartext.
Mit Chiffrat und Klartext zusammen kann er Deinen Schlüssel berechnen.
Ab jetzt kriegt er alles übersetzt.Und nu gibts auch Dinger, wo sogar dieser Plaintextangriff Jahrhunderte der Rechenzeit kostet. Die sind einfach Klasse.
-
ja, aber im "normalfall" (ohne folter u.s.w.) hat er nur die verschlüsselte datei und kann daraus nichts ableiten, weil er durch die variable schlüssellänge mehrere sinnvolle lösungen erhält und dann nicht weiss welche die richtige ist. :p
[ Dieser Beitrag wurde am 01.08.2002 um 14:20 Uhr von tenim editiert. ]
-
deine Verschlüsselung kann man doch ganz leicht knacken über eine heufigkeits Analyse. Das war schon vor über 1000 Jahren kein Problem.
-
dann zeig mir mal wie. ich hab eine zeichenkette die ich verschlüsseln will: "das haus ist gross". ich addiere dann z.b. bytes aus einer beliebigen anderen datei(keydatei) dazu (z.b. eine mp3-datei weil die komprimiert ist und es kaum zeichenketten mit gleichen bytes gibt). du hast nur das ergebniss z.b. "4t2ß+~3<´22öÖÖ12". wenn du alle möglchen kombinationen von keydateien durchprobierst dann kommst du auf ALLE möglichen lösungen dieser satzlänge. also auf "heut geh ich baden" oder "autos sind schnell" und auch auf "das haus ist gross". aber woher willst du wissen WELCHE nachricht die richtige ist????
-
Oh, ich hatte dich wohl erst nicht richtig verstanden.
Naja so ist deine Lösung aber unpraktisch, wie das One Time Pad Verfahren.
-
Aber wenn ich 100 Deiner so verschlüsselten Mails zu lesen kriege, dann kann ich jede Stelle einzeln analysieren und den key finden.
-
ja sie hat den nachteil das keine checksumme mitgespeichert wird (währe sonst eine möglichkeit mit brute force ranzugehen) und deshalb der richtige empfänger nicht 100%ig sicher sein kann das die datei korrekt decodiert wurde.
ja, wenn ich immer den selben schlüssel nehme dann vielleicht.
-
In der Umsetzung hat deine Verschlüsselung viele Probleme
1. Key Verteilung - Man müsste theoretisch unmengen an Schlüsseln mit einer riesigen Länge erstellen und dann sicher verteilen können
2. Key Generierung - Man müsste ein 100% zufälliges Verfahren zur Herstellung der Schlüssel benutzen
-
Was haltet ihr von Stenografie?
Ist praktisch unknackbar, solange man die Textposition nicht
kennt...Devil
-
solange man die nicht kennt
Naja Stenographie ist eigentlich nicht schlecht.
-
@kingruedi
keygenerierung ist kein problem: mach ein foto mit einer digitalkamera von irgenwas und schon hast du deinene key.
aber sonst ist diese variante natürlich nicht geeignet um produktiv eingesetzt zu werden.
-
@tenim: Die Schlüsselerzeugung ist sehr wohl ein Problem und bestimmt nicht so einfach, wie Du meinst! Nach Möglichkeit sollten nur zufällige Bits in den Schlüssel einbezogen werden. Dein Verfahren ist IMHO nicht zufällig genug.
Wenn Dein Algo nur dann sicher ist, wenn keine weiteren Informationen (Schlüssellänge, Plaintext) dem Angreifer vorliegen, ist deine Methode nicht schrott. Geh' mal von dem Ansatz aus, das der Angreifer alles außer dem Schlüssel haben kann. Wenn er dann immer noch nichts über den Plaintext erfährt, dann ist Dein Algo gut. Alles andere ist Spielzeug.
-
Original erstellt von mady:
**
Geh' mal von dem Ansatz aus, das der Angreifer alles außer dem Schlüssel haben kann. Wenn er dann immer noch nichts über den Plaintext erfährt, dann ist Dein Algo gut. Alles andere ist Spielzeug.**Den hatt er dann doch schon. Wenn man Plaintext und Chiffretext hat und das Verfahren kennt, kann man sich den Schlüssel ja bruteforcen. Bei One-Time-Pads muss halt sichergestellt werden, daß kein Unbefugter etwas mit dem Schlüssel verschlüsseln darf, sonst ist es wirklich Mist. Mit ciphertext-only kann wirklich niemand was anfangen. Bei den Russen hat das doch auch geklappt.
-
hi
aprobo bild, da fällt mir grad was ein
man nehme ein bild, das beiden bekant ist, und beide im ursprünglichen format haben, manipuliere nun die farbwerte des bildes anhand des plain textes ein wenig und verschike diese bild als atatchment in einer ganz harmlos anmutenden mail. z.B. "schau mal hier, mein neues auto/ haus / pferd/ ,..... ." ist natürlich so ne art one time pad. da aber derjenige der die mail ebfängt nicht weis das sich im bild die nachricht versteckt. steigerst du daduch nochmal etwas die sicherheit.
man könnte auch die bilder auf irgend nen webserver legen und derjenige holt sich dann die bilder ausem netz. abe sowas is etwas zu aufwendig für normale verschlüsselte kommunikation
gruss termite
-
Original erstellt von Doktor Prokt:
Den hatt er dann doch schon. Wenn man Plaintext und Chiffretext hat und das Verfahren kennt, kann man sich den Schlüssel ja bruteforcen. Bei One-Time-Pads muss halt sichergestellt werden, daß kein Unbefugter etwas mit dem Schlüssel verschlüsseln darf, sonst ist es wirklich Mist. Mit ciphertext-only kann wirklich niemand was anfangen. Bei den Russen hat das doch auch geklappt.Ich trau der Geschichte nicht ...
Ein One-Time-Pad muss aus lauter zufälligen Bits bestehen. Wenn er jetzt ein bild nimmt, ist das nicht zufällig. Bestimmte Bereiche haben gleiche Farben usw. Wenn er ne *.exe z.B. nimmt hat auch diese Datei eine Struktur. Eine Text-Datei besteht zum großen Teil aus ASCII-Codes < 128. Jede 'scheinbar' zufällige Datei hat ihre Probleme ....
-
@mady
Dann nimmt er eben kein Bild aus der Natur, sondern einen kubischen Kongruenzgenerator mit einer hohen Periode. Die Nachrichten sollten dann nach Möglichkeit nicht länger sein als die Periode. Und über den Startwert sollte man sich auch unterhalten
-
falsch,mien jung -bei mir sind die daten zufällig weil ich bei der gewählten datei die header ausblende (z.b. .exe) und nur den datenbereich der datei zum verschlüsseln nehme der immer anders ist. und ein .jpg-bild ist schon sehr zufällig weil jedes digitalfoto das du machst andere daten liefert und die gleichen farbbereiche die auftreten sind in der .jpg-datei wegen kompression nicht mehr erkennbar. :p
-
Das läuft aber dann in Richting Stromchiffrierung, oder ?? Dann sollte der Startwert auch jedes Mal anders (zufällig?!?) sein. Aber sind diese Kongruenzgeneratoren auch sicher??? Für Simulationen würde ich das ja noch akzeptieren, aber für Kryptographie ....
Und für Datenübertragung ist das ganze dann sowieso nicht mehr geeignet ... :))
[ Dieser Beitrag wurde am 02.08.2002 um 10:08 Uhr von mady editiert. ]
-
Original erstellt von tenim:
**@madyfalsch,mien jung -bei mir sind die daten zufällig weil ich bei der gewählten datei die header ausblende (z.b. .exe) und nur den datenbereich der datei zum verschlüsseln nehme der immer anders ist. und ein .jpg-bild ist schon sehr zufällig weil jedes digitalfoto das du machst andere daten liefert und die gleichen farbbereiche die auftreten sind in der .jpg-datei wegen kompression nicht mehr erkennbar. :p**
Also für mich sind bekannte (=festgelegter Befehlssatz) Maschinencodes einer ausführbaren Datei nicht zufällig.... Erst, wenn sich der Schlüsselstrom nicht reproduzieren lässt, könnte das funktionieren....
-
mal was anderes. kann man nicht auch den schlüsselraum von aes oder anderen neueren chiffren in kurzer zeit komplett durchsuchen indem
man spezielle hardware auf röhrenbasis baut (die arbeiten doch im Ghz-bereich) und genügend parallel betreibt. röhren kosten auch nicht so viel nur der stromverbrauch und die ausfallsicherheit ist nicht ohne.
oder ist das komplett unmöglich ?