128 Bit Verschlüsselung proggen
-
@ p84
sorry kann sein das ich mir was falsch gemerkt hab. werd mal nachlesen. bei irgendeinem system ist das aber so. werd mal nachschauen.
@ monsterbacke
aus den beiden texten den schlüssel zu generieren ist meist schwer bzw bei guten algorytmen fast unmöglich (wer weis schon was die zukunft alles bringt). da interessierts auch nicht ob du das verfahren kennst oder nicht. (das verfahren nent sich glaub plaintext analyse. gute algorithmen halten gegen so ein verfahren stand)
kennst du den chifretext und den algorithmus ( annahme er hat wieder keine hintertüren oder irgendwelchen unsicheren sachen ) bleibt nur ne brouth forth atack ( wahlloses ausprobiern mit sämtlichen schlüsseln) die ergebnisse kann man dann anhand von zeichenhäufigkeiten auf echtheit prüfen ( meist weis man ja auch in welcher sprache der text verfasst wurde )
soweit ich mich errinern kann braucht man für ne plaintext analyse nicht umbedingt den kompletten orginaltext meist reichen teile schon aus ( aufbau des schreibens, begriffe die darin zwingend vorkommen, Namen, Orte, aussehen des priefpapiers fals verschlüsseltes fax) machen manche geheimdinste. falschmeldung ner botschaft mitteilen, und die nachricht die sie verschicken abfangen.
junjor Quark ? gruss termite
[ Dieser Beitrag wurde am 31.07.2002 um 09:55 Uhr von Termite editiert. ]
-
Hi
Original erstellt von <monsterback>:
**(Mir ist kein anderer Nick eingefallen
Oder anders. Ich habe den orig. und den verschlüsselten Text. Ist es mir damit möglich, den Schlüssel oder das Verfahren zu reproduzieren?
.**
Nun ja in dem Fall brauchst du das Verfahren nicht zuknacken,du hast ja den Plaintext. Wenn Du teile des Plaintextes hast ist das ein Vorteil. Den Kannst du dann in weiteren Analysen verwenden.(Differentiele Kryptoanalyse). Die Sache ist die Du kannst bei den Meisten verfahren nicht einfach deinen Plaintext mit verschiedenen Schluesseln verschluesseln und das ergebnis mit dem ciphertext(Schluesseltext) vergleichen. Da nicht jedes Plaintextzeichen auf ein Ciphertextzeichen abgebildet wird. Das ist wichtig denn sonst kommt man mit statistischen Analysen sehr schnell zum Ergebenis. Die heutigen Algorithmen lassen solche Analysen scheitern. Versteht mich jetz nicht falsch. Es kann dich weiterbringen den Plaintext zuverschluesseln. Aber du bekommst kein Ergebnis wie:
Plaintext : abcde
Ciphertext(original von abcde): &%$§"Ciphertext(von Plaintext): &%$§
Wo du dann sagen koenntest: Aha a wird auf & abgebildet oder d wird auf $ abgebildet. So ist es nicht. Es kann sein das a auf &,? oder ! oder irgend ein anderes Zeichen jeweils zufällig abgebildet wird.
Ich hoffe das war einigermaßen verständlich. Wenn du Interesse an dem Thema hast. Schau mal bei dem allseitsbeliebten Suchautomaten google unter Kryptoanalyse,RSA,Diffie Helman,Rjindal oder fuer einfachere Sachen rot13,CAESAR usw. Dann bekommst du schon mal eine guten Einblick. Achso die Uni Kassel hat auf ihren Seiten ueber diskrete Mathematik auch was interessantes rumliegen. Die Forschen da in einer Arbeitsgruppe an Eliptic Curve Cryptographie; Sehr interssant.
?:-Gruß(X)
X=Prolog
-
Wenn jemand glaubt, einen unknackbaren Verschlüsselungsalgo. entwerfen zu können, dann hat der meiner Meinung nach keine Ahnung von der Materie oder er ist wirklich ein Genie.
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.
-
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