Zitat:

---

Wer sich sowas richtig gut machen möchte, nimmt aus dem Radio rauschen auf, digitalisiert es als WAV, editiert die Header-Informationen aus der Datei, und speichert das z.B. als .bin.

---

Ich denke, daß der Fehler durch den beschränkten Frequenzgang und die schlechte Digitalisierung so groß ist, daß sich mit derartigem "Rauschen" keine sichere One-Time-Pad Verschlüsselung bauen lässt.

Zitat:

---

Eine Kopie davon bekommt der Empfänger.

---

Genau das ist der Knackpunkt.
Wenn Du dem Empfänger den Schlüssel so übermitteln kannst, daß niemand ihn abfangen kann, kannst Du ihm auch die unverschlüsselte Nachricht schicken, dann ist Dein Übertragungskanal nämlich sicher

Grüße
Malte

Zitat:

---

Original geschrieben von hybrid

Zitat:

---

Wer sich sowas richtig gut machen möchte, nimmt aus dem Radio rauschen auf, digitalisiert es als WAV, editiert die Header-Informationen aus der Datei, und speichert das z.B. als .bin.

---

Ich denke, daß der Fehler durch den beschränkten Frequenzgang und die schlechte Digitalisierung so groß ist, daß sich mit derartigem "Rauschen" keine sichere One-Time-Pad Verschlüsselung bauen lässt.

---

Wird bei der NSA so gemacht
Warum auch nicht? Du brauchst ja nur ein völlig zufälliges Bitmuster. Du kannst auch 10 trillionen mal eine Münze werfen: Kopf = 0, Tahl = 1, und das aufschreiben. Hauptsache, es wird nicht so erzeugt, dass ein wiederkehrendes Muster erkennbar ist.

Zitat:

---

Eine Kopie davon bekommt der Empfänger.

---

Genau das ist der Knackpunkt.
Wenn Du dem Empfänger den Schlüssel so übermitteln kannst, daß niemand ihn abfangen kann, kannst Du ihm auch die unverschlüsselte Nachricht schicken, dann ist Dein Übertragungskanal nämlich sicher



Wieso? Ich gebe Dir persönlich 500 solcher Kopien heute in die Hand, und die nächsten 500 Nachrichten (morgen) verschlüssele ich dann sicher. Ich habe also ein mal einen sicheren Kanal genutzt, der recht aufwändig ist (ich fahre persönlich hin), um danach n mal einen sicheren Kanal mit geringerem Aufwand zu haben.

Das ist natürlich genau nicht das Public-Key-Gedöns, klar.

So, nachdem ich meinen Fred nun einige Zeit "im Stich" gelassen habe, melde ich mich hiermit wieder zurück.

Ich habe, während ich über die Problematik nachgedacht habe, einen neuen Ansatz gefunden.
Nun meine Frage an euch "Krypto-Freaks" (nicht persönlich nehmen).

Wie sieht die Sicherheit meines Verfahrens aus, wenn ich nach dem Vorbereiten der Daten, aber vor dem Verschlüsseln im Bild zusätzlich noch einmal mit dem selben Schlüssel einen Cäsar, oder ein ähnliches, einfaches Verfahren (auf Bitebene) drüberlaufen lasse?
Das hätte die Folge, dass mein Ursprungstext wegen der Kompression auf eine kleine Änderung empfindlich reagiert ...

Und nun nochmal wegen der Chosen-Plaintext-Attacke: mein Schlüssel ist in der Standartausführung einzigartig und ohne Wiederholungen.

Sprich, meine Anweisungen lauten:

X-Wert;Y-Wert;Farbe;Ebene

5;9;2;1
12;49;0;2;
23;16;1;1;
...

Wenn ich jetzt herausgefunden habe, dass mein Plaintext an dieser Stelle 010 heißt, bringt mich das keinen Meter weiter, weil ich nämlich nicht weiterverfolgen kann, wie die Daten als nächstes aussehen.
Und ich werde durch dieses "Fenster" auch in Zukunft nur das sehen, was in diesem Bereich gespeichert ist, evtl sogar nur Zufallsdaten!
Und schließlich werden die gewonnenen Daten nutzlos sein, da aufgrund der verwendeten Kompression wesentlich mehr Informationen benötigt werden, um den Teil wieder zu entpacken.
Und da eine Kompression (soweit ich weis) bei (fast) jeder Dateikonstellation komplett anderst aussieht, dürfte es schon schwer sein, einen Known-Plaintext zu erhalten ...

mfG

Markus

PS: Ich nehme mal an, dass die Hälfte von dem was ich geschrieben habe, auf falsche Gedanken und Annahmen beruht, also korrigiert mich in diesen Teilen, wenn was nicht in Ordnung ist DANKE!!

Zitat:

---

Original geschrieben von MarkusJ

Wie sieht die Sicherheit meines Verfahrens aus, wenn ich nach dem Vorbereiten der Daten, aber vor dem Verschlüsseln im Bild zusätzlich noch einmal mit dem selben Schlüssel einen Cäsar, oder ein ähnliches, einfaches Verfahren (auf Bitebene) drüberlaufen lasse?

---

Das nennt man "Überschlüsseln". Natürlich erhöht das den Aufwand für für die illegale Entschlüsselung um den Aufwand für diesen zweiten Schlüssel. Das ist wie beim Bank-Safe: Da kann man auch 3 Safetüren hintereinander machen. Solange die Einbrecher genug Zeit haben, hindert das nicht am Einbruch. Die nächste Frage ist, ob 2 hintereinandergeschaltete Safetüren gleicher Bauart auch doppelt so lange brauchen, wie eine. Je nach Ansatz kann die zweite Tür wesentlich schneller zu knacken sein, wenn man die Erste geschafft hat (Erfahrung, entschlüsselter Algorythmus usw.)

Besser ist es immer, die eine Tür derart Einbruchsicher zu bauen, dass hier der Versuch schon nicht lohnt. Beispiel der Enigma: Hier wurden manche Nachrichten auch überschlüsselt, z.B. wurden bereits mit 3 Scheiben verschlüsselte, allgemeine Nachrichten nochmals mit einem 4-Scheiben-Schlüssel überschlüsselt, um sie an die U-Boote zu übermittlen. Die Briten hatten dann einmal das 3-Scheiben Kryptogramm, und dann noch das gleiche, mit 4-Scheiben verschlüsselt. Das half beim Herrausfinden des 4-Scheiben-Codes genauso gut, als hätten sie den Klartext gehabt.

Hallo @ all

nachdem ich mich nun einige Zeit "schlaugelesen" habe, bin ich mir recht sicher, dass mein Verfahren sicher ist.
Weiter oben im Thread schrieb jemand, (ich glaub es war Andreas Mueller) dass eine kleine Schlüsseländerung eine große Änderung im Chiffrat erzeugen muss ...
Nun, das gilt für den Fall, dass es für ein Chiffrat genau einen richtigen Schlüssel gibt ... was ist aber wenn es mehrere möglich richtige Schlüssel gibt, von denen nur ein einziger der wirklich Richtige ist?
Zur Erklärung:

Ich habe ein Feld voller Einsen und Nullen.
Wenn ich weiß, wie mein Text aussieht, kann ich mir daraus etliche verschiedene Schlüssel zusammenpuzzeln, die mir diesen Text ergeben ... aber nur ein einziger Schlüssel ist korrekt und würde bei einem neuen Verschlüsselungsdurchlauf den korrekten Text ergeben ...

Wenn ich ein Feld voller Buchstaben habe, kann ich mir ein Wörterbuch nehmen ud alle sinnvollen Möglichkeiten zusammensetzten, die es gibt. Wenn ich ein Feld voll mit 1 und 0 habe, kann ich das nicht, weil sich meine Bits nocht zu einem sinnvollen Text ergänzen. Ich kann mir jede mögliche Kombination aus diesen Bits basteln, aber niemand sagt mir, welche die richtige ist ... das ist nämlich eine aus 2^(X*Y*Ebenen*Farben).
Und selbst wenn ich etwas sinnvolles aus diesen möglichkeiten Fische, so ist die Wahrscheinlichkeit, dass es kein Wunschkonstrukt ist, gleich null, weil ich aus dem selben Feld, in dass ich "Morgen" verschlüsselt habe, auch "Abend" rauslesen kann.

Deshalb kann ich nicht erkennen, warum mein Verfahren empfindlich sein soll.

Und dazu kommt noch, dass mein Verfahren erstens durch seine Unsichtbarkeit geschützt ist und zweitens, wenn man verschiedene Bilder verwendet, auch keine Vergleiche schließen lässt ... dann kann man sogar Problemlos den sleben Key verwenden.

mfG

Markus

Hi,

die Anzahl der Möglichkeiten für eine Permutation sind N! nicht 2^N. Der Wechsel der Bilder bringt dir dabei nichts, weil du nur die niedrigsten Biteben verwendest, aber den Rest (in dem sich die Bilder unterscheiden) ignorierst. Das ist wie ein Zahlenschloss, dass du von einem roten Fahrrad auf ein Blaues gibst. Durch diesen Vorgang ist das Schloss auch nicht schwerer angreifbar.
Ansonsten stimmt es schon, dass bei richtiger Anwendung (Schlüssel nur einmal verwendet) diese Chiffre nur schwer zu brechen sein wird. Es bleiben aber nach wie vor die Schwachpunkte an anderer Stelle (Choosen Plaintext, Schlüsselgröße,...). Deshalb würde ich es nie für eine "reale" Anwendung verwenden.

Gruß
Reinhard

Zitat:

---

Original geschrieben von Andreas Mueller


frq -r l/NOPQRSTUVWXYZABCDEFGHIJKLM/MLKJUIHGPFEDCBONWTASQZVYXR/

---

Eigentlich war hier ausser dem Befehlswort (links vom /) gar nichts verschlüsselt, nicht mal rot13, hat's jemand gemerkt?

Nein.

Zitat:

---

weil sich meine Bits nocht zu einem sinnvollen Text ergänzen

---

Man kann auch neue Wörter einbauen die einem die Statistik beim Buchstabenzählen versaut. Ich mische unter meinem Text erstmal an mir bekannter Stelle sinnlose Buchstaben die nur den einen Sinn haben die Statistik beim zählen zu versauen.
Ich kam auf die Idee bei oberen zitierten Text. "nocht" eine Kombination aus "noch nicht". wenn man sowas einbaue bringt es das Wörterbuch auch nicht mehr.

Gruß

Neil

Naja, Neil, eigentlich soll der Tippfehler nur "nicht" bedeuten ...

Ach ja, @ Reinhard: Was bringt mir der Choosen Plaintext wenn ich nicht weis wo er steckt? Ohne die "Landkarte" kannst du dir deine Bits wie wild zusammenpuzzeln, vielleicht kriegste ihn ja auch wieder raus, aber der dann entstehende Schlüssel bringt dich leider keinen Meter weiter, weil der nämlich nur für die von dir gewählte Konstellation gilt, ausser wenn du mit extrem viel Glück den korrekten Schlüssel triffst ...
Und wenn ich über den Cäsar deinen Choosen Plaintext verschwinden lasse (natürlich für jedes Bit ein eigenes Schlüsselwort ... von denen hab ich ja in meinem Monsterschlüssel genug), dann fischt du endgültig im Trüben ...

Und mit dem Bildwechsel meinte ich nur, dass man dann keine Rückschlüsse auf den Anteil an Nutzdaten schließen kann ... so kann man zweimal den selben Text mit dem selben Schlüssel verschlüsseln, das Resultat ist zwar rein Kryptologisch gesehen dasselbe, aber meine Nutzdaten verschwinden ja in einem Hintergrundrauschen, welches ich selbst erzeuge.
Durch das neue Bild fällt es aber weniger auf, wenn sich gewisse Bitbereiche überdecken.
Und selbst im schlimmsten Fall sind immer noch ca. 50% aller Bits bei beiden Bildern gleich, was immer noch eine gigantische Masse an nutzlosen Füllbits darstellt.
Und anderster als bei Worten und Zeichen(folgen) kann man bei Bits nicht so leicht zwischen Füllbit und Datenbit unterscheiden ... womit wir wieder bei meinem gigantischen Feld von 1 en und 0 en wären, welche sich auf alle erdenklichen Arten zusammenstellen lassen.

Ach ja, meine Permutationszahl: 8! ~ 40000; 2^8 = 256 --> Meine Permutationen errechnen sich aus 2^(genutzte Bits+ungenenutzte Bits in der selben Ebene).

Meine Schlussfolgerung:

Der größte Schutz meines Verfahrens ist, dass es zum einen nicht als Stream betrachtet werden kann,
und zum zweiten, dass man anderster als bei Zeichen nicht von den Bits auf den Klartext schließen kann, da es alleine bei 8 Bits schon 256 Möglichkeiten gibt und somit, selbst wenn man alle Nutzdaten extrahiert,
erstens eine extrem hohe Zahl an Möglichkeiten hat,
und zweitens dann nur sämtliche möglichen Dateien mit dieser Dateigröße erhält, worunter etliche "Sinnvolle" Möglichkeiten sind, bei einer größe von vier Bytes könnte der Inhalt der Datei sowohl Neil, als auch pegi, als auch RMBF, oder aber auch WaRa oder oder oder ... du siehst, viele Möglichkeiten, alle Sinnvoll, aber nur eine stimmt!
Wobei ich anmerken muss, dass die Möglichkeiten durch die Anzahl der 1en und 0en eingeschränkt wird, was ich bei diesen Beispielen aus Faulheit aber nicht überprüft habe ... ich muss weiterprogrammieren


mfG

Markus