Ich habe schon die ganze Zeit überlegt, wo ich meine Paßwörter sicher aufbewahren kann. Dazu ist mir jetzt was eingefallen. Mit GIMP läßt sich ein Bild in zwei Halbbilder zerlegen, die zusammengefügt wieder das vollständige Bild ergeben. Wenn eines dieser Halbbilder auf dem Computer verbleibt, das andere z. B. auf einem Speicherstift abgelegt und woanders aufbewahrt wird, denke ich, wäre mein Problem bzgl. Sicherheitsbedenken gelöst. Mit nur einem Halbbild kann wohl niemand was anfangen? Manuell durchgeführt ist die Herstellung der Halbbilder allerdings etwas kniffelig. Ich hätte das gerne automatisiert für zukünftige Verschlüsselungen. Wäre so was eventuell mit einer Batch Progammierung möglich? Oder besser mit OOorg Basic? Hätte jemand Lust sich dem mal anzunehmen? Aufgabenstellung: Auf dem Desktop soll ein Bild (jpg, bmp, gif….egal) abgelegt werden. Dann soll das Programm gestartet und im Anschluß darauf sollen auf dem Desktop die beiden Halbbilder im gimpeigenen Format erscheinen, ggf. das zweite Halbbild ohne Umweg über den Desktop gleich auf dem Stift abspeichert werden. Wenn jemand für mich ein entsprechendes Programm schreiben würde, wäre das sehr freundlich...aber ich muß es nachvollziehen können! Oder gibt's so was schon? Bitte keine Hinweise auf Paßwortmanager und dgl. geben. Das ist mir alles bekannt. Will ich nicht haben. L.G.
Angehängte Dateien:
-
Seite4.jpg
270 KB
Wenn jemand das halbe Bild kennt, kennt er auch das halbe Passwort. Ist jetzt nicht so der ganz große Sicherheitsgewinn...
Also theoretisch recht einfach, mit C / C++ / C#. Bilddatei öffnen, Breite auslesen, 2 Bilder im RAM erzeugen, Streifen beliebiger Breite abwechselnd in die 2 Bilddateien schreiben, Beide Bilddateien abspeichern. :)
foo schrieb: > Wenn jemand das halbe Bild kennt, kennt er auch das halbe Passwort. Ist > jetzt nicht so der ganz große Sicherheitsgewinn... Mir reicht das aber an Sicherheit. Ich habe noch mal die originale Gimp-Datei beigefügt.
Habe es noch nie ausprobiert, aber vllt. könnte man das Bild auch mit einem "Schlüssel" verschlüsseln. Dann sollte eigentlich ein verrauschtes Bild entstehen.
Noch was vergessen. Es soll mit Version Gimp 2.6 erledigt werden.
olbi schrieb: > Noch was vergessen. Es soll mit Version Gimp 2.6 erledigt werden. Ja ich dachte du willst ein "Programm", damit du es halt nicht immer händisch machen musst?
:
Bearbeitet durch User
Adam P. schrieb: > Also theoretisch recht einfach, mit C / C++ / C#. > > Bilddatei öffnen, > Breite auslesen, > 2 Bilder im RAM erzeugen, > Streifen beliebiger Breite abwechselnd in die 2 Bilddateien schreiben, > Beide Bilddateien abspeichern. > > :) Danke. Aber C habe ich leider nicht. Ich kann auch nicht in C programmieren, da keine Vorkenntnisse vorhanden sind. Eine für mich einfache Lösung wird es dann wohl nicht geben?
olbi schrieb: > Eine für mich einfache Lösung wird es dann wohl nicht geben? Mir fällt grade nichts ein, außer es immer per Hand zu machen. Meine Idee war in etwas sowas: https://de.wikipedia.org/wiki/Visuelle_Kryptographie
foo schrieb: > Wenn jemand das halbe Bild kennt, kennt er auch das halbe > Passwort. Ist > jetzt nicht so der ganz große Sicherheitsgewinn... Je nach dem wo genau das Bild aufgeteilt worden ist sogar das Ganze. Und selbst wenn man bei aufteilen der Bilder genaustens auf die Buchstaben Trennung achtet damit keine Fragmente entstehen aus denen man den Fehlenden Buchstaben mit großer Wahrscheinlichkeit erraten kann muss das Passwort natürlich völlig Zufällig erstellt worden sein. Wenn es was "sinnvolles" ergibst kann man den fehlenden Teil extrem einfach erraten. Man sollte auch bedenken das man mit der "hälfte" schon bekannt gibst wie lange das Passwort ist und wie die Charakteristik ist. Mit diesen Infos kann jeder brute force den Rest in kurzer Zeit durchprobieren - Aus ursprünglich eignen Mio. an Kombinationen werden so ganz schnell nur noch wenige Tausend. Sowas nennt man im allgemeinen Security by obscurity:-)
Hier ist sowas als Online Tool, jedoch kann man dort kein eigenen Schlüssel angeben. https://encrypt.imageonline.co/index-de.php
foo schrieb: > Wenn jemand das halbe Bild kennt, kennt er auch das halbe Passwort. Ist > jetzt nicht so der ganz große Sicherheitsgewinn... Warum? Bei nur einem falsche Zeichen, funktioniert der Login nicht und die Ehefrau kommt dann auch nicht an mein Adressbuch z. B..
olbi schrieb: > Warum? Bei nur einem falsche Zeichen, funktioniert der Login nicht > und die Ehefrau kommt dann auch nicht an mein Adressbuch z. B.. Wegen dem was bereits erwähnt wurde: Irgend W. schrieb: > den > Fehlenden Buchstaben mit großer Wahrscheinlichkeit erraten kann muss das > Passwort natürlich völlig Zufällig erstellt worden sein. Sonst müssen die Passwörter auf dem Zettel zufällig erstellt sein und nicht sowas wie z.B.: "MeinGeheimesPasswort123" das wäre leicht herauszufinden, wenn man sich mal bissel Zeit nimmt und sich den Aufbau auf dem halben Bild anschaut. Dan müsste eher sowas da stehen: "a(§_X6-?fOo$!"
Adam P. schrieb: > Hier ist sowas als Online Tool, > jedoch kann man dort kein eigenen Schlüssel angeben. > > https://encrypt.imageonline.co/index-de.php Gut, aber dann begebe ich mich schon wieder in Abhängigkeit anderer Leute. Ich weiß doch gar nicht, was da abläuft. Ich denke da auch an die vielgelobte Kryptogafie vor etlichen Jahren, mit Tausendmillionen Möglichkeiten, wo der Geheimdienst aber im Klartext mitgelesen konnte. Für einige Leute gab es damals ein böses Erwachen.
Wie oben schon erwähnt, wenn auf der einen Häfte Kr el ns r steht, dann braucht deine Frau nicht übetrieben viel Fantasie, um auf Krümelmonster zu kommen. Und Brute Force geht auch sehr viel schneller, wenn man die ungefähre Länge und die Hälfte der Zeichen kennt. Und es kommt auch immer darauf an, vor wem man sich schützen möchte. Wenn es tatsächlich deine Frau ist, dann liegen die Probleme ganz woanders.
Ja stimmt, deshalb würde ich es auch nicht verwenden. Aber du musst erstmal Definieren wie sicher muss dein Sicher sein. Aufwand - Nutzen. Also wegen einem Adressbuch würde ich jetzt nicht so ein Aufriss machen ;)
> > das wäre leicht herauszufinden, wenn man sich mal bissel Zeit nimmt und > sich den Aufbau auf dem halben Bild anschaut. Das sehe ich aber ganz anders. Schau doch nur mal das Halbbild in meinem Post ganz oben an. Da kann keiner was mit anfangen!
Das ist keine Verschlüsselung. Das ist aufteilen der Information. Als hättest du zwei Schlösser und zwei Schlüssel. Wie kommt man auf so einen Schwachsinn? Kauf dir nen Yubikey und gut ist.
Hildegard schrieb: > Das ist keine Verschlüsselung. Das ist aufteilen der Information. Als > hättest du zwei Schlösser und zwei Schlüssel. Ja und...ist doch gut! Funktioniert doch. > > Wie kommt man auf so einen Schwachsinn? Kauf dir nen Yubikey und gut > ist. Gar nichts werde ich mir kaufen. Da gebe ich kein Geld für aus. Ich weiß schon gar nicht mehr wohin mit dem vielen Computerkram. ...und neue Paßwörter will ich mir auch nicht merken.
Bilder verschlüsseln? das erinnert doch fast an IRDETO. -Wer das analoge Premiere-Geflimmer noch kennt...
:
Bearbeitet durch User
● Des I. schrieb: > Bilder verschlüsseln? > das erinnert doch fast an IRDETO. > > -Wer das analoge Premiere-Geflimmer noch kennt... Falsche Firma, was war Kudelsky NAGRAVISION/Syster.
:
Bearbeitet durch User
Hildegard schrieb: > Kauf dir nen DAS mag bei Hildegard von Bingen geholfen haben. Sobald jedoch ein Wort im Speicher ist, könnte es auch einen Versuch geben diesen Speicher auszulesen? Was jetzt Herr Pegasus so alles kann weiß ich noch nicht.
ich würde das nicht mit dem "usability monster" gimp machen (mag bildbearbeitung generell nicht gern) sondern in bash mit imagemagick (spalten/zeilen/kästchen in schleifen ausschneiden und das ganze dann gleicb wieder zusammenbasteln z.b. https://legacy.imagemagick.org/discourse-server/viewtopic.php?t=13715 mit einer auswahl von splice, chop, montage, crop, append und ihren freunden
Wenn Du eine einfache Möglichkeit für verschiedene Passwörter suchst,
dann aufteilen in einen konstanten Teil, den Du Dir merkst ("Solerit4")
und einen kryptischen, individuellen Teil, den Du aufschreibst (
"X&as-6*@“)
Das Passwort ist dann ""Solerit4X&as-6*@“.
Deine Frau kann mit dem Geschreibsel nichts anfangen (ohne brutal
force), dein russischer Hacker nichts ohne.
Das geht so ähnlich auch für fremde Pins: merke Dir eine 4stellige Zahl
(4711). Von jeder Pin ziehst Du 4711 ab (Modulo) und schreibst den Wert
auf. Notfalls auf die Karte, aufs Handy etc.
Beim eingeben rechnest Du vorher das geschriebene + 4711
Angehängte Dateien:
-
seite5.png
290 KB -
seite5-enc-a.png
750 KB -
seite5-enc-b.png
750 KB -
seite5-dec.png
290 KB
Mindest genauso einfach wie das Zerlegen des Bilds in Streifen und – bei richtiger Handhabung – absolut sicher ist eine OTP-Verschlüsselung: https://de.wikipedia.org/wiki/One-Time-Pad Ich habe das mal ganz rudimentär in Python mit Pillow umgesetzt. Aufruf:
1 | imgotp.py encrypt <original> <verschlüsselt1> <verschlüsselt2> |
2 | |
3 | imgotp.py decrypt <verschlüsselt1> <verschlüsselt2> <entschlüsselt> |
Beispiel:
1 | imgotp.py encrypt seite5.png seite5-enc-a.png seite5-enc-b.png |
2 | |
3 | imgotp.py decrypt seite5-enc-a.png seite5-enc-b.png seite5-dec.png |
Die Bilder seite5-enc-a.png und seite5-enc-b.png sind jeweils für sich alleine wertlos und müssen getrennt voneinander aufbewahrt werden. Nur ein Besitzer beider Bilder kann das Originalbild wiederherstellen. Für alle anderen ist das absolut unmöglich, egal wieviel Aufwand sie in die Entschlüsselung hineinstecken.
Angehängte Dateien:
-
visualcrypt.PNG
820 KB
Yalu X. schrieb: > Aufruf: > imgotp.py encrypt <original> <verschlüsselt1> <verschlüsselt2> > imgotp.py decrypt <verschlüsselt1> <verschlüsselt2> <entschlüsselt> Ich wusste ja das mit Python alles einfacher geht... aber die paar Zeilen haben mich eindeutig überzeugt :) Das werde ich mir mal genauer anschauen! Ich habe es grad mit C++ versucht, aber anderes Verfahren. Funzt aber auch. Aber ich hab da noch irgendwo ein Farbproblem bei der Rückrechnung... naja, ist ja nur ein Versuch gewesen um es mal zu probieren (Neugier). Edit: Farbproblem gelöst...copy&paste Fehler.
:
Bearbeitet durch User
Adam P. schrieb: > Ich wusste ja das mit Python alles einfacher geht... > aber die paar Zeilen haben mich eindeutig überzeugt :) Dass das Programm so kurz ist, liegt auch daran, dass es keinerlei Fehlerabfragen enthält. Schon beim kleinsten Fehler bekommt man deswegen einen Stacktrace entgegengeschmissen (ok, immer noch besser als ein Segfault :)). Welches Verfahren hast du in deinem Programm verwendet?
Yalu X. schrieb: > Welches Verfahren hast du in deinem Programm verwendet? Ich bin einfach hergegangen, hab mir mit HxD ein 512 Byte großes Array mit Zufallswerten erzeugt. Dann durchlaufe ich jedes Pixel und addiere den Wert aus dem Array dazu. "code" ist mein Zufallswerte-Array.
1 | for (y=0; y<height; y++) |
2 | {
|
3 | for (x=0; x<width; x++) |
4 | {
|
5 | pixel = decrypt->Canvas->Pixels[x][y]; |
6 | |
7 | b = (pixel & 0xFF0000) >> 16; |
8 | g = (pixel & 0x00FF00) >> 8; |
9 | r = (pixel & 0x0000FF); |
10 | |
11 | b += code[i % 512]; |
12 | g += code[(i+1) % 512]; |
13 | r += code[(i+2) % 512]; |
14 | |
15 | pixel = (b << 16) | (g << 8) | r; |
16 | |
17 | decrypt->Canvas->Pixels[x][y] = pixel; |
18 | i += 3; |
19 | }
|
20 | }
|
Das mit dem Array machst du ja auch, aber danach trennen sich unsere Wege :-D Meins ist nicht wirklich sicher, außer man würde es so umschreiben, dass du noch eine Key-Datei öffnen könntest, dann hättest ja auch 2 Dateien. Also das 512 Byte Array in eine Key-Datei auslagern.
:
Bearbeitet durch User
olbie schrieb: > zwei Halbbilder zerlegen, > die zusammengefügt wieder das vollständige Bild ergeben d.h. man sieht nicht nur wie lang das Passwort ist, sondern hat sofort die Hälfte der Zeichen? Really?
wenn man sich ein vernünftiges System aneignet, wie man seine Passworte vergibt, braucht man das alles garnicht. Bring unter anderem z.B. die Jahreszahl mit ins Passwort rein, dann hast Du auch schon mal einen Grund das PW Jährlich zu ändern.
● Des I. schrieb: > wenn man sich ein vernünftiges System aneignet ja, aber was bringen neue Passwörter, wenn sie nach gleichen Regeln, wie die alten, aufgebaut sind?
Das BSI hat sich von der Empfehlung, Passwörter regelmäßig zu ändern, schon vor längerer Zeit verabschiedet. Seit Jahren sind viele Sicherheitsfachleute der Ansicht dass solche Regeln eher schaden als nützen. "Ein gutes Passwort kann man bedenkenlos über Jahre hinweg nutzen", schreibt Heise Security. "Das regelmäßige Ändern führt eher dazu, dass man schwache Passwörter benutzt und diese beispielsweise nach einem Schema (geheim1, geheim2, ...) erzeugt." Siehe dazu auch: https://www.bsi.bund.de/DE/Themen/Verbraucherinnen-und-Verbraucher/Informationen-und-Empfehlungen/Cyber-Sicherheitsempfehlungen/Accountschutz/Sichere-Passwoerter-erstellen/Umgang-mit-Passwoertern/umgang-mit-passwoertern_node.html
steganography schrieb: > ● Des I. schrieb: >> wenn man sich ein vernünftiges System aneignet > > ja, aber was bringen neue Passwörter, wenn sie nach gleichen Regeln, wie > die alten, aufgebaut sind? mehrteiliges Passwort. darin z.B. Dein Username oder der Name des Programms wofür das PW sein soll. dazu Deine Telefonnummer, Dein Autokennzeichen etc dazu noch Sonderzeichen, mit denen du die Teilbereiche des PW trennst. So erinnere ich mich an 20 Jahre alte PW...
Angehängte Dateien:
-
seite4_5.jpg
130 KB
steganography schrieb: > olbie schrieb: >> zwei Halbbilder zerlegen, >> die zusammengefügt wieder das vollständige Bild ergeben > > d.h. man sieht nicht nur wie lang das Passwort ist, sondern hat sofort > die Hälfte der Zeichen? Really? Im Prinzip ja, wenn man mal von den leeren Streifen absieht. Was ich rausgefunden habe: Ich kann in Gimp die beiden Bilder übereinanderlegen und dort die Nachricht auch sichtbar machen. Aber die Halbbilder selber kann ich nicht erstellen. Leider fehlt mir das Programm und die erforderlichen Progammierkenntnisse dazu, und überhaupt bin ich nicht auf dem Laufenden. Ich habe wenig bis keine Ahnung, bin auch schon etwas älter. Schade, aber das werde ich wohl nicht hinkriegen? L.G.
Angehängte Dateien:
-
seite5.png
290 KB -
seite5-enc-gimp.png
730 KB -
seite5-dec-gimp.png
740 KB
olby schrieb: > Was ich rausgefunden habe: Ich kann in Gimp die beiden Bilder > übereinanderlegen und dort die Nachricht auch sichtbar machen. Ja, das scheint erstaunlich gut zu funktionieren, obwohl der Gimp-Modus "Unterschied" (absolute Differenz) eine ganz andere Funktion ist als die, die ich für die OTP-Verschlüsselung verwendet habe (XOR). Ein Bisschen Rauschen bleibt zwar, aber der Text ist dennoch gut lesbar. > Aber die Halbbilder selber kann ich nicht erstellen. Doch, das geht genauso: Lade das Originalbild und lege (im Modus "Unterschied") ein zweites Bild darüber, das nur Rauschen enthält, z.B. eines der beiden aus meinem vorletzten Beitrag (seite5-enc-a.png oder seite5-enc-b.png). Allerdings ist die auf der absoluten Differenz basierende Funktion d: B → B, x ↦ |x - c|, c ∈ B, B = [0, 255] für 1 ≤ c ≤ 254 nicht surjektiv, weswegen im verschlüsselten Bild noch ein paar Überbleibsel des Originalbilds erkennbar sind. Die Funktion ist auch nicht selbstinvers, weswegen nach zweimaliger Anwendung nicht wieder exakt das Original, sondern nur eine stark verrauschte (aber im konkreten Fall immerhin noch lesbare) Version davon herauskommt (s. Anhang). Die XOR-Verknüpfung und die Modulo-256-Addition hingegen sind Beispiele von Operationen, die für die OTP-Verschlüsselung perfekt geeignet sind. Leider sind sie im Gimp nicht verfügbar (oder ich habe sie noch nicht gefunden). olby schrieb: > Leider fehlt mir das Programm und die erforderlichen > Progammierkenntnisse dazu, und überhaupt bin ich nicht auf dem > Laufenden. Ich habe wenig bis keine Ahnung, bin auch schon etwas älter. > Schade, aber das werde ich wohl nicht hinkriegen? Du könntest Python und Pillow installieren und dann mein Progrämmchen von oben verwenden. https://wiki.python.org/moin/BeginnersGuide/Download https://pillow.readthedocs.io/en/stable/installation.html
> Ich habe das mal ganz rudimentär in Python mit Pillow umgesetzt. > > Aufruf: > imgotp.py encrypt <original> <verschlüsselt1> <verschlüsselt2> > imgotp.py decrypt <verschlüsselt1> <verschlüsselt2> <entschlüsselt> > > Beispiel: > imgotp.py encrypt seite5.png seite5-enc-a.png seite5-enc-b.png > imgotp.py decrypt seite5-enc-a.png seite5-enc-b.png seite5-dec.png > Ich verstehe das leider nicht. Aber ich wage mal eine dumme Frage: Ein Makro geschrieben in Python / OOorg. calc. Ginge das damit?
Yalu X. schrieb: > Du könntest Python und Pillow installieren und dann mein Progrämmchen > von oben verwenden. > > https://wiki.python.org/moin/BeginnersGuide/Download > https://pillow.readthedocs.io/en/stable/installation.html Danke, das werde ich mal ausprobieren.
Adam P. schrieb: > Ich habe es grad mit C++ versucht, aber anderes Verfahren. > Funzt aber auch. Das Zufallszahlen-Array ist – gemessen an der Gesamtgröße des Bildes – ziemlich klein, so dass man im verschlüsselten Bild die Periodizität gut erkennen kann. Das ermöglicht es einem Angreifer, dieses Array näherungsweise zu rekonstruieren und damit das Bild gut genug zu entschlüsseln, um den Text lesen zu können. Das OT in OTP steht nicht umsonst für "One-Time", denn das generierte Zufallszahlen-Array sollte nur ein einziges Mal verwendet werden. Das bedeutet im konkreten Fall, dass es mindestens so lang wie die Bilddatei sein und für jede Verschlüsselung neu generiert werden sollte.
Yalu X. schrieb: > Leider sind sie im Gimp nicht verfügbar (oder ich habe sie noch nicht > gefunden). "Exclusion" als Layer-Modus? Zumindest konnte ich deine Variante einigermaßen nachvollziehen. Eine Lage voller Rauschen kann man mit Filter -> Noise -> Hurl produzieren, wobei man die Schieberegler alle an den rechten Anschlag fahren muss. Außerdem sollte man natürlich ein random seed benutzen (siehe deinen Beitrag über meinem). Das Rauschbild ist natürlich nicht wirklich komprimierbar, das ist der Nachteil des Verfahrens. Aber es kommt komplett mit Gimp aus.
:
Bearbeitet durch Moderator
xor aufblähen durch Ersatzfunktion aus and/or und not geht nicht?
Jörg W. schrieb: > "Exclusion" als Layer-Modus? Geht einigermaßen, ist aber auch nicht perfekt. Im Vergleich zu "Difference" rauscht das entschlüsselte Bild zwar weniger, hat aber auch weniger Kontrast. Weißt du, was "Exclusion" genau macht? Hier hätte ich die Antwort erwartet: https://docs.gimp.org/en/gimp-concepts-layer-modes.html Sie lautet aber nur "TODO" :) Abdul K. schrieb: > xor aufblähen durch Ersatzfunktion aus and/or und not geht nicht? Gibt es AND, OR und NOT in Gimp?
ACHTUNG ACHTUNG, VERSCHLÜSSELUNGSEXPERTEN ON TOUR!
Ein Gimp-Schredder.... jop. passt. Irgendwo mal was mit Verschlüsselung
gelesen und schon ist man Experte. Naja, die besten Ideen sind immer
die, die nie gepentested wurden, nicht wahr?
Und dann kommen die anderen mit OTP daher und preisen es als
Allheilmittel an.
Mal ein kleines Geheimnis, dessen wahre Bedeutung hier aber
wahrscheinlich eh keiner versteht: Das Problem ist nicht die
Kryptographie an sich, sondern das ganze drumherum.
Zum Thema OTP zum Beispiel:
Message1 XOR key1 = Ciphertext1
Message2 XOR key1 = Ciphertext2
Ciphertext1 XOR Ciphertext2
(Message1 XOR key1) XOR (Message2 XOR key1)
Message1 XOR Message2 XOR key1 XOR key1 <- 2*XOR neutralisiert sich!
Message1 XOR Message2
Ergebnis:
Ciphertext1 XOR Ciphertext2 = Message1 XOR Message2
Aber ja, sicher genug, wenn es nicht sicher sein muss, ist ziemlich
vieles, sogar der Aktenschredder mit der Sicherheitsstufe 1, die hier
als sicher genug fabuliert wird.
Yalu X. schrieb: > Gibt es AND, OR und NOT in Gimp? Du bist doch der Experte. Ich habe Gimp vor 10 Jahren mal superkurz benutzt, also frag mich besser nicht🤣
HExperte schrieb: > Mal ein kleines Geheimnis, dessen wahre Bedeutung hier aber > wahrscheinlich eh keiner versteht Nur gut, dass wir dich haben. Wir verstehen es jetzt zwar immer noch nicht (das war ja dein Plan), aber du bist es los geworden. Das ist doch das Wichtigste. Ob das dem TE irgendwie weiter geholfen hat?
Yalu X. schrieb: > Weißt du, was "Exclusion" genau macht? Nö. Klang so bisschen wie "Exclusive OR", aber wirklich überzeugt das nun auch nicht.
Yalu X. schrieb: > Abdul K. schrieb: >> xor aufblähen durch Ersatzfunktion aus and/or und not >> geht nicht? > > Gibt es AND, OR und NOT in Gimp? Kann man doch mittels Transparanz emulieren: - Erste Variable (=untere Ebene) bleibt normal Schwarz/Weiss. - Zweite Variable (=obere Ebene) "Schwarz-->Schwarz" und "Weiss-->Transparent" gibt ODER. - Obere Ebene "Weiss-->Weiss" und "Schwarz-->Transparent" gibt UND. (Gilt für Weiss-->Falsch und Schwarz-->Wahr) NOT ist Invertieren, das gibt es.
HExperte schrieb: > Zum Thema OTP zum Beispiel: > > Message1 XOR key1 = Ciphertext1 > Message2 XOR key1 = Ciphertext2 Ahh. Es heißt ONE TIME Pad, weil man es ZWEIMAL verwenden soll. Alles klar. > Aber ja, sicher genug, wenn es nicht sicher sein muss, Spinner.
steganography schrieb: > d.h. man sieht nicht nur wie lang das Passwort ist, > sondern hat sofort die Hälfte der Zeichen? Really? Köstlich. Gegeben sei ein (binär codierter) Klartext und der zugehörige Geheimtext gleicher Länge. Betrachte das n-te Bit von Klartext und Geheimtext. Welche Möglichkeiten außer "stimmen überein" und "sind verschieden" fallen Dir bei einem binären Code noch ein?
Egon D. schrieb: > Ahh. Es heißt ONE TIME Pad, weil man es ZWEIMAL > verwenden soll. > > Alles klar. > > >> Aber ja, sicher genug, wenn es nicht sicher sein muss, > > Spinner. Nö. Ich lebe in der Realität und du in deiner Traumwelt. Du willst gar nicht wissen, wie oft ich bei Audits schon die kryptografisch unsichere Verwendung von Keys bemängeln durfte. Das Argument ist dann immer das gleiche "wir dachten, dass ist schon nicht so schlimm." "Mal Kirche im Dorf lassen" etc blablubb.
HExperte schrieb: > Ich lebe in der Realität und du in deiner Traumwelt. Urteile doch bitte nur über Dinge, die Du auch beurteilen kannst. Meine Lebensumstände gehören nicht dazu. > Du willst gar nicht wissen, wie oft ich bei Audits > schon die kryptografisch unsichere Verwendung von > Keys bemängeln durfte. Das Argument ist dann immer > das gleiche "wir dachten, dass ist schon nicht so > schlimm." "Mal Kirche im Dorf lassen" etc blablubb. Ach so. Okay, jetzt verstehe ich, was Du mitteilen wolltest. Nur mal als Hinweis: Der Wurm muss dem Fisch schmecken, nicht dem Angler. Wenn Du bei den Audits genauso kommunizierst wie hier, dann ist Dein... ähhh... limitierter Erfolg leicht erklärlich.
Beitrag #6814189 wurde von einem Moderator gelöscht.
Beitrag #6814194 wurde von einem Moderator gelöscht.
HExperte schrieb: > Mal ein kleines Geheimnis, dessen wahre Bedeutung hier aber > wahrscheinlich eh keiner versteht: Das Problem ist nicht die > Kryptographie an sich, sondern das ganze drumherum. > > Zum Thema OTP zum Beispiel: > > ... > > Ergebnis: > Ciphertext1 XOR Ciphertext2 = Message1 XOR Message2 Wow, alle Achtung, du bist wirklich der Mega-Uber-Kryptoexperte. Jetzt weiß ich endlich, dass man das One-Time-Pad nicht Two-Times verwenden sollte. Diese bahnbrechende Erkenntnis haut mich total aus den Socken. Ich bin übrigens der Mega-Uber-Filterexperte und verrate dir jetzt als Gegenleistung ebenfalls ein kleines Geheimnis: Zum Thema Tiefpass zum Beispiel: (Die Berechnung lass ich hier mal weg) Ergebnis: Ein Tiefpassfilter ist zur Übertragung hoher Frequenzen nur bedingt geeignet, da er diese dämpft. Ja, das haut jetzt dich total aus den Socken, nicht wahr? Es ist doch immer schön, mit selbsternannten Experten zu diskutieren :)
Egon D. schrieb: > Yalu X. schrieb: > >> Abdul K. schrieb: >>> xor aufblähen durch Ersatzfunktion aus and/or und not >>> geht nicht? >> >> Gibt es AND, OR und NOT in Gimp? > > Kann man doch mittels Transparanz emulieren: > - Erste Variable (=untere Ebene) bleibt normal Schwarz/Weiss. > - Zweite Variable (=obere Ebene) "Schwarz-->Schwarz" und > "Weiss-->Transparent" gibt ODER. > - Obere Ebene "Weiss-->Weiss" und "Schwarz-->Transparent" > gibt UND. > (Gilt für Weiss-->Falsch und Schwarz-->Wahr) Ja, das wäre ein guter Ansatz. Wenn ich das richtig verstanden habe, lässt sich das aber nur auf Binärbilder (mit nur zwei Farben: schwarz und weiß) anwenden. Könnte man das irgendwie verallgemeinern, um auch RGB-Bilder wie das des TE verarbeiten zu können? > NOT ist Invertieren, das gibt es. Die Invertierfunktion arbeitet bitweise auf den Farbwerten und ist damit perfekt. Zusammen mit einer bitweise AND- und OR-Funktion könnte man dann ein bitweises XOR realisieren, womit auch in Gimp ein echtes OTP möglich wäre. Aber selbst wenn dies irgendwie gelänge, wäre wahrscheinlich die Handhabung des Ganzen so umständlich, dass man lieber ein Plug-In schreibt, in dem man ja problemlos jede beliebige Pixelberechnung ausführen kann.
Er kann es sich auch einfach machen, wenn die Sicherheit nicht so hoch sein darf. Entweder mit Zip oder Rar : https://www.pcwelt.de/tipps/So_verstecken_Sie_Zip-Archive_in_Bildern-Daten_verstecken-8518950.html
Jörg W. schrieb: > HExperte schrieb: >> Mal ein kleines Geheimnis, dessen wahre Bedeutung hier aber >> wahrscheinlich eh keiner versteht > > Nur gut, dass wir dich haben. Wir verstehen es jetzt zwar immer noch > nicht (das war ja dein Plan), aber du bist es los geworden. Das ist doch > das Wichtigste. > > Ob das dem TE irgendwie weiter geholfen hat? was ich verstehe, verstehe ich. Wenn nicht, ist das auch nicht weiter schlimm, dann halt nicht...ist nicht so wichtig! Interessant finde ich die Unterhaltung trotzdem. Yalu X. schrieb: > Das OT in OTP steht nicht umsonst für "One-Time", denn das generierte > Zufallszahlen-Array sollte nur ein einziges Mal verwendet werden. Das > bedeutet im konkreten Fall, dass es mindestens so lang wie die Bilddatei > sein und für jede Verschlüsselung neu generiert werden sollte. Ich hab's mit Gimp versucht, wie du gesagt hast. Bisher leider ohne richtig Erfolg. Da muß ich mich noch mal mit beschäftigen. Soweit ich es verstanden habe, und wenn das mit Gimp so funktioniert wie beschrieben, dann ist man auf Zufallsvariablen nur einmal angewiesen. Dann wird halt mit jeder Übermittlung auch ein Anhang (Code) mitgesendet, der das erste Halbbild (Zufallsvariable) verändert (Z. B. seite5-enc-a.png). Das müßte dann empfängerseitig mit einem Programm erledigt werden. Senderseitig zuvor natürlich auch. Bei jeder weiteren Übermittlung dann natürlich wieder auf's Neue für jede weitere Übertragung. Vermutlich Quatsch, meine Überlegung! Bitte mir nicht übelnehmen.
Abdul K. schrieb: > Yalu X. schrieb: ... > Du bist doch der Experte. Ich habe Gimp vor 10 Jahren mal superkurz > benutzt, also frag mich besser nicht🤣 Da war Gimp noch leicht zu verstehen. Guck jetzt mal die neueste Version 2.10. Das ist ja wohl 'ne Zumutung? ...dann noch dieses Layout in schwarz...furchtbar!
Für mich waren die bisherigen Vorschläge nicht überzeugend. Wenn es eines von vielen regelmäßig genutztes Passwörtern ist, dann nimm KeePassXC. Wenn es ein besonderes regelmäßig genutztes Passwort ist, dann merke es dir (z.B. das für KeePassXC oder Festplattenverschlüsselung/LUKS). Selbige(s) Haupt-Passwort/-wörter möchte man z.B. für den Todesfall evtl. anderen Leuten (den Erben, dem Partner) vorab mitteilen und bei direkter Weitergabe hat dann das Problem, dass die das dann aber schon vorher verwenden könnten. In dem Fall ist die Lösung seit dem letzten Jahrhundert bekannt und heißt Shamir's Secret Sharing: https://en.wikipedia.org/wiki/Secret_sharing https://en.wikipedia.org/wiki/Shamir%27s_Secret_Sharing Gibt mit ssss auch ein tool dafür: http://point-at-infinity.org/ssss/ https://packages.debian.org/bullseye/ssss Man kann das Geheimnis zum Beispiel auf 3 Parteien aufteilen und mindestens 2 davon müssen zusammen kommen und sich gegenseitig ihren Teil des Geheimnisses teilen. Im Fall von Erben könnte man z.B. einen Teil beim Notar als Teil des Testaments ablegen. Einen anderen Teil gibt man den potentiellen Erben, dem Partner, einem guten Schulfreund, oder irgendeiner anderen Vertrauensperson. Wie genau das Geheimnis abgespeichert ist, z.B. einfach als Text ausdrucken und mit später OCR wieder einscannen oder abtippen, als "Bild" ausdrucken, auf einem USB-Stick speichern, etc... ist egal. Secret Sharing bietet sich auch an, wenn man Software-releases kryptographisch signieren möchte, aber nicht eine Person alleine Zugriff auf den geheimen Schlüssel haben soll (bzw. jemand, der es mit krimineller Energie schafft, auf den Rechner einer der Personen zu kommen). In dem Fall kann man das ähnlich machen und z.B. erfordern, dass mindestens zwei Maintainer zusammen kommen und ihren Teil des Geheimnisses teilen um den Signierschlüssel zu erhalten. Das ganze macht man dann auf einem airgapped Rechner in einem Live-System, dessen Inhalt nach dem reboot verlohren ist.
olby schrieb: > ...dann noch dieses Layout in schwarz...furchtbar! Edit > Preferences > Interface > Theme > dann ein anderes als "Dark" auswählen, z.B. "System".
HM schrieb: > olby schrieb: >> ...dann noch dieses Layout in schwarz...furchtbar! > > Edit > Preferences > Interface > Theme > dann ein anderes als "Dark" > auswählen, z.B. "System". Danke, dann müßte ich mal sehen, ob das so geht. Aber ich habe 2.10 auch nicht installiert. Ich bin mit 2.6 voll zufrieden.
olbie schrieb: > Ich hätte das gerne automatisiert für zukünftige Verschlüsselungen. > Wäre so was eventuell mit einer Batch Progammierung möglich? > Oder besser mit OOorg Basic? Gimp hat eine eingebaute Sprache "Script-Fu" siehe https://docs.gimp.org/2.10/de/gimp-concepts-script-fu.html Das Skript musst Du aber schon selbst erstellen.
Haarsträubend, alles Amateure hier: Jeder mit ein wenig Wissen wird erkennen, das nur eine Vollbitverschlüsselung sicher ist! Die bisher weltweit einzige sichere Methode kommt immer noch vom KRYPTOCHEF Detlef Granzow (persönlich)! Alles andere sind Fakenews. Aufjedenfall, ganzsicher. Keinewiederrede...
Potato schrieb: > Haarsträubend, alles Amateure hier Ah, noch einer. Schön, dass du dir nichtmal die Mühe machst, den TE zu verstehen. Nirgends war die Rede von einer kryptografisch sicheren Verschlüsselung. Wenn man sowas haben will, nimmt man die dafür fertigen Tools.
Jörg W. schrieb: > Potato schrieb: >> Haarsträubend, alles Amateure hier > > Ah, noch einer. Ich glaube, bei Potato hast du den nicht vorhandenen Smiley übersehen ;-) Er bezieht sich auf dieses Individuum hier, das seine Webseite wohl mittlerweile so stark verschlüsselt hat, dass es selber nicht mehr darauf zugreifen kann und seine Domain deswegen zurückgegeben hat: https://web.archive.org/web/20140517202802/http://kryptochef.net/
Yalu X. schrieb: > Ich glaube, bei Potato hast du den nicht vorhandenen Smiley übersehen > ;-) OK, nein, das kannte ich noch nicht.
Yalu X. schrieb: > Er bezieht sich auf dieses Individuum hier, das seine Webseite wohl > mittlerweile so stark verschlüsselt hat, dass es selber nicht mehr > darauf zugreifen kann und seine Domain deswegen zurückgegeben hat: > https://web.archive.org/web/20140517202802/http://kryptochef.net/ Danke, die Seite ist einfach nur köstlich... "Vollbitverschlüsselung", achnee "Vollbit Verschlüsselung" - klasse! EDIT: Boah, hab ich gelacht! Er kann nicht nur verschlüsseln, sondern auch "zerstören"! Zitat: "Datei zerstören liest die Länge der zu zerstörenden Datei ein. Erzeugt Zufalls Daten und überschreibt die zu zerstörende Datei damit bis maximal 3000 mal." 3000 mal! Damit hätte mein Radiergummi schon das ganze Blatt Papier zerfetzt!
:
Bearbeitet durch Moderator
Yalu X. schrieb: > Das Zufallszahlen-Array ist – gemessen an der Gesamtgröße des Bildes – > ziemlich klein, so dass man im verschlüsselten Bild die Periodizität gut > erkennen kann. Ja da gebe ich dir Recht. War von mir auch nur ein Versuch.
Yalu X. schrieb: > Das OT in OTP steht nicht umsonst für "One-Time", denn das generierte > Zufallszahlen-Array sollte nur ein einziges Mal verwendet werden. Ich hatte vor einigen Wochen mal so etwas ähnliches gemacht in C - einfach als Spielerei. Eine beliebige Datei (muss also kein Bild sein) sequentiell eingelesen und jedes Zeichen mit dem nächsten Zufallswert aus /dev/urandom ver-x-odert und direkt wieder weggeschrieben. Das Ergebnis kam dann nach Datei A, der Zufallswert nach Datei B. Das Prinzip ist eigentlich dasselbe, ist aber nicht auf Bilder beschränkt. Ein Array von Zufallszahlen ist dabei auch nicht notwendig: diese Zahlen kann man unabhängig von der Größe der Datei munter weiter sequentiell und beliebig oft "on the fly" erzeugen. Durch mehrfache Anwendung kann man das Ergebnis nicht nur halbieren (zwei Dateien an verschiedenen Orten der Welt), sondern auch vierteln, achteln usw. P.S. Ja, ich weiß, dass man besser /dev/random nehmen sollte ;-)
:
Bearbeitet durch Moderator
Du meinst nicht 'schredder' sondern 'scrambler' in deiner Überschrift. https://de.wikipedia.org/wiki/Scrambler_(Telekommunikation) In deinem Überschaubaren Fall, würde ich das tatsächlich manuell machen, statt diese Gimp-frickelei. Du kannst aber auch eine Folie mit geschwärzten Spalten (jede zweite) verwenden und zwei scans mit jeweils Verschiebung der Folie um eine Spaltenbreite machen.
Frank M. schrieb: > Danke, die Seite ist einfach nur köstlich... "Vollbitverschlüsselung", > achnee "Vollbit Verschlüsselung" - klasse! Da kann man noch was lernen: > Ein Byte hat also nur (8 Binär Bits) bzw. (256 Dezimal Bits) und kann > deshalb garnicht unter (Dezimal Bit 0) oder > über (Dezimal Bit 256) sein. > Deshalb ist 256 Bit die technisch höchste Verschlüsselungstiefe die > überhaupt auf Computern möglich ist.
:
Bearbeitet durch User
Martin H. schrieb: > Da kann man noch was lernen: >> Ein Byte hat also nur (8 Binär Bits) bzw. (256 Dezimal Bits) und kann >> deshalb garnicht unter (Dezimal Bit 0) oder >> über (Dezimal Bit 256) sein. >> Deshalb ist 256 Bit die technisch höchste Verschlüsselungstiefe die >> überhaupt auf Computern möglich ist. Naja, er könnte jedes Byte auch 3000 mal verschlüsseln, dann hätte er - nach seiner Definition - eine Verschlüsselungstiefe von sagenhaften 768.000 Bit. Dann ist das wenigstens genauso sicher wie sein Programm "Zerstören". ;-)
Frank M. schrieb: > Das Prinzip ist eigentlich dasselbe, ist aber nicht auf Bilder > beschränkt. Ja, es ist nicht nur universeller, sondern sogar einfacher, weil man dann nicht noch das Bildformat dekodieren und wieder kodieren muss. Ich hab's halt gemacht, damit der TE wie bei seinem eigenen Verfahren zwei Bilder als Ergebnis bekommt. Als Nebeneffekt kann man noch schön sehen, ob die Verschlüsselung geklappt hat (Indiz dafür: gleichmäßiges Rauschen über das gesamte Bild und sonst nichts).
Yalu X. schrieb: > Als Nebeneffekt kann man noch schön > sehen, ob die Verschlüsselung geklappt hat (Indiz dafür: gleichmäßiges > Rauschen über das gesamte Bild und sonst nichts). Ja, das war eine schöne Veranschaulichung - nicht nur, was das Ansehen der Bilder betrifft, sondern auch, wie man das in Python sehr einfach formulieren kann. Danke dafür.
Wenn du magst, mach ich dir dazu ein Progrämmchen. Allerdings ohne Gimp und für Windows.
Matse schrieb: > Wenn du magst, mach ich dir dazu ein Progrämmchen. Allerdings ohne > Gimp > und für Windows. Wenn Du so freundlich bist, Danke.
Angehängte Dateien:
-
verknuepfung2.jpg
33 KB
Von den Schredderstreifen bin ich inzwischen abgekommen. Jetzt hätte ich doch lieber das professionelle Verfahren. Aber so richtig komme ich nicht weiter mit der Erstellung der Halbbilder. Ich würde es gern mit Gimp machen. Dazu müßte ich wissen, wie die Verknüpfungen der einzelnen Modi aussehen. Für "Normal" bin ich auf die Verknüpfung auf dem Bild im Anhang gekommen, bin mir aber nicht sicher, ob das so richtig ist. Wie ist das mit den anderen?...Unterschied, Multiplikation, Division usw. Ist das irgenwo notiert? L.G.
Wieso schriebt ihr den Text nicht in ein char[][]-array und fummelt dort dann auf Zeilen und Spalten rum, das ist einfacher zu programmieren, speichern, auch auf Papier per Bleistift.
Da ich nicht programmieren kann (jedenfalls nicht so richtig), habe ich mit Gimp noch etwas rumprobiert. Das hier habe ich schon mal hinbekommen: (s. Anhang). Wenn man die Buchstaben von Hand malt, ist das ganz einfach zu machen. Schwieriger wird es mit einem Dokument. Das muß man zuerst in die richtige Form bringen. Die Nachricht muß mit Pixeln geschrieben werden. Es geht bestimmt auch mit Gimp, aber bis jetzt habe ich es nicht hingekriegt. Vielleicht weiß jemand weiter? L.G.
Angehängte Dateien:
-
olbi_Screenshot.jpg
37 KB
mit Screenshot. (Ich komme mit dem Hochladen der Bilder nicht klar)
Ich nehme an, wenn man für jede Nachricht ein anderes Pixelfeld nimmt, dürfte m. E. der Code nicht zu knacken sein. Auf jeden Fall ist schon besser als der Streifenschredder.
soll ich mir das verschlüsselte Dokument jetzt wirklich runterladen?
●DesIntegrator ●. schrieb: > soll ich mir das verschlüsselte Dokument jetzt wirklich > runterladen? Wenn du es sehen möchtest, wird dir wohl nichts anderes übrig bleiben. Es klappt inzwischen auch mit einem ganzen Schriftsatz. 50 Zeilen sind kein Problem. Man muß dann nur das Pixelfeld groß genug machen. Theoretisch ließe sich das bestehende Pixelfeld mit dem neu gesendeten Feld modulieren, so daß ein ganz neues Feld vorliegt. Das jeweils neue Feld kennen dann nur Absender und Empfänger. Einmal zu Anfang ein Pixelfeld erzeugt, würde das ausreichen für eine sichere Codierung auch aller nachfolgender Übetragungen. Meiner Meinung nach ist die Übertragung für Dritte dann nicht zu entschlüsseln...Jedenfalls habe ich mir das erstmal so ausgedacht. Was ist davon zu halten? Ich habe eine Ahnung von Verschlüsselung. Wenn es funktionieren sollte, vielleicht was fürs Internet?
> Was ist davon zu halten? Ich habe eine Ahnung von Verschlüsselung.
"keine Ahnung" soll es natürlich heißen.
Angehängte Dateien:
-
olbi.png
210 KB -
document_verschluesselt.png
210 KB -
threshold.png
19 KB -
olbi-threshold.png
958 Bytes -
document_verschluesselt-threshold.png
1,2 KB -
olbi-document_verschluesselt.png
18 KB
olby schrieb: > Das hier habe ich schon mal hinbekommen: (s. Anhang). olby schrieb: > Mit Dokumenten funktioniert es inzwischen auch. Wenn ich jeweils nur den ersten Layer hernehme (olbi.png bzw. document_verschluesselt.png) und den zweiten nicht kenne, sollte daraus das Originalbild ja eigentlich nicht rekonstruierbar sein. Es geht aber (zumindest ansatzweise) dennoch, indem man auf die verschlüsselten Bilder die Threshold-Funktion von Gimp mit den Thresholds 1 und 254 und dem Channel RGB anwendet (theshold.png). Damit entstehen die Bilder olbi-threshold.png und document_verschluesselt-threshold.png. Das Verfahren ist also auch nicht sicherer als dein ursprüngliches Steifenverfahren. Ich vermute, dass deine Originalbilder Schwarz-Weiß-Bilder mit Antialiasing sind. An den Schwarz-Weiß-Übergängen entstehen durch das Antialiasing Grauwerte, die durch die Threshold-Funktion hervorgehoben werden. Beim "l" und beim senkrechten Balken im "b" hat in document_verschluesselt.png wohl kein Antialiasing stattgefunden, deswegen konnten diese Teile mit dem einfachen Threshold-Verfahren nicht sichtbar gemacht werden. Ich bin aber fast sicher, dass mit etwas mehr Mathematik auch der gesamte Schriftzug entschlüsselt werden kann. olby schrieb: > Theoretisch ließe sich das bestehende Pixelfeld mit dem neu gesendeten > Feld modulieren, so daß ein ganz neues Feld vorliegt. Das jeweils neue > Feld kennen dann nur Absender und Empfänger. Einmal zu Anfang ein > Pixelfeld erzeugt, würde das ausreichen für eine sichere Codierung auch > aller nachfolgender Übetragungen. Meiner Meinung nach ist die > Übertragung für Dritte dann nicht zu entschlüsseln Ich habe das zwar nicht im Detail verstanden, es scheint mir aber eine ganz schlechte Idee zu sein. Da passiert dann evtl. etwas Ähnliches wie wenn jemand beide der obigen verschlüsselten Dateien (olbi.png und document_verschluesselt.png) gleichzeitig in die Hände bekommt. Dann erstellt man (mit Gimp) einfach die Defferenz der beiden Bilder und erhält olbi-document_verschluesselt.png. Du kannst ja mal ein paar Beispiele posten (nur die jeweils verschlüsselten Dateien ohne die Originale und ohne die Schlüsseldatei). olby schrieb: >> Was ist davon zu halten? Ich habe eine Ahnung von Verschlüsselung. > > "keine Ahnung" soll es natürlich heißen. Ich habe davon auch keine Ahnung, deswegen versuche ich gar nicht erst ernsthaft, neue Verschlüsselungsverfahren zu erfinden.
:
Bearbeitet durch Moderator
Yalu X. schrieb: > Ich habe davon auch keine Ahnung, deswegen versuche ich gar nicht erst > ernsthaft, neue Verschlüsselungsverfahren zu erfinden. Dann werde ich das zukünftig auch sein lassen. Danke für die Aufklärung. L.G.
Yalu X. schrieb: > Wenn ich jeweils nur den ersten Layer hernehme (olbi.png bzw. > document_verschluesselt.png) und den zweiten nicht kenne, sollte daraus > das Originalbild ja eigentlich nicht rekonstruierbar sein. Es geht aber > (zumindest ansatzweise) dennoch, indem man auf die verschlüsselten > Bilder die Threshold-Funktion von Gimp mit den Thresholds 1 und 254 und > dem Channel RGB anwendet (theshold.png). Damit entstehen die Bilder > olbi-threshold.png und document_verschluesselt-threshold.png. Hallo Yalu X., sei doch bitte so freundlich, und überprüfe auch einmal diese Übermittlung im Anhang, ob das Originalbild auch hier rekonstuierbar ist. Vielleicht kannst Du dazu etwas sagen? Ich habe mich inzwischen so lange mit dem Thema beschäftigt...da hätte ich das auch noch ganz gern gewußt. Vielen Dank. L. G.
Ich hab's noch mal mit einem anderen Bild überprüft. Die Nachricht scheint auch bei indiziertem Bild rekonstruierbar zu sein. Zwar nicht so deutlich, aber wohl möglich.
Yalu X. schrieb: > olby schrieb: >> Theoretisch ließe sich das bestehende Pixelfeld mit dem neu gesendeten >> Feld modulieren, so daß ein ganz neues Feld vorliegt. Das jeweils neue >> Feld kennen dann nur Absender und Empfänger. Einmal zu Anfang ein >> Pixelfeld erzeugt, würde das ausreichen für eine sichere Codierung auch >> aller nachfolgender Übetragungen. Meiner Meinung nach ist die >> Übertragung für Dritte dann nicht zu entschlüsseln > > Ich habe das zwar nicht im Detail verstanden, es scheint mir aber eine > ganz schlechte Idee zu sein. Da passiert dann evtl. etwas Ähnliches wie > wenn jemand beide der obigen verschlüsselten Dateien (olbi.png und > document_verschluesselt.png) gleichzeitig in die Hände bekommt. Dann > erstellt man (mit Gimp) einfach die Defferenz der beiden Bilder und > erhält olbi-document_verschluesselt.png. > > Du kannst ja mal ein paar Beispiele posten (nur die jeweils > verschlüsselten Dateien ohne die Originale und ohne die Schlüsseldatei). > Dieses Dokument hat 26 Zeilen. Ich habe den Layer noch mal überprüft auf Schwellwertempfindlichkeit. Es sind leichte Schatten zu erkennen, wo sich die Schriftzüge befinden. Die sind aber sehr schwach. Vielleicht siehst du mit deinem neuen Gimp mehr als ich mit meiner alten 9.6er Version? Meinst Du, daß jemandem die Dechiffrierung des Textes gelingen könnte? Ich habe mich etwas unklar ausgedrückt. Vielleicht so besser?: Nachdem die erste Nachricht verschickt wurde, erfolgt eine zweite. Dieser Layer setzt sich zusammen aus der Codierung des ursprünglichen Pixelfeldes mit einem neu generierten Feld. Das Ergebnis ist ein völlig neu entstandenes Feld, das nun gesendet wird. Der Empfänger kann dann mit dem alten Pixelfeld, das ihm ja vorliegt, das neu generierte Pixelfeld rausfiltern. So haben beide, der Empfänger und der Sender, das gleiche neue Feld für die zukünftige Übertragung vorliegen. Das alte kann dann gelöscht werden... usw. fortlaufend. M. E. kann ein Dritter die Nachricht nicht lesen und auch das neue Feld nicht sehen. Könnte mich jemand wieder auf den Boden der Realität zurückzuholen? L. G.
Yalu X. schrieb: > Ich habe das zwar nicht im Detail verstanden, es scheint mir aber eine > ganz schlechte Idee zu sein. Da passiert dann evtl. etwas Ähnliches wie > wenn jemand beide der obigen verschlüsselten Dateien (olbi.png und > document_verschluesselt.png) gleichzeitig in die Hände bekommt. Dann > erstellt man (mit Gimp) einfach die Defferenz der beiden Bilder und > erhält olbi-document_verschluesselt.png. In dem Fall sind beide Pixelfelder (untere Ebene) für die Erstellung der beiden Übertragungen dieselben. Nach meinem Vorschlag jedoch nicht. Das zweite Bild ist ja mit einem anderen Pixelfeld erzeugt worden. Habe ich einen Denkfehler gemacht?
@ Yalu X. Auf diesem Bild kann ich auch keine Schatten mehr feststellen. Jetzt habe ich so viel Zeit inverstiert, da hoffe ich, daß das Bild auch wirklich sicher ist.
olby schrieb: > Vielleicht siehst du mit deinem neuen Gimp mehr als ich mit meiner > alten 9.6er Version? Meinst Du, daß jemandem die Dechiffrierung des > Textes gelingen könnte? Das Beste, was ich mit dem Threshold-Trick hinbekommen habe, ist das im Anhang gezeigte. Da ist tatsächlich nicht allzu viel sichtbar. Ich kann mir aber vorstellen, dass man mit aufwendigeren Methoden noch mehr herausholen kann. Es ist halt immer die Frage, wieviel Zeit man in so etwas hineinstecken möchte. Je wertvoller der geheime Inhalt ist, desto größer werden die von den Angreifern aufgefahrenen Geschütze sein. olby schrieb: > Ich habe mich etwas unklar ausgedrückt. > Vielleicht so besser?: Ich habe in deinem Text mal die einzelnen Bilder, Nachrichten, Pixelfelder, Layer – oder wie auch immer man sie nennt – nach meinem Verständnis mit Buchstaben gekennzeichnet, damit klarer wird, welche davon sich auf dasselbe Bild beziehen und welche nicht. Für das Zusammensetzen von zwei Bildern mit dem Gimp-Modus "Unterschied" (deutsch) bzw. "Difference" (englisch) habe ich dem Operator "absdiff" (absolute Differenz) verwendet. > Nachdem die erste Nachricht (A) verschickt wurde, erfolgt eine zweite > (C). Dieser Layer setzt sich zusammen aus der Codierung des > ursprünglichen Pixelfeldes (A) mit einem neu generierten Feld (B). Das > Ergebnis (C) ist ein völlig neu entstandenes Feld, das nun gesendet > wird. A ist also der Schlüssel und B das Bild mit den geheimen Informationen. Der werden zusammengesetzt zu einem neuen Bild C: C = A absdiff B Der Sender sendet nun A und C getrennt voneinander an den Empfänger. Dabei verwendet er für den Schlüssel A einen abhörsicheren Kanal, damit ein Angreifer keinesfalls A und B gleichzeitig in die Hände bekommt (bspw. übergibt der Sender den Schlüssel A dem Empfänger persönlich auf einem USB-Stick). C hingegen kann auf einem unsicheren Kanal (bspw. per E-Mail) versandt werden, da der Angreifer mit C alleine (ohne A) nichts anfangen kann. > Der Empfänger kann dann mit dem alten Pixelfeld (A), das ihm ja > vorliegt, das neu generierte Pixelfeld (B) rausfiltern. Der Empfänger verknüpft also die beiden empfangenen Bilder C und A und erhält damit das Bild B', das ähnlich wie B aussieht: B' = C absdiff A = (A absdiff B) absdiff A ≈ B B' ist (wenn auch etwas verrauscht) für den Empfänger lesbar, damit ist B erfolgreich übertragen worden. > So haben beide, der Empfänger und der Sender, das gleiche neue Feld > (B') für die zukünftige Übertragung vorliegen. Das alte (A) kann dann > gelöscht werden... usw. fortlaufend. Wenn ich dich richtig verstanden habe, möchtest du nun C anstelle von A als neuen Schlüssel verwenden. Wenn der Sender nun eine weitere geheime Information (D) senden möchte, verknüpft er diese mit dem neuen Schlüssel C: E = C absdiff D und sendet E auf einem unsicheren Kanal an den Empfänger. Dieser verknüpft das empfangene Bild E mit dem ihm bereits bekannten Schlüssel D zu D', das ähnlich wie D aussieht: D' = E absdiff C = (C absdiff D) absdiff C ≈ D Damit kann der Empfänger nun auch diese Informationen lesen. Habe ich das soweit richtig verstanden? Wenn ja: Es ist nun davon auszugehen, dass der Angreifer die Bilder C und E abgegriffen hat, da diese über einen unsicheren Kanal übertragen wurden. Er bildet nun die Verknüpfung D'' = C absdiff E = C absdiff (C absdiff D) ≈ D D'' ist damit für den Angreifer lesbar, so dass er nun den Inhalt von D kennt. Jedes weitere vom Sender nach diesem Verfahren übertragene Bild kann der Angreifer ebenso entschlüsseln. Nur das erste geheime Bild (B) bleibt dem Angreifer verborgen, denn dazu müsste er den ursprünglichen Schlüssel A kennen, der aber über einen sicheren Kanal übertragen wurde. olby schrieb: > Auf diesem Bild kann ich auch keine Schatten mehr feststellen. > Jetzt habe ich so viel Zeit inverstiert, da hoffe ich, daß das Bild auch > wirklich sicher ist. Ich kann darin auch nichts mehr erkennen, was aber nichts heißen muss. Poste hier doch einfach mal deine mit deinem Verfahren verschlüsselten Bankkontodaten inkl. PIN. Wenn du nach ein paar Tagen feststellst, dass dein Konto leergeräumt wurde, weißt du, dass du an deinem Verfahren noch etwas feilen musst :)
Yalu X. schrieb: > Poste hier doch einfach mal deine mit deinem Verfahren verschlüsselten > Bankkontodaten inkl. PIN. Wenn du nach ein paar Tagen feststellst, dass > dein Konto leergeräumt wurde, weißt du, dass du an deinem Verfahren noch > etwas feilen musst :) Ein guter Vorschlag. Aber soweit möchte ich doch nicht gehen. Deinen kompletten Post muß ich erstmal verdauen. Da werde ich noch eine Weile für brauchen. Aber recht herzlichen Dank schon mal für die Stellungnahme. L. G.
man sieht z.B. in diesem Bild https://www.mikrocontroller.net/attachment/530219/document_verschluesselt.png sich wiederholende Muster. so leicht horizontal versetzt. fast wie bei einer 3D-Brille. das ist nicht gut, wenns um Verschlüsselungen geht
:
Bearbeitet durch User
●DesIntegrator ●. schrieb: > man sieht z.B. in diesem Bild > > https://www.mikrocontroller.net/attachment/530219/document_verschluesselt.png > > sich wiederholende Muster. so leicht horizontal versetzt. > fast wie bei einer 3D-Brille. > > das ist nicht gut, wenns um Verschlüsselungen geht Auf meinen Bildern ist das Muster ist nicht versetzt! Da wiederholt sich nichts.
Angehängte Dateien:
-
rauschen.png
610 KB
also richtiges Rauschen sieht zumindest noch irgendwie anders aus. Bei den oben gezeigten Bildern sieht man schon noch gewisse regelmässige Strukturen
:
Bearbeitet durch User
Yalu X. schrieb: >> Der Empfänger kann dann mit dem alten Pixelfeld (A), das ihm ja >> vorliegt, das neu generierte Pixelfeld (B) rausfiltern. > > Der Empfänger verknüpft also die beiden empfangenen Bilder C und A und > erhält damit das Bild B', das ähnlich wie B aussieht: > > B' = C absdiff A = (A absdiff B) absdiff A ≈ B > > B' ist (wenn auch etwas verrauscht) für den Empfänger lesbar, damit ist > B erfolgreich übertragen worden. > >> So haben beide, der Empfänger und der Sender, das gleiche neue Feld >> (B') für die zukünftige Übertragung vorliegen. Das alte (A) kann dann >> gelöscht werden... usw. fortlaufend. > > Wenn ich dich richtig verstanden habe, möchtest du nun C anstelle von A > als neuen Schlüssel verwenden. Wenn der Sender nun eine weitere geheime > Information (D) senden möchte, verknüpft er diese mit dem neuen > Schlüssel C: > > E = C absdiff D > > und sendet E auf einem unsicheren Kanal an den Empfänger. Dieser > verknüpft das empfangene Bild E mit dem ihm bereits bekannten Schlüssel > D zu D', das ähnlich wie D aussieht: > > D' = E absdiff C = (C absdiff D) absdiff C ≈ D > > Damit kann der Empfänger nun auch diese Informationen lesen. Das ist so nicht richtig. Für jede neue Übertragung wird ein ganz neues Pixelfeld verwendet (für beide Seiten). Das wurde neu generiert und codiert. Da stecken jeweils neue Informationen drin, die durch einen Vergleich miteinander nicht sichtbar gemacht werden können. Für mich ist das auch schwer nachvollziehbar. Vielleicht kann man das übersichtlich mit Hilfe einer Grafik darstellen?
Wenn du in den Halbbildern Transparenz einfügst kannst du die Bilder mit ein bisschen html und css übereinander legen.
olby schrieb: > Das ist so nicht richtig. Für jede neue Übertragung wird ein ganz neues > Pixelfeld verwendet (für beide Seiten). Dann habe ich dich bisher falsch verstanden. Wenn das Schlüsselpixelfeld jedes´mal neu generiert wird, ist das in Ordnung. Allerdings bedeutet das eben auch, dass dieses Pixelfeld von demjenigen, der es generiert, irgendwie zu seinem Kommunikationspartner gelangen muss, den es bringt ja nichts, wenn Sender und Empfänger unabhängig voneinander ihre eigenen, völlig verschiedenen Pixelfelder generieren. Wenn es aber einen sicheren Weg gibt, das Schlüsselpixelfeld zu übertragen, kann derselbe Weg auch dazu genutzt werden, gleich die geheimen Daten unverschlüsselt zu übertragen. Das ist der Grund, warum OTP-Verfahren für die Übertragung von Daten zwischen einem Sender und einem Empfänger nicht immer praktikabel sind. Was aber natürlich geht: Der Sender übergibt dem Empfänger einmal persönlich eine große Menge (bspw. 1 GByte) an Schlüsseldaten. Diese können dann nach und nach für die Übertragung kleinerer Nachrichten genutzt werden (bspw. für 1000 Nachrichten à 1 MByte). Irgendwann wird der Pool an Schlüsseldaten aufgebraucht sein, dann müssen sich Sender und Empfänger wieder treffen, um einen neuen Satz von Schlüsseldaten auszutauschen.
:
Bearbeitet durch Moderator
Yalu X. schrieb: ... > Wenn das Schlüsselpixelfeld jedes´mal neu generiert wird, ist das in > Ordnung. Allerdings bedeutet das eben auch, dass dieses Pixelfeld von > demjenigen, der es generiert, irgendwie zu seinem Kommunikationspartner > gelangen muss, den es bringt ja nichts, wenn Sender und Empfänger > unabhängig voneinander ihre eigenen, völlig verschiedenen Pixelfelder generieren... Das ist gerade der Punkt, auf den es mir ankommt. Der Empfänger generiert kein völlig neues Pixelfeld, sondern decodiert aus dem neu übertragenen Pixelfeld des Senders ein Pixelfeld, welches er für die Decodierung des nächsten Bildes benötigt. Für die Decodierung des Pixelfeldes zieht er dabei das letzte aktuelle Pixelfeld heran. Das ändert sich ja mit jeder zweiten Übertragung. Man darf nicht vergessen, eine Übermittlung besteht aus zwei Bildern. Einmal die Nachricht, das andere Mal das neue codierte Pixelfeld. Die nächste Übertragung besteht dann ebenfalls wieder aus zwei Bildern. Ich muß ganz ehrlich sagen, daß ich derzeit nicht in der Lage bin, meine eigene Theorie selber völlig zu durchschauen. Diese vielen Differenzbildungen der Farben, zusammen mit weiteren Differenzbildungen bei der Codierung/Decodierung, haben mich schon gehörig durcheinander gebracht. In dem Punkt habe ich aber ein wenig Hoffnung, daß das funktionieren könnte. Allerdings, wenn es darum geht, ob der Angreifer nicht doch das Pixelfeld durch Differenzbildung zweier Nachrichten erfahren könnte, da bin ich völlig unsicher. Ob das möglich sein könnte, das durchschaue ich im Moment einfach nicht. Da muß noch mal etwas Zeit vergehen, wenn mir das jemals klar werden sollte. Die einzige Möglichkeit, daß zu veranschaulichen, sehe ich nur im Erstellen einer Skizze, so eine Art Blockschaltbild, wie es die Elektroniker aus der Funktechnik machen bei der Umsetzung von Trägerfrequenzen. " Der Empfänger verknüpft also die beiden empfangenen Bilder C und A und erhält damit das Bild B', das ähnlich wie B aussieht: B' = C absdiff A = (A absdiff B) absdiff A ≈ B " Ich schlage vor, erstmal das "Ungefährzeichen" wegzulassen und von verlustfreier Übertragung auszugehen. Die Materie an sich ist schon schwierig genug. Das lenkt nur ab. Natürlich könnten Verluste das ganze Projekt zunichte machen. Diese zu eliminieren wäre eine weitere Aufgabe. Aber eins ist jetzt schon klar: Die Übertragung hat im GIMP-eigenen Format zu erfolgen. Mit jpg ist das nichts zu wollen. Bestenfalls für ein- oder zwei Bilder in bescheidener Qualität. Mein letzter Post im GIMP-Format hat beachtliche 13,5 MB. Ich bin ja kein Gimp-Entwickler, kann mir aber vorstellen, daß bei dieser Größenordung eine Menge Redundanz vorhanden ist. (Kann man Redundanz dazu sagen?) Meine einfache Anfrage hat sich jetzt zu einer anspruchsvollen Sache entwickelt, so daß ich mit der Vervollkommnung der Angelegenheit selber überfordert bin. Falls es wirklich funktionieren sollte ???? was mir so vorschwebt, dann müßten andere, bessere Leute das weiterentwickeln. Wenn es doch gehen sollte, also absolut sicher wäre, und die Verkettung der Nachrichten verlustfrei wäre, fände ich, wäre das schon eine tolle Sache. Die Geheimdienste wären außen vor, Mafiosi würden sich freuen, das Bankwesen....., keine Schlüsselmerkerei mehr, absolute Sicherheit bei E-mail Übertragungen, kostet nix. Bitte das Gesagte zum Schluß nicht ernst nehmen. Ich habe mal wieder zu viel Phantasie. Wenn es möglich wäre, dann würde es das schon längst geben. Da braucht es keinen Olby für. L.G.
Aber was die Sicherheit einer Einzelübertragung anbelangt, hätte ich doch gerne gewußt, ob es jemand gelingt, das Bild in meinem Post vom 15.09.2021 07:49 zu dechiffrieren.
Ich habe noch einmal darüber nachgedacht. Da ich zu keinem Ergebnis gekommen bin, bin ich zur Überzeugung gelangt, daß nur eine Einmalübertragung wirklich sicher sein kann. Damit hat sich mein Vorschlag mit der Pixelfeldcodierung erledigt.
olby schrieb: > Das ist gerade der Punkt, auf den es mir ankommt. Der Empfänger > generiert kein völlig neues Pixelfeld, sondern decodiert aus dem neu > übertragenen Pixelfeld des Senders ein Pixelfeld, welches er für die > Decodierung des nächsten Bildes benötigt. Für die Decodierung des > Pixelfeldes zieht er dabei das letzte aktuelle Pixelfeld heran. Das macht die Sache zwar komplizierter, aber nicht sicherer. Aber vielleicht verstehe ich das Vorgehen immer noch nicht ganz. Poste doch einfach mal ein Beispiel mit den jeweiligen Dateien, die da jeweils übertragen werden. > Ich schlage vor, erstmal das "Ungefährzeichen" wegzulassen und von > verlustfreier Übertragung auszugehen. Das Ungefährzeichen habe ich wegen möglicher Übertragungsfehler verwendet, sondern weil bei zweimaliger Anwendung der Differenzbildung (einmal bei der Ver- und einmal bei der Entschlüsselung) nicht das Originalbild herauskommt, sondern etwas, was nur grob ähnlich aussieht (aber immerhin gut genug ist den Text im Bild lesbar zu machen). > Aber eins ist jetzt schon klar: Die Übertragung hat im GIMP-eigenen > Format zu erfolgen. Mit jpg ist das nichts zu wollen. Ja, JPEG taugt dafür nicht, weil es verlustbehaftet wird. Du kannst aber bspw. PNG verwenden. Das zwar größer als JPEG, aber i.Allg. deutlich kleiner als XCF, da es im Wesentlichen nur die reinen Pixelinformationen enthält. XCF hingegen enthält noch einige an zusätzlichen Informationen, die in deinem Anwendungsfall nicht so wichtig sind: https://de.wikipedia.org/wiki/XCF olby schrieb: > Aber was die Sicherheit einer Einzelübertragung anbelangt, hätte ich > doch gerne gewußt, ob es jemand gelingt, das Bild in meinem Post vom > 15.09.2021 07:49 zu dechiffrieren. Da steht sechsmal der folgende Text:
1 | Herr Präsident, meine Damen und Herren, liebe |
2 | [N-Wort]! |
3 | Ich freue mich, am heutigen Tage hier zu sein. |
4 | ??er??n??? ähm, ähm, ähm |
Bei den Fragezeichen bin ich mir nicht sicher. Die dritte Zeile könnte bspw. lauten:
1 | Hier in ... ähm, ähm, ähm |
Yalu X. schrieb: > Das zwar größer als JPEG, aber i.Allg. deutlich > kleiner als XCF, da es im Wesentlichen nur die reinen Pixelinformationen > enthält. Man kann auch ein XCF als .xcf.bz2 abspeichern, dann wird es deutlich kleiner.
Yalu X. schrieb: >
1 | > Herr Präsident, meine Damen und Herren, liebe |
2 | > [N-Wort]! |
3 | > Ich freue mich, am heutigen Tage hier zu sein. |
4 | > ??er??n??? ähm, ähm, ähm |
5 | > |
> > Bei den Fragezeichen bin ich mir nicht sicher. Die dritte Zeile könnte > bspw. lauten: > > >
1 | > Hier in ... ähm, ähm, ähm |
2 | > |
Jetzt bin ich auch meiner restlichen Illusionen vollständig beraubt. Wie hast Du das gemacht?????
Angehängte Dateien:
olbi schrieb: > Wie hast Du das gemacht????? Das angehängte Python-Programm macht alle Pixel mit seltenen Farben (d.h. Farben, die im Gesamtbild höchstens 10-mal vorkommen) weiß, alle anderen schwarz. Mit etwas Phantasie kann man nun etliche der Buchstaben erkennen. Leider bleiben horizontale und vertikale Abschnitte der Umrisslinien der Buchstaben größtenteils unsichtbar. Umgekehrt schränkt dies aber auch die Möglichkeiten, die Buchstabenfragmente zu vollständigen Buchstaben zu ergänzen, ein, was die Rekonstruktion wieder etwas erleichtert. An den Stellen, wo überhaupt keine Buchstaben sichtbar sind, obwohl man dort welche erwarten würde, kommen nur solche Buchstaben in Frage, die ausschließlich aus horizontalen und vertikalen Linien zusammengesetzt sind, also E, F, H, I, L, T, i, oder l. Damit und mit etwas Galgenmännchenerfahrung lässt sich der größte Teil des Texts relativ sicher erraten.
:
Bearbeitet durch Moderator
Yalu X. schrieb: > olbi schrieb: >> Wie hast Du das gemacht????? > > Das angehängte Python-Programm macht alle Pixel mit seltenen Farben > (d.h. Farben, die im Gesamtbild höchstens 10-mal vorkommen) weiß, alle > anderen schwarz. Mit etwas Phantasie kann man nun etliche der Buchstaben > erkennen. > > Leider bleiben horizontale und vertikale Abschnitte der Umrisslinien der > Buchstaben größtenteils unsichtbar. Umgekehrt schränkt dies aber auch > die Möglichkeiten, die Buchstabenfragmente zu vollständigen Buchstaben > zu ergänzen, ein, was die Rekonstruktion wieder etwas erleichtert. > > An den Stellen, wo überhaupt keine Buchstaben sichtbar sind, obwohl man > dort welche erwarten würde, kommen nur solche Buchstaben in Frage, die > ausschließlich aus horizontalen und vertikalen Linien zusammengesetzt > sind, also E, F, H, I, L, T, i, oder l. > > Damit und mit etwas Galgenmännchenerfahrung lässt sich der größte Teil > des Texts relativ sicher erraten. Vielen Dank für Deine Arbeit. Ich möchte mich mit meinem Scheitern jedoch nicht so ohne weiteres abfinden. Es ist einfach zu schade, die Sache aufzugeben. Ich werde noch einen neuen Versuch starten. Ob das sinnvoll ist, kann ich im Moment nicht sagen. Ich muß erst noch einmal über deine Erklärungen zur Dechiffrierung nachdenken. Es kann also noch etwas dauern, bis ich mich wieder melde. Ich hatte ein in den Beiträgen vorgegebenes Pixelfeld benutzt. Jetzt möchte ich das Feld selber generieren. Wie macht man das mit GIMP? Könnte mir das jemand sagen? Das würde mir viel Rumprobiererei ersparen. Zudem glaube ich, hätte ich vieles besser machen können. L. G. HM schrieb: > olby schrieb: >> ...dann noch dieses Layout in schwarz...furchtbar! > > Edit > Preferences > Interface > Theme > dann ein anderes als "Dark" > auswählen, z.B. "System". Vielen Dank für den Tip. Jetzt sieht das schon ganz anders aus. Ein wirklich mächtiges Programm ist die neue Version 9.10. L.G.
Angehängte Dateien:
-
sicher.jpg
220 KB
Yalu X. schrieb: > olby schrieb: >> Das ist gerade der Punkt, auf den es mir ankommt. Der Empfänger >> generiert kein völlig neues Pixelfeld, sondern decodiert aus dem neu >> übertragenen Pixelfeld des Senders ein Pixelfeld, welches er für die >> Decodierung des nächsten Bildes benötigt. Für die Decodierung des >> Pixelfeldes zieht er dabei das letzte aktuelle Pixelfeld heran. > > Das macht die Sache zwar komplizierter, aber nicht sicherer. Aber > vielleicht verstehe ich das Vorgehen immer noch nicht ganz. Poste doch > einfach mal ein Beispiel mit den jeweiligen Dateien, die da jeweils > übertragen werden. > Guten Abend, ich melde mich in der Sache noch mal. Der Empfänger hat zwei Schlüssel, einen für die Nachricht (Schlüssel 1N, einen für das Pixelfeld (Schlüssel 1P). Der Sender ebenso. Die erste Übermittlung (Nachricht) wird wie gehabt verschlüsselt mit (Schlüssel 1N) gesendet, und vom Empfänger mit seinem (Schlüssel 1N) decodiert. Dann folgt eine zweite Übermittlung mit Schlüssel 1P für's Pixelfeld, dann eine dritte, eine vierte usw. Ich habe mal eine Skizze beigefügt, wie ich mir das so denke. Vielleicht könntest Du mal schauen, was von dieser Methode zu halten ist? Es werden bei paarweise Übertragung immer wieder neue Felder generiert und versendet. Vermutlich wird es wohl nicht funktionieren??? Warum du meine Verschlüsselung mit Hilfe eines Progammes so leicht knacken konntest, glaube ich jetzt zu wissen. Da habe ich einen Fehler gemacht... L. G. Olbi
Warum verwendest du nicht einfach einen Passwortmanager zB. Keepass? Da kannst du Passwörter auch viel komfortabler auschecken...
F. M. schrieb: > Warum verwendest du nicht einfach einen Passwortmanager zB. > Keepass?.. Dazu habe ich mich doch schon mehrmals geäußert.
@Yalu X. Ich bin etwas verunsichert. Es wird wohl nicht gehen, so wie vorgeschlagen? Codiert und decodiert wird durch Differenzbildung der Farben auf beiden Seiten, also einmal im Sender und einmal im Empfänger. Wenn ich nun die Differenzen benachbarter Übertragungskanäle (für den Angreifer sichtbar) bilde, könnte dann eventuell die Nachricht zum Vorschein kommen?
Angehängte Dateien:
-
sicher2.jpg
210 KB
Nachdem ich noch mal darüber geschlafen habe, muß ich feststellen: Es geht nicht. Wenn ich Übertragung 2 von Übertragung 3 abziehe, kommt die Nachricht für den Angreifer zum Vorschein. So schön wie ich es mir gedacht habe, geht es leider nicht. Ich beende das Projekt nun endgültig.
Trotzdem wäre es schön, wenn Yalu x. noch mal einen Blick auf die neue Zeichnung wirft. Viele Grüße Olby
olby schrieb: > Trotzdem wäre es schön, wenn Yalu x. noch mal einen Blick auf die neue > Zeichnung wirft. In der Differenz der Übertragungen 2, 3 und 4 sollten die Nachrichten 2 und 3 erkennbar sein. Nein, das wird so nichts. Bei OTP- und verwandten Verfahren, zu denen auch deine gehören, braucht man für jede Übertragung eine neue Schlüsseldatei, da beißt die Maus keinen Faden ab. Um n Bilder zu übertragen, brauchst du also n Schlüsseldateien. Du gehst nun davon aus, dass eine davon bereits zu Beginn dem Sender und dem Empfänger bekannt ist, die restlichen n-1 möchtest du verschlüsselt übertragen. Dazu brauchst du aber n-1 weitere Schlüsseldateien. Um diese zu übertragen, brauchst du nochmals n-1 Schlüsseldateien usw. Fazit: Schlüsseldateien kann man mit OTP-Verfahren nicht übertragen, da sich bei dieser Übertragung Nutzen (1 weitere Schlüsseldatei beim Empfänger bekannt) und Kosten (1 Schlüsseldatei verbraucht) gegenseitig aufheben, so dass damit überhaupt nicht gewonnen wird. Du kannst natürlich noch weitere, ähnliche Verfahren ausprobieren, du kannst deine Zeit aber genauso gut in die Entwicklung eines Perpetuum Mobile stecken. Letzteres hat den Vorteil, dass du im Erfolgsfall ein reicher Mann sein wirst ;-)
:
Bearbeitet durch Moderator
Ich glaube, ich habe es jetzt verstanden. Ich schütze zwar die Nachricht mit den immer neu generierten Pixelfeldern, aber die Pixelfelder selber, die ja auch eine Art Nachricht darstellen, sind nicht gesichert.
Nachdem ich eine Nacht darüber geschlafen habe, sehe ich die Sache wieder anders. Die "ONE-Time" Übertragung ist einleuchtend: Während der Schlüssel sämtliche Farbpixel des Pixelfeldes umfaßt, werden für die Nachricht nur ein Bruchteil aller zur Verfügung stehenden Farbpixel verwendet, eben nur für Schrift und/oder Zahlen. Die Zwischenräume enthalten dann Farbpixel des Schlüssels. Dann ist es klar, wenn mehrmals Nachrichten mit ein und demselben Schlüssel versendet werden, braucht der Angreifer nur die Pixelfelder mit den Nachrichten speichern und dann miteinander vergleichen, welche Art Farbpixel immer wieder an derselben Stelle auftauchen. Somit kann der Angreifer nach einigen Übermittlungdn nach und nach den Gesamtschlüssel, also das komplette Pixelfeld des Schlüssels rekonstruieren. Wenn aber die Nachricht aus einem kompletten (codierten) Schlüsselfeld besteht, das ebenso groß ist wie der Schlüssel selber, wüßte ich nicht, wie bei mehrmaliger bzw. häufiger Übertragung jemals der Schlüssel durch Vergleich rekonstruiert werden könnte. Der Angreifer kann nicht einen einzigen originalen Hintegrundfarbpixel sehen, egal wie oft neue Schlüssel gesendet werden. So könnte man m. E. beliebig viele sichere Übertragungen machen mit nur einem Grundschlüssel, vorausgesetzt, die Nachricht umfaßt das ganze Pixelfeld. Was habe ich dabei übersehen? L.G.
Die Abneigung gegen PW Manager verstehe ich trotz (oder wegen) der Ausführungen nicht - der Thread war aber m.E. ein gutes Beispiel dafür, das es zu 99.9% eine dumme Idee ist, selber Crypto zu erfinden (oder sogar nur zu implementieren). Für diese Demonstration in der Praxis vielen Dank - und das meine ich nicht abwertend. Manchmal muss eben handfest erfahren das eine Idee nicht funktioniert.
olby schrieb: > Wenn aber die Nachricht aus einem kompletten (codierten) Schlüsselfeld > besteht, das ebenso groß ist wie der Schlüssel selber, wüßte ich nicht, > wie bei mehrmaliger bzw. häufiger Übertragung jemals der Schlüssel durch > Vergleich rekonstruiert werden könnte. Den Schlüssel kann man damit nicht rekonstruieren, aber die Verknüpfung von zwei Nachrichten. Das Ergebnis sieht dann ähnlich aus wie hier: https://www.mikrocontroller.net/attachment/530225/olbi-document_verschluesselt.png Darin sind zwei Nachrichten (einmal "Olbi" und einmal "Olby") ineinander verwoben, was das Lesen zwar etwas erschwert, aber nicht unmöglich macht. Selbst wenn ein paar wenige Buchstaben nicht eindeutig identifiziert werden können (im Beispiel das "l" von "Olby", da ebenso ein "i" sein könnte), lassen sich diese oft aus dem Kontext erraten. Bei einem guten Verschlüsselungsverfahren kann der Angreifer absolut überhaupt nichts von der Nachricht lesen, nicht einmal 0,01% davon.
Yalu X. schrieb: > Den Schlüssel kann man damit nicht rekonstruieren, aber die Verknüpfung > von zwei Nachrichten. Das Ergebnis sieht dann ähnlich aus wie hier: > > https://www.mikrocontroller.net/attachment/530225/olbi-document_verschluesselt.png Nein, so sehe ich das nicht. In dem Beispiel sind die beiden Schriftzüge ineinandergewoben nur sichtbar, weil ein und derselbe Hintergrund (Schlüssel) verwendet wurde, also ein- und derselbe Schlüssel. Durch Differenzbildung beider oberer Bilder hat sich der Schlüssel in den Bereichen außerhalb der Nachricht dann gegenseitig aufgehoben, sodaß nur noch nur noch die beiden Nachrichten sichtbar waren. Alles andere ist schwarz. Bei zwei verschiedenen Hintergründen, wäre eine Decodirung nicht möglich gewesen. Zwei Bilder mit zwei verschiedenen Schlüsseln können m. E. so nicht sichtbar gemacht werden.
Ich möchte daran festhalten, daß man beliebig viele Schlüssel mit nur einem Grundschlüssel sicher übertragen werden können, wenn die Nachricht ein maximales Pixelfeld beinhaltet. Was habe ich übersehen?
Ich habe schon wieder Zweifel bekommen. Ich glaube, das Thema lasse ich jetzt sein.
olby schrieb: > Yalu X. schrieb: > >> Den Schlüssel kann man damit nicht rekonstruieren, aber die Verknüpfung >> von zwei Nachrichten. Das Ergebnis sieht dann ähnlich aus wie hier: >> >> > https://www.mikrocontroller.net/attachment/530225/olbi-document_verschluesselt.png > > Nein, so sehe ich das nicht. > In dem Beispiel sind die beiden Schriftzüge ineinandergewoben nur > sichtbar, weil ein und derselbe Hintergrund (Schlüssel) verwendet wurde, > also ein- und derselbe Schlüssel. Durch Differenzbildung beider oberer > Bilder hat sich der Schlüssel in den Bereichen außerhalb der Nachricht > dann gegenseitig aufgehoben, sodaß nur noch nur noch die beiden > Nachrichten sichtbar waren. > Alles andere ist schwarz. ... Das ist dann auch ein Beispiel dafür, was passieren kann, wenn beim "ONE-Time" Verfahren zweimal derselbe Schlüssel verwendet wird.
Belmondo schrieb: > Die Abneigung gegen PW Manager verstehe ich trotz (oder wegen) der > Ausführungen nicht - der Thread war aber m.E. ein gutes Beispiel dafür, > das es zu 99.9% eine dumme Idee ist, selber Crypto zu erfinden (oder > sogar nur zu implementieren). Für diese Demonstration in der Praxis > vielen Dank - und das meine ich nicht abwertend. Manchmal muss eben > handfest erfahren das eine Idee nicht funktioniert. Aber was spricht gegen den Versuch, mal eine Sache gründlich zu verstehen?
Angehängte Dateien:
-
zwei_Woerter_unten.png
220 KB -
zwei_Woerter_oben.png
220 KB
Jetzt noch mal ganz zum Schluß. Dann ist das Thema endgültig erledigt. Hier noch mal eine Übermittlung im PNG-Format, womit ich mir richtig Mühe gegeben habe. Wenn Yalu X. vielleicht noch mal mit seinem Programm das obere Bild überprüfen könnte? Vielen Dank.
Angehängte Dateien:
-
Test.jpg
370 KB
nach langem suchen hab ich das Programm welches ein Bild invertiert, in Blöcke zerlegt und diese dann verwürfelt wieder gefunden. Es gibt noch eine Reihe anderer Parameter die man einstellen kann. Wer Lust hat kann sich ja mal daran versuchen, ich löse es später auf. Gefunden hab ich auch noch Picture to sound. Auch nicht ganz uninteressant.
olby schrieb: > Ich glaube, ich habe es jetzt verstanden. > Ich schütze zwar die Nachricht mit den immer neu generierten > Pixelfeldern, > aber die Pixelfelder selber, die ja auch eine Art Nachricht darstellen, > sind nicht gesichert. Nach den neuen Erkenntnissen ist das aber auch gar nicht erforderlich. Bei der Übermittlung einer Nachricht in Pixelfeldgröße kann die Nachricht auch bei Mehrfachübertragung nicht vom Angreifer decodiert werden.
Angehängte Dateien:
@Yalu X. Hallo Yalu X., ich habe noch einmal eine neue Zeichnung gemacht, wie ich mir das so denke. Mit satzweise Übertragung des Schlüssels finde ich, ist es jetzt besser nachvollziehbar. Was meinst du, ginge das eventuell so, oder ist alle Mühe umsonst gewesen? L. G.
Fehler in Zeichnung: Es muß auf "Unterschied" gestellt werden, nicht auf "Abziehen".
Angehängte Dateien:
-
decrypted.jpg
430 KB
lostandfound schrieb: > Wer Lust hat kann sich ja mal daran versuchen Siehe Anhang :) olby schrieb: > Was meinst du, ginge das eventuell so, oder ist alle Mühe umsonst > gewesen? Bilde mal die Differenz aus den Übertragungen 2.1, 2.2, 3 und 4. Da dürfte einiges aus den Nachrichten 2 und 3 zum Vorschein kommen.
Yalu X. schrieb: > lostandfound schrieb: >> Wer Lust hat kann sich ja mal daran versuchen > > Siehe Anhang :) > > olby schrieb: >> Was meinst du, ginge das eventuell so, oder ist alle Mühe umsonst >> gewesen? > > Bilde mal die Differenz aus den Übertragungen 2.1, 2.2, Da erhalte ich ein neues Pixelfeld, wenn die Ebnen auf "Unterschied" eingestellt sind. 3 und 4. Da > dürfte einiges aus den Nachrichten 2 und 3 zum Vorschein kommen. Da weiß ich jetzt nicht, wie du das meinst.
bashooka schrieb: > So macht man das richtig: > https://de.wikipedia.org/wiki/Visuelle_Kryptographie Das hatten wir schon einmal weiter oben in diesem Topic.
Yalu X. schrieb: > lostandfound schrieb: >> Wer Lust hat kann sich ja mal daran versuchen > > Siehe Anhang :) > > olby schrieb: >> Was meinst du, ginge das eventuell so, oder ist alle Mühe umsonst >> gewesen? > > Bilde mal die Differenz aus den Übertragungen 2.1, 2.2, 3 und 4. Da > dürfte einiges aus den Nachrichten 2 und 3 zum Vorschein kommen. Entschuldigung, jetzt habe ich verstanden, wie das gemeint ist. Überprüfen werde ich das aber vorerst nicht, da doch mit viel Aufwand verbunde.
olby schrieb: > Überprüfen werde ich das aber vorerst nicht, da doch mit viel Aufwand > verbunde. Das ist doch kein großer Aufwand. Lade einfach die vier Bilder als vier Ebenen in Gimp und wähle für die drei obersten den Modus "Unterschied".
Yalu X. schrieb: > olby schrieb: >> Überprüfen werde ich das aber vorerst nicht, da doch mit viel Aufwand >> verbunde. Doch, eine genaue Überprüfung, so wie du vorgeschlagen hast, wäre ein großer Aufwand für mich. Ich habe bereits sehr viel Zeit dafür verwendet, daß ich jetzt nicht mehr weitermachen werde. > > ....................... Lade einfach die vier Bilder als vier > Ebenen in Gimp und wähle für die drei obersten den Modus "Unterschied". Es ist ja so, daß nur die beiden oberen Ebenen mit Modus "Unterschied" miteinander reagieren. Die Verknüpfung bezieht sich immer nur auf die beiden oberen. Die darunterliegenden Ebenen werden dabei nicht berücksichtigt. Man kann sie unsichtbar machen oder weglassen. Das ist egal, spielt keine Rolle. L.G.
@Yalu X. Aber wenn du das obere Bild noch mal mit deinem Programm duchschecken würdest, dann wäre das sehr freundlich. Ich würde mich freuen, wenn du es nicht decodieren könntest.
Vielleicht noch ganz interessant: Wenn du mein letzten Bild (Logau Gedicht) aufrufst, die Verknüpfung auf "Normal" stellst und die obere Ebene im Wechsel auf sichtbar und dann wieder auf unsichtbar stellst, kannst du für etwa eine Sekunde sehen, wie sich die Pixel des Schriftzuges verändern. Aber nur für einen kurzen Moment, danach ist alles wieder für das Auge einheitlich verpixelt. Das ist zwar jetzt etwas Spielerei, aber trotzdem, ich finde das beeindruckend.
olby schrieb: > Es ist ja so, daß nur die beiden oberen Ebenen mit Modus "Unterschied" > miteinander reagieren. Nein, die Ebenen werden schrittweise von unten nach oben abgearbeitet und dabei in jedem Schritt der jeweils eingestellte Verknüpfungsmodus angewandt. olby schrieb: > Aber wenn du das obere Bild noch mal mit deinem Programm duchschecken > würdest, dann wäre das sehr freundlich. Das Programm liefert tatsächlich nur sehr wenige Pixel (decrypted1.png). Allerdings liegen diese wenigen Pixel alle an Stellen, wo sich im Originalbild Buchstaben befinden (decrypted12.png), weswegen davon ausgegangen werden kann, dass ein Zusammenhang zwischen dem Originalbild und den erkannten Pixeln besteht. Im konkreten Beispiel lässt sich aus den erkannten Pixeln nichts rekonstruieren, weil es einfach viel zu wenige sind. Aber kannst du sicher sein, dass es in einem anderen Beispiel nicht vielleicht deutlich mehr werden?
@ Yalu X. ich bin begeistert. Super Das Programm heißt Gmask und ist schon etwas älter. Dafür nur 357KB groß und hat noch einige andere Parameter zur Veränderung der Blöcke. Habe es bei einmal Klick auf CL Mask belassen. Interessantes Thema übrigens.
Yalu X. schrieb: Vielen Dank für die Überprüfung meines letzten verschlüsselten Textes. Ich habe mich sehr darüber gefreut, daß dir die Entschlüsselung nicht gelungen ist. Dieser Erfolg hat sich nur Dank der Zusammenarbeit mir dir ergeben. Ohne deine vielen qualifizierten Richtigstellungen zu meinen Posts, wäre ich niemals mit der Verschlüsselung zu einem so guten Ergebnis gekommen. Mit dieser Aussage bin ich jedoch nicht ganz einverstanden: Yalu X. schrieb: ... > > Nein, die Ebenen werden schrittweise von unten nach oben abgearbeitet > und dabei in jedem Schritt der jeweils eingestellte Verknüpfungsmodus > angewandt... Ich bin kein GIMP-Fachmann, habe aber schon viel Zeit mit dem Programm verbracht. Dabei mußte ich feststellen, daß sich der Umgang mit Ebenen, wenn es sich um mehr als zwei oder drei handelt, recht schwierig gestaltet. Man muß schon ein richtiger Profi sein, um damit auf höherem Niveau arbeiten zu können. Ich bin aber kein Profi. Ich kann mir auch nicht vorstellen, daß du das bist. In einem vorherigen Post hast du nämlich angedeutet, daß du dich nur mal ganz kurz vor 10 Jahren mit GIMP auseinandergesetzt hast. M. E. kann aber niemand ohne gründliche Einarbeitung in das Programm die Ebenenverwaltung im Detail durchschauen. Dazu enthält dieses Programm zu viele technische Feinheiten. Ich will mich gern belehren lassen, aber ich gehe davon aus, daß es sinnvoll ist, den Ebenenstapel von oben nach unten abzuarbeiten und nicht umgekehrt. Mal sehen, ob ich ich bei Gelegenheit noch einen weiteren verschlüsselten Text erstelle? Es funktioniert ja, aber es fehlt eine Funktion in GIMP, den verschlüsselten Text bequem zu erstellen. Noch habe ich sie nicht entdeckt. So, wie ich das mache, dauert das alles viel zu lange.
vielleicht kann man sich dazu ein Script basteln, in Photoshop nennt sich so etwas glaub ich Stapelverarbeitung. Praktisch werden die Bedienschritte aufgezeichnet und dann kann man sich den automatischen Ablauf auf eine fast beliebige Funktions Taste legen. Müsste in Gimp auch möglich sein.
lostandfound schrieb: > vielleicht kann man sich dazu ein Script basteln, in Photoshop > nennt > sich so etwas glaub ich Stapelverarbeitung. Praktisch werden die > Bedienschritte aufgezeichnet und dann kann man sich den automatischen > Ablauf auf eine fast beliebige Funktions Taste legen. Müsste in Gimp > auch möglich sein. Es ist wirklich schwierig, das in Gimp zu machen. Ich brauche jedesmal viel Glück, um einen Text zu chiffrieren. Eben habe ich es noch mal mit einem anderen Text versucht, habe es aber nicht hinbekommen. Ich werde es später noch mal versuchen. Für heute reicht es erst mal.
olby schrieb: > Ich bin aber kein Profi. Ich kann mir auch nicht vorstellen, daß du > das bist. In einem vorherigen Post hast du nämlich angedeutet, daß du > dich nur mal ganz kurz vor 10 Jahren mit GIMP auseinandergesetzt hast. Das mit den 10 Jahren war Abdul. Ich selber benutze Gimp schon etwas öfter, aber ein Profi bin ich deswegen noch lange nicht :) > Ich will mich gern belehren lassen, aber ich gehe davon aus, daß es > sinnvoll ist, den Ebenenstapel von oben nach unten abzuarbeiten und > nicht umgekehrt. Gimp arbeitet immer von unten nach oben, wie das auch ein Maler tut, aber du kannst die Anordnung der einzelnen Ebenen beliebig ändern, wenn dich die Reihenfolge stört. > Mal sehen, ob ich ich bei Gelegenheit noch einen weiteren > verschlüsselten Text erstelle? Es funktioniert ja, aber es fehlt eine > Funktion in GIMP, den verschlüsselten Text bequem zu erstellen. Noch > habe ich sie nicht entdeckt. So, wie ich das mache, dauert das alles > viel zu lange. Die Frage ist halt, ob Gimp für so etwas überhaupt das richtige Werkzeug ist. Zum einen ist das Verschlüsselungsverfahren, wie du es damit bisher realisieren konntest, noch lange nicht perfekt (sie wäre besser, wenn es eine XOR-Verknüpfung oder eine Modulo-256-Addition auf Bildern gäbe), zum anderen ist der Arbeitsaufwand für die Verschlüsselung recht hoch, weil dafür mehrere Schritte nacheinander ausgeführt werden müssen. Das könnte man mit einem Skript vereinfachen. Wenn du aber schon eine Skriptsprache lernst (Gimp unterstützt Script-Fu (Scheme), Python, Perl, Tcl und (mit Einschränkungen) Ruby), kannst du auch gleich ein Stand-Alone-Programm in einer dieser Sprachen schreiben und den Gimp beiseite legen, da du für diese Anwendung kaum Gimp-spezifische Funktionen brauchst.
Yalu X. schrieb: > > Die Frage ist halt, ob Gimp für so etwas überhaupt das richtige Werkzeug > ist. Zum einen ist das Verschlüsselungsverfahren, wie du es damit bisher > realisieren konntest, noch lange nicht perfekt (sie wäre besser, wenn es > eine XOR-Verknüpfung oder eine Modulo-256-Addition auf Bildern gäbe), > zum anderen ist der Arbeitsaufwand für die Verschlüsselung recht hoch, > weil dafür mehrere Schritte nacheinander ausgeführt werden müssen. Das ist alles wahr. Der Aufwand ist viel zu hoch für eine zeitgemäße Anwendung. Dem steht gegenüber, daß ich kein Programm benötige, lediglich zwei Bilder erstelle ich selber. Die kann ich jederzeit an jedem Computer zu einer Nachricht verarbeiten. Ich benötige kein spezielles Programm, auch keinen extra Schlüssel. Sollte die Sache sicher sein, was ich nicht garantieren kann, finde ich das für mich schon mal ganz gut. Ich stehe aber vor einer Stolperstelle bei der Erstellung des oberen Bildes. Es ist eine ganze Kleinigkeit, aber ich habe schon Stunden daran gesessen und keine Lösung gefunden. Es läuft auf Frickelei heraus. Da hätte GIMP ruhig mal etwas weiter denken können. Sollte das aber einfach zu erledigen sein, wäre die Erstellung des oberen Schlüssels schnell gemacht.
Dazu kommt, hätte ich mit jemanden Geheimnisse auszutauschen (aber ich habe niemanden), hätte ich ein weniger schlechtes Gewissen, ihm das obere Bild mit sensiblen Daten über das Internet zuzusenden. Für die Entschlüsselung braucht er kein extra Programm auf seinem Computer installiert haben. So gesehen ist die Sache unkompliziert. Natürlich sollte noch geklärt werden, ob die Daten auch wirklich sicher codiert sind. Da kann ich als Nichtfachmann wenig zu sagen.
Angehängte Dateien:
-
liebe_Damen_3.jpg
95 KB
Das untere Bild mit der Transparenz im Schriftzug ist problemlos und ganz leicht zu erstellen. Der obere Schriftzug hingegen, mit der Transparenz um den Schriftzug herum, macht enorm Schwierigkeiten. Das ist Glücksache. Heute Morgen habe ich zwei Stunden lang versucht einen längeren Text in Pixelschrift umzuwandeln, bis ich dann aufgegeben habe. Den Umgang mit den Auswahlen finde ich überaus schwierig. Die Gimp-Hilfe hat mir nicht weitergeholfen. Vielleicht kann jemand erklären, wie man einen Schriftzug, bestehend aus einem vorgegebenen Pixelfeld heraus, einfach erstellen kann. L.G.
https://www.gimp-handbuch.de/gimp-bildbearbeitung/gimp-schrift-mit-bild-fuellen Statt Photo nimmst du die Eben mit deinen Rauschpixeln.
bashooka schrieb: > https://www.gimp-handbuch.de/gimp-bildbearbeitung/gimp-schrift-mit-bild-fuellen > > Statt Photo nimmst du die Eben mit deinen Rauschpixeln. Vielen Dank für den Link. Ich werde das Kapitel gleich durcharbeiten. Eben aber noch mein letzter Erfolg im Anhang (hat eine Stunde gedauert). Ich hoffe sehr, daß der Text nicht zu entschlüsseln ist.
Die xcf-Datei ist groß geworden (18,3 MB). Mit PNG sind es nur jeweils 2.4 MB. Die Bildqualität ist die gleiche.
Ich hab's nach der Anleitung versucht, aber damit ist es auch ziemlich aufwendig. Es müßte schon eine spezielle Funktion in Gimp eingerichtet sein, um das Verfahren anwenderfreundlich zu machen. Inzwischen habe ich es noch etwas verbessert, so daß ich auch einen DIN A4 Seiten Text codieren und wieder lesbar machen kann. Die Strichstärke umfaßt dann doppelte Pixelbreite. Es geht jetzt auch etwas schneller mit der Codierung. Ich meine, wenn es sich herausstellte, daß die Codierung sicher wäre und auch eine sichere Mehrfachübertragung im Internet möglich wäre, dann wäre das doch eine ganz tolle Sache? Dann hätten wir ein Briefgeheimnis im Internet für jedermann und die Geheimdienste würden zimlich alt aussehen. Zumindest hätten sie dann richtig viel Arbeit, oder umgekehrt, gar nichts mehr zu tun? Könnte mich bitte jemand von meinen Illusionen befreien?
Kannst du mal beschreiben wie du die Dateien mit Gimp erstellst? Ich versuche das dann mal per imagick nachzubilden.
bashooka schrieb: > Kannst du mal beschreiben wie du die Dateien mit Gimp erstellst? > Das ist weiter oben schon besprochen worden. Geht ja auch über die von dir gepostete Anleitung. Vielen Dank nochmal dafür. > Ich versuche das dann mal per imagick nachzubilden. Das ist aber nicht Sinn der Sache. Ich will ja weg von den Programmen. Gimp ist überall auf jedem Computer vorhanden oder zumindest leicht einzurichten. Ich bin jetzt nun mal auf die Idee gekommen, ein Briefgeheimnis im Internet einzurichten. Dann ist es der falsche Weg, irgendwelche Programme mit einzubinden. Zumindest bleibe ich erstmal bei dem Gedanken, bis man mich überzeugt hat, daß es nicht funktioniert.
olby schrieb: > Ich bin jetzt nun mal auf die Idee gekommen, ein > Briefgeheimnis im Internet einzurichten. Und ich frag mich, warum es Dunkelmänner heute noch vorziehen, Schokolade zu verschicken. Aber nur solche, deren Rückseite glatt ist. Da stichelt man einen Text rein und futtert die Nachricht danach auf.
olby schrieb: >> Ich versuche das dann mal per imagick nachzubilden. > > Das ist aber nicht Sinn der Sache. Ich will ja weg von den Programmen. > Gimp ist überall auf jedem Computer vorhanden Naja, ich würde sagen: auf einigen :) Ich kenne kaum Windows-User, die Gimp installiert haben. Bei Linux sind es sicher mehr, aber auch da gibt es konkurrierende Programme (bspw. Krita), die vielleicht nicht ganz so leistungsfähig, aber für den Durchschnitts-User mehr als ausreichend und dazu noch leichter zu bedienen sind. > oder zumindest leicht einzurichten. Auch für Imagemagick braucht der Windows-User nur einen Installer herunterzuladen und diesen auszuführen. Unter Linux geht es noch einfacher, da sagt man dem Paketmanager, dass man Imagemagick will, und dieser übernimmt den Download, die Installation und später ggf. die Updates. Wenn bashooka das mit Imagemagick hinbekommt, liefert er dir sicher ein Shell-Script bzw. eine Batch-Datei dafür, so dass die Sache auch für Unerfahrene nutzbar ist. Für Gimp müsstest du eine längere Anleitung schreiben (wenn ich dich richtig verstanden habe, ist die Verschlüsselung mit Gimp ja nicht ganz einfach), die sich der Anwender zu Gemüte führen muss, falls du es nicht schaffst, ein Plugin dafür zu schreiben, das der Anwender per Mausklick starten kann. Aber das alles liegt noch in der Zukunft. Erst einmal musst du die Leute davon überzeugen, dass dein Verfahren mindestens so sicher ist wie die bereits etablierten. Mich hast du jedenfalls noch nicht ganz überzeugt. Insbesondere bei der von dir angedachten verschlüsselten Übertragung der Schlüssel habe ich noch arge Zweifel. Aber selbst wenn du dafür eine Lösung findest, würde ich das Verfahren erst anwenden, nachdem es von einem (oder besser von mehreren) Experten (der ich leider nicht bin) gründlich untersucht und als sicher empfunden wurde.
Yalu X. schrieb: > Aber selbst wenn du dafür eine Lösung findest, würde ich das Verfahren > erst anwenden, nachdem es von einem (oder besser von mehreren) Experten > (der ich leider nicht bin) gründlich untersucht und als sicher empfunden > wurde. Ganz sicher kann ich das nicht beurteilen. Ich denke aber schon, daß du die Kenntnisse besitzt. Ohne dein Zutun wäre die Sache überhaupt nicht so weit fortgeschritten. Was das Internet anbelangt, da habe ich mal wieder zu viel Phantasie gehabt. Für mich ist das erstmal erledigt. Ich selber kann das auch nicht weiter optimieren. Weiterhin Zeit darin zu investieren macht keinen Sinn. Vielen Dank für deine Hilfe bisher.
Aber den Desintegrator muß ich noch mal antworten. ●DesIntegrator ●. schrieb: > Und ich frag mich, warum es Dunkelmänner heute noch vorziehen, > Schokolade zu verschicken. > Aber nur solche, deren Rückseite glatt ist. > > Da stichelt man einen Text rein und futtert die Nachricht danach auf. Angenommen, der Gefängnisdirektor fängt die Tafel Schokolade ab, hat im Moment aber keinen Appetit auf Süßes, dreht die Tafel um, sieht die Gravur auf der Rückseite, entziffert den Tex, der ihm nicht gefällt, wird darauhin böse, und da er einen nachtragenden Charakter hat, kann es durchaus sein, daß der Häftling später leiden muß, sich schließich sagt: "Hätte ich doch bloß Olbies Pixelfeld genommen".
olby schrieb: > "Hätte ich doch bloß Olbies Pixelfeld genommen". ... weil so ein ins Gefängnis eingeschleustes Bild mit scheinbar völlig zufälligen bunten Punkten ja überhaupt nicht verdächtig ist :)
Wechselnder EAN-Code auf der Milchpackung, einfliegende 🐞. . -Kolonie, codiert steckende Steinchen in der Fußsohle der Turnschuhe usw. Heizstrahler pulsierend neben dem Knast Netzspannung modulierend Gibt genug Möglichkeiten.
Um mal auf den Ursprung mit den Zerstreiften Bildern zu kommen, ja ich weiss das ist inzw. obsolet geworden aber ich habe da was interessantes gefunden: Ein Verfahren wie man in Streifen zerlegte und vermischte Bilder wieder automatisch fast komplett in die richtige Reihenfolge bringen kann: https://www.nayuki.io/page/image-unshredder-by-annealing Dass man dafür simulated annealing verwenden kann kapiere ich aber nicht.
Hab' spaßhalber noch einen Text codiert. Jetzt geht es schon ziemlich flott. Auf die obere Seite habe ich zusätzlich noch das zugrundeliegende Pixelfeld vermerkt, uncodiert natürlich, damit ggf. der Empfänger das entsprechende Feld vor der Decodierung auswählen kann. Was die Decodierung anbelangt, glaube ich, wenn Yalu X. das nicht schafft, dann wird es auch kein anderer schaffen. Ich wüßte wirklich keinen Ansatzpunkt. Bei der Mehrfachübertragung bin ich mir nicht sicher, ob es funktioniert. Das zu überprüfen, wäre vielleicht eine schöne Aufgabe für einen Dekypter? Sollte es wirklich funktionieren, was ich nicht glauben kann, da Olbi nur wieder mal das Rad neu erfunden hat, könnte man eventuell mehr draus machen. Thema: Briefgeheimnis im Internet für Jedermann.
Angehängte Dateien:
-
12_logau_Text_Seite7jpg.jpg
470 KB
Der farbige Text ist nicht unbedingt gut lesbar. Mit einigen Klicks in Gimp läßt sich die Lesbarkeit aber noch etwas verbessern. Das war es jetzt. Besser kriege ich es nicht hin.
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.