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.
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.
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?
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?
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:-)
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.
● 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.
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
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:
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.
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.
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.
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?
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...
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.
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/Downloadhttps://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?
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.
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:> 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.
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.
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_sharinghttps://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:> 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!
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 ;-)
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.
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.
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.
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.
●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?
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.
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.
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?
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.
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/XCFolby 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:
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.
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.
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.
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
@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?
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.
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 ;-)
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?
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?
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.
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.
@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.
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.
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.
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.
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?
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.
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.
Seite4.jpg
(270 KB)
