128 Bit Verschlüsselung proggen
-
Hi
Jo. Stimmt hatte ich vergessen. Ist aber unpraktisch!
Trotzdem hast recht, es gibt ein doch ein Theoretisch unknackbares Verfahren.Gruß Prolog
-
Hi
@KingRuedi
Ja natuerlich muss man sein Verfahren auf Herz und Nieren pruefen lassen. Ist ja besser wenn man einen Fehler im Vorhinein sieht und dann später nicht diese Erfahrung machen muss, wenn es um was geht.
Aber wenn einer eine gute Idee hat und seinen Algo- veroeffentlicht,dann gibt es da glaube ich, genug Leute, die sich das mal anschauen und ein oder zwei Experten sollen sich ja auch im Internet rumtreiben
Aber so ist es doch bis jetzt mit jedem neuen Verfahren gewesen. Also, wie gesagt. Nur Mut dem jenigen, der es versuchen moechte. Ich wuerds nicht. Aber ich muss zugeben dass ich mir auch shon einige Nächte um die Ohren geschlagen habe, weil ich dachte das Faktorisierungsproblem kann doch nicht so schwer sein. Hatte dann aber Albträume von primen Restklassen. 
Naja vieleicht mach ich irgendwann mal weiter.Gruß Prolog
-
**"Der Triple DEA wurde erstmalig 1985 mit dem ANSI-Standard X9.17 zur Verwendung in Finanzprogrammen standardisiert. Seit der Veröffentlichung des FIPS PUB 46-3 1999 stellt TDEA ein Teil des Encryption Standard dar.
TDEA verwendet drei Schlüssel und drei Durchläufe des DES-Algorithmmus. [...] Darüber hinaus vereitelt die Schlüssellänge von 168 Bit jeden Brute-Force-Angriff"**
(W.Stallings Addison-Westley 2001DES, AES, TDEA ... Ich musste hier 3 Angriffe abwähren, was ist denn los ...
Du kannst natürlich auch alle 2-3 Schüssel abgleichen
Nix für Ungut
P84
[ Dieser Beitrag wurde am 30.07.2002 um 22:57 Uhr von Prof84 editiert. ]
-
(Mir ist kein anderer Nick eingefallen
Ich habe diese Beiträge mit Interesse gelesen, aber so richtig verstanden habe ich sie nicht (so ganz).
Also, ich habe einen verschlüsselten Text. Wie müßte ich vorgehen, um diesen zu entschlüsseln?
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?
Oder liege ich mit meinen Ansätzen völlig daneben? Bitte eine verständliche Erläuterung (bin kein Mathematiker).
-
@ 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 eingefallenOder 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.