Verschlüsselungsalgorithmus (Idee)

  • War ne interessante idee (zumindest empfand ich dies so), dank minx (siehe Antwort weiter unten), wurd mir klar, dass dies so, wie minx sagt, keine verschlüsselung ist

    Abend, is ne ewigkeit zurück, seit ich hier das letztemal war :rolleyes:
    Ich hoffe (naja eher denke) dass ich den richtigen bereich des forums dafür gewählt habe, falls nicht, bitte ich um verschiebung des threads.

    In den letzten tagen hab ich zimlich viel über Verschlüsselungsalgorithmen geschaut & gelesen und bei einem vid kahm mir spotan ne strube idee.
    Nun möcht ich wissen ob es sowas bereits gibt (Falls ja dan, tjo, shit :rofl: , Falls nein 8o ) , was ihr davon haltet und ob es auch umsetzbar ist.
    Ich habe keinerlei berechnungen unternommen, nur die blose idee aufgeschrieben, sprich, falls es wen interessieren sollte und sich dass mal genauer ansehn möchte, nur zu, bist herzlichst willkommen :D

    Also, meine idee, ein Verschlüsselungsalgorithmus Basierens auf einem bild, das in dessen farbspectren sowie deren frequenzwelle aufgeteilt wird und daraus den Algorithmus generiert.
    Z.B.
    Man macht ein bild mit seinem handy oder cam, danach liest man die anzahl der verschiedenen farbspektren (aka lichtspektrum) aus, das würde dann (Theoretisch und einfach gesehen wie folgt sein
    [Ersteinmal das lichtspektrum]

    lichtspektrum.jpg

    bei dem augelessen bild dann z.b.
    grün 520 = 3931 (mal vorhanden)
    rot 680 = 4935 (mal vorhanden)
    blau 430 = 8133 (mal vorhanden)

    Das würde eine elenlange liste der farbaufteilung des bildes geben, diese kann man z.b. durch die anzahl vorhandener farben multipliziert, geteil, addiert oder subtrahiert werden (jenachdem was zu einem besseren ergäbniss führt) z.b.
    grün,rot,blau (3 (farben))
    3'931 * 3 / 4'935 * 3 - 8'133 =
    3'931 * 3 = 11'793
    4'935 * 3 = 14'805
    11'793 / 14'805 = 0.79655521783181357649442755825735
    (oder)
    14'805 / 11'793 = 1.2554057491732383617400152632918
    (oder)14'805 * 11'793 = 174595365 (- o. + o. * o. / 8'133)
    (Dies ist nur ein veranscheilichungs bsp und kähme nie und nimmer den realen zahlen einer auflistung der farbspektren eines HD (z.b. oder höheraufgelösten) bildes heran)
    durch den algorithmus selber, der die spektrumanalyse als "prime" verwendet, lassen sich eigentlich doch enorm grosse "bit" stränge generrieren, oder die "prime" selbst durch verschiedene andere Variablen addieren z.b.
    p = 1.2554057491732383617400152632918
    A = (irgendwas (Persönliches Datum oder oder Anzahl einer weiteren farbspektrums analyse eines zweiten bildes) aber sagen wir der einfachiet halber mal Perso Datum woe Geb (was scheiss dämmlich wäre))
    also A = 3009
    p(hoch A) = p³⁰⁰⁹ (ergäbe ne scheiss lange zahl <X , aber währe dan in etwa so. Mein taschenrechner gibt nach hoch 16 auf :rolleyes: aber is nurn bsp und hoffe auch verständlich wie ichs meine)
    und aus dem Resultat von p³⁰⁰⁹ arbeitet dan der algoritmus.

    Ich bin noch nicht sehr vertraut mit allg. verschlüsselungsalgorithmen, weiss aber das dies oftmals eine "prime" (oder immer?) besitzt, auf welches der algorithmus aufbaut (zumindest hab ich es so verstanden, korrigiert mich da wenn falsch BITTE!!) und aus mind 2 weiteren zahlen.

    In demsinne, könnte man das ergebniss des farbspektren"analyse" die "prime" bilden, was für eine zahl da am ende dan genau rausspringt, wie viele ziffern sie haben wird, weiss ich nicht, doch diese ist abhängig vom ausgewählten bild.
    Was die variation an möglichkeiten bei den möglichkeiten an bildern die gemacht werden können, immens steigert und aus meiner sicht, eines Brutforcings, reverse engeniering (sofern verwendetes bild nicht vorhanden) usw, so gut wie unmöglich macht.
    Nun, wie gesagt, ich beschäfftige mich mit Verschlüsselungsalgorithmen erst seit paar tagen und kann dh auch nicht wirklich sagen obs dies so schon gibt, dies umsetzbar wäre oder in dem sinne als verschlüsselung dienen kann / könnte.

    Das ganze liese sich bis ins endlose wiederhohlen durch den algoritmus :S

    nun zu euch, was haltet ihr von der grund idee ansich? ist es realisierbar? WÜRDE dies überhaupt was Taugen?
    Es war nur ne Spontane idee und fand es selber irgendwie in ner form lächerlich, aber ich habs mir aufgeschrieben und am nächsten tag nochmal angeschaut, wobei ich fand...hmm, theoretisch könnte dass zu was führen...

    Greez, danke für die zeit und ich hoffe, dass dies nicht zu :S oder unverständlich erläutert ist ^^

    *Edit1: War so in gedanke, das ich sätze im selbigen satz wiederhohlt hab o_O
    *Edit2: Mir kommt grade in den sinn, wie man verhindern könnte, das irgendjemand besagtes bild erhalten, klauen oder sonnstiges kann.
    Via VM auf dem Rechner, welche ohne Internetverbindung läuft, das bild in die VM Laden, in der VM Verschlüsseln (wenn das mit der rechenleistung der VM vereinbar ist), via VM nen USB stick freischalten, bild + verschlüsselte daten auf den USB stick (oder nur bild auf USB stick und die verschlüsselten Daten direkt von der VM auf den PC schieben), nach kompletierung der verschlüsselung die hdd der VM komplett löschen. Theoretisch, bestünde dan (auser man bekähme den USB stick in die finger) keine möglichkeit mehr aus den überresten der gelöschten hdd, irgendwelche verwertbaren informationen zu filtern.

    2 Mal editiert, zuletzt von Skilkor (14. August 2015 um 02:28)

  • Dieser Gedanke ist durchaus sinnvoll und auch richtig. In der bekannten Verschlüsselungssoftware TrueCrypt beispielsweise können Bilder zum verschlüsseln verwendet werden. Wie genau kann ich dir leider auch nichts sagen. (Musst nur suchen, weil die die Entwicklung eingestellt haben -> oder musste, je nachdem welcher theorie man glaub... jetzt kann das programm von der offiziellen seite nurnoch entschlüsseln. :))

  • Danke für die schnelle antwort
    Das dies TrueCrypt konnte wusst ich nicht, aber laut informationen wurde die entwicklung auf grund verlangen der NSA ein Backdoor einzuprogrammieren, eingestellt.
    Und aus deinen Informationen entnehme ich, dass dies durchaus im rahmen des möglichen ist?
    Ich finds extrems interessant und auch der Stupide weg, wie ich auf die idee kahm..ich mein...ich hab Verschlüsselungsalgorithmen vids angesehen und danach n Video auf youtube von Vsauce, titel: what is the brightest thing in the universe und bei dem vid machte es "klick" und da kahm mir diese idee

  • Verstehe jetzt immer noch nicht den Nutzen des Bildes. Aus deinem Geschriebsel entnehme ich, dass du es als Seed verwenden willst? Was ist dann der Unterschied zu einem kryptographischen PRNG?

    Kannst du einfach mal kurz in ein/zwei Sätzen zusammenfassen was du jetzt vorhast?

  • Ich habe grad mit nem kumpel geredet, er meinte, das ein bild im .raw format, sei unkomprimiert und mitunter sämtliche infos zu jedem pixel, er meinte, wen man diese via hex-editor öffnet, erhielte man die infos die ich beschrieb, ich hab dies nicht getestet, werd erst morgen dazu kommen.

    meine idee bezieht sich darauf dass jede farbe, im Farbspektrum eine Spezifiesche zahl hat, aufgrund der anzahl, der pixel und den informationen der pixelfarb aus dem farbspektrum (z.b. grün(520)), einen, wie du sagst, seed, erstellen.
    so meine idee im groben

  • RAW Dateien enthalten keine RGB Daten, sondern Rohdaten vom Sensor.

    Gut, Bild als Seed gibt es schon. Generell ist jede Datei, ob nun Bild oder sonstwas, ein Bitstream. Von daher besteht kein Unterschied zu einem klassischen Seed. Auch hat das an sich nix mit Verschlüsselung zu tun, schon gar nicht mit einem Verschlüsselungsalgorithmus, sondern mit PRNG.

    Ein Beispiel für einen für Kryptographie geeigneten PRNG habe ich mal hier implementiert: https://www.autoitscript.com/forum/topic/17…rator-verified/

    Wichtig für diese Kategorisierung ist eine hohe Entropie, Seed-Sensibilität und natürlich eine objektiv hohe Zufälligkeit. Dafür gibt es Testsuits wie ent, DIEHARD und Standards von NIST.GOV. fliptag besteht all diese Tests. ent im Speziellen ist ein Vergleichstest. Oben siehst du den Vergleich von fliptag zu der Mersenne Twister Implementation von AutoIt.

    Beide Algorithmen benutzen einen Zeitstempel als Seed, wobei fliptag diesen Seed über zwei Stufen vorher noch einmal verstärkt. Um deine Idee zu testen, nimm einfach mal ein Bild (ob das nun TIF, RAW oder andere unkomprimierte Dateien sind) und lasse es gegen ent laufen. Du wirst sehen, dass das Ergebnis katastrophal ist.

    Diesen Fehler in deiner Idee kannst du dir aber schon ohne ent herleiten. Sobald ein einfacher Kompressionsalgorithmus das Bild verkleinern kann (z.B. PNG > JPEG), ist der bitstream nicht zufällig. Ein zufälliger bitstream kann nicht komprimiert werden.

    Fazit: Für eine sichere Zufälligkeit müssen es nicht viele Daten oder große Zahlen sein, sondern gute Daten.

  • Danke für die ausführliche erklärung, das es eine gewisse komplexität hat war mir bewusst, jedoch nicht was die daten anging, wie du sagst
    "Fazit: Für eine sichere Zufälligkeit müssen es nicht viele Daten oder große Zahlen sein, sondern gute Daten."
    Dürfte ich dich darum bitten, rein aus neugierde, was genau du mit "gute Daten" meinst?

    Schaade, wäre interessant gewessen aus einer struben idee eine mögliche entwicklung zu sehen ^^

  • Es gibt ja zwei Möglichkeiten um das Bild zu verwenden, beide ergeben wenig Sinn

    1. Als Seed

    Nehmen wir mal den MT von AutoIt. Laut AutoIt source code benutzt der time(NULL) als input, also einen 32bit Seed. Mehr als 32bit braucht der nicht, also wäre ein Bild (jedes Bild größer als 1 Pixel) zu groß, unnötig groß. fliptag kann bis zu 4x 53bit Seeds aufnehmen (als Pseudo-Double) und ist extrem empfindlich, was Änderungen in den ersten 16 Dezimalstellen angeht. Jeder Zyklus hat etwa eine Kapazität von [Blockierte Grafik: https://latex.codecogs.com/gif.latex?2%5E%7B73%7D]. Es braucht also einen guten (sprich zufälligen) Seed, keinen großen Seed. Ein Seed von 32 bis 212bit reicht aus um (theoretisch) bis zu [Blockierte Grafik: https://latex.codecogs.com/gif.latex?2*10%5E%7B24%7D] zufällige 53bit doubles zu generieren.

    Selbst die ersten Bits jedes Bildes als Seed wären nicht brauchbar, da die tatsächliche Entropie viel kleiner als die theoretische Entropie ist.

    2. Als fertiger bitstream

    Da habe ich bereits oben erklärt warum das nichts wird.

  • Hi,

    Wichtig für diese Kategorisierung ist eine hohe Entropie, Seed-Sensibilität und natürlich eine objektiv hohe Zufälligkeit.

    Stimmt!

    Sobald ein einfacher Kompressionsalgorithmus das Bild verkleinern kann (z.B. PNG > JPEG), ist der bitstream nicht zufällig. Ein zufälliger bitstream kann nicht komprimiert werden.

    Selfowned :thumbup:
    Damit Bilder (wir reden hier über Sensor-Kamera erzeugte Digitalbilder) überhaupt komprimiert werden können, werden GENAU DIE ZUFÄLLIGEN Anteile der Sensordaten abgeschnitten! Es gibt kaum etwas zufälligeres wie die unterstersten Bits von Bildsensoren, denn diese basieren auf physikalisch bedingtes "Rauschen"! Die Frage ist nur, was macht der Prozessor in der Kamera damit?!
    Da natürlich der Kamerahersteller davon weiß, wird er alles dafür tun auch die "RAW"-Bilder (ich sags mal SEHR vorsichtig) "anzupassen".
    Alles andere wäre kontraproduktiv, denn man kann keinem Kunden plausibel erklären warum er mehrere hundert Euro für ein neueres Kameramodell mit x Millionen Pixeln ausgeben soll, wenn ein nicht unerheblicher Teil des "Bildes" zufällig ist! Bei einem Bit "Rauschen" pro Farbe immerhin 12,5%, bei 10 Bit/Farbe immer noch 10%!
    Und wir reden hier von einem Bit! Rechnet euch das für zwei Bit aus, und es wird klar, dass NIEMAND auf der Welt viel Geld für 1/4 "zufällige" Bilddaten ausgibt...

    Wer das selbst mal testen möchte schiesst ein Bild in einem völlig dunklen Raum und schaut sich die "Raw"-Daten an. Kommt dort "nichts" an, d.h. die untersten Bits der Pixel sind alle (!) null und nicht zufällig verteilt, dann rechnet der Kamera-Prozessor das Bild "schön".
    Das ist aber relativ unwahrscheinlich, denn selbst die besten Rauschunterdrückungsalgorithmen geben irgendwann auf 8o

    Wäre mal interessant, diesen Ansatz weiter zu verfolgen, denn wenn die Sensordaten "zufällig" sind, wäre mit simpelstem XOR ein sicheres Verschlüsseln möglich!
    Für gängige Verfahren ist das, wie von mir bereits ausführlich behandelt, uninteressant, denn gängige Verfahren MÜSSEN umkehrbar sein, damit die verschlüsselten Daten mit heutiger Rechnertechnologie wiederherstellbar sind!
    Es soll immer noch Leute geben, die daran glauben, dass öffentlich zugängliche Verschlüsselungsverfahren "sicher" sind....
    Diese Menschen sind auch in der Lage, Millionen Zeilen Quellcode eines "offenen" Betriebssystems auf Sicherheitslücken zu analysieren bzw. Prozessoren/Microcontroller aufzuschleifen und die darin implementierten Algorithmen abzugleichen. Daher hat es auch "nur" einige Jahre gedauert, OpenSSL zu fixen!

    Aber wieso ein Kamerabild zur Verschlüsselung benutzen, wenn man die zu versteckenden Daten so schön Steganografieren kann...
    Steganographie....Verstecken statt Verschlüsseln
    Steganografie für Bild- und Sounddateien

  • Musst nur suchen, weil die die Entwicklung eingestellt haben -> oder musste, je nachdem welcher theorie man glaub...

    Ob man der urkomischen Version glaubt, die NSA hätte ein Backdoor gebraucht, um es zu knacken, oder der Tatsache, dass es immer mehr Berichte darüber gab, wie das ganze System wenig kostenintensiv innerhalb kürzester Zeit von gleich mehreren Stellen (unter anderem Geheimdienste und AV-Hersteller) geknackt wurde und das Vertrauen in diese Software dadurch schwer erschüttert wurde? Gibt keinen Grund, das ganze einzustellen, wenn die NSA ein Backdoor braucht. Im Gegenteil: Immerhin scheitert die NSA nicht an SSL-"on the fly"-Entschlüsselung und bekommen auch Rijndael in akzeptabler Zeit problemlos geknackt. Und die haben nicht einmal die Technik der Firma D-Wave Systems, die das alles noch schneller und problemloser machen würde. ;)


    Die Verschlüsselung selbst wird immer mehr zu einem Problem, für das es keine annehmbare Lösung gibt und vielleicht nicht mehr geben kann. Es fehlt der eine Durchbruch, der Geheimdienste wirklich aus dem ganzen System aussperrt, und die Daten geheim hält. Es fehlt der eine Durchbruch, bei dem es ohne die offensichtliche Sicherheitslücke "Mensch" wieder einmal Ewigkeiten braucht, den Schlüssel zu erraten. Aber das bringt auch nicht die Bild-Methode die hier beschrieben wurde in meinen Augen. Warum würde zu lange dauern dies zu erklären - und ich müsste mir sicher sein, dass ich deine Idee überhaupt richtig interpretiere - denn ich habe insgesamt 7 Möglichkeiten im Blick, wie ich es interpretieren könnte.

    Es gibt Tage, da trete ich nicht ins Fettnäpfchen. Ich falle in die Friteuse.

  • Wäre mal interessant, diesen Ansatz weiter zu verfolgen, denn wenn die Sensordaten "zufällig" sind, wäre mit simpelstem XOR ein sicheres Verschlüsseln möglich!

    Das wäre ein OTP, und damit der Schlüssel. Greift wieder meine ursprüngliche Aussage.

  • Es gibt kaum etwas zufälligeres wie die unterstersten Bits von Bildsensoren

    Noch mal ein Beispiel warum das nicht richtig ist. Im Anhang sind zwei Bilder, einmal ein RAW und einmal ein entwickeltes JPG (Lightroom Standard, nicht bearbeitet). Ergebnis: JPG ist zufälliger. Logischerweise! Zudem bestätigt der Chi² meine zweite Aussage. Beide Bilder sind absolut unzufällig. Somit ist auch deine XOR Idee nutzlos, denn für eine One-Time-Pad Verschlüsselung muss der Schlüssel zwar lang, aber sehr zufällig sein.

    Jeder komprimierbare bitstream ist immer weniger zufällig als ein komprimierter, oder von Anfang an zufälliger. Wurde auch auf der Revision klar, als einige Demos pinkes oder weißes Rauschen gezeigt haben, also "hohe" Zufälligkeit. Die Leute vor dem Stream konnten dann nichts mehr sehen, da der Codec das Bild nicht mehr richtig komprimieren und encoden konnte. :D


    Zitat von RAW (Sony A600 ARW)

    Entropy = 7.490889 bits per byte.

    Optimum compression would reduce the size
    of this 25133056 byte file by 6 percent.

    Chi square distribution for 25133056 samples is 19954582.73, and randomly
    would exceed this value less than 0.01 percent of the times.

    Arithmetic mean value of data bytes is 98.1557 (127.5 = random).
    Monte Carlo value for Pi is 3.716989087 (error 18.32 percent).
    Serial correlation coefficient is 0.129460 (totally uncorrelated = 0.0).

    Zitat von JPEG

    Entropy = 7.979499 bits per byte.

    Optimum compression would reduce the size
    of this 13504038 byte file by 0 percent.

    Chi square distribution for 13504038 samples is 397037.14, and randomly
    would exceed this value less than 0.01 percent of the times.

    Arithmetic mean value of data bytes is 125.3367 (127.5 = random).
    Monte Carlo value for Pi is 3.207214909 (error 2.09 percent).
    Serial correlation coefficient is 0.011864 (totally uncorrelated = 0.0).


    Download RAW
    Download JPG

  • Zitat von Einexage

    und ich müsste mir sicher sein, dass ich deine Idee überhaupt richtig interpretiere - denn ich habe insgesamt 7 Möglichkeiten im Blick, wie ich es interpretieren könnte.

    Würde es dir was ausmachen, deine Interpretationen uns mitzuteilen?
    Ich weiss dass ich oftmals sätze formuliere die man vielerlei interpretieren kann, dh kann ich danach direkt sagen, weöche interpretation so gemeint ist, wie ich es im kopf habe oder annähernd rankommt.

    Die diskusion zwischen Andy und minx ist extrem spannend ^^
    Und Andy hinterlässt einen winzigkleinen hoffnungsschimmer das es evt wirklich funktionieren könnte 8o

    Ich habe mir vorhin, besagte aussage die ich beschrieben habe, die von meinem Kumpel kahm, Bezüglich .raw dateien angesehen und stelle fest, dass es nicht dass ist, was ich kopf hatte.
    Doch es gab einen ansatz, aus dem evt etwas werden könnte.

  • jetzt muss ich einmal einen naive vll. dumme Frage stellen.

    Verschlüsselung bedeutet heutzutage doch nicht mehr, dass ich eine Information unkenntlich mache und "nur" der mit dem richtigen Schlüssel kann es wieder kenntlich machen.

    Heutzutage ist das Spiel doch eine Information so unkenntlich zu machen, dass deren Wiederherstellung ohne passenden Schlüssel länger dauert als der Inhalt Wert ist. Oder?

    nur ein Gedanke wo man bei der Verschlüsselung heutzutage ansetzen könnte ...

    MfG Schnuffel

    "Sarkasmus ist die niedrigste Form des Witzes, aber die höchste Form der Intelligenz."
    Val McDermid

    ein paar Infos ...

    Wer mehr als "nur" Hilfe benötigt, kann sich gern im Forum "Programmieranfragen" an uns wenden. Wir helfen in allen Fällen, die die Forenregeln zulassen.

    Für schnelle Hilfe benötigen wir ein ! lauffähiges ! Script, dass wir als Demonstration des Problems testen können. Wer von uns erwartet ein Teilscript erstmal lauffähig zu bekommen, der hat
    1. keine wirkliche Not
    2. keinen Respekt vor Menschen die ihm in ihrer Freizeit Ihre Hilfe anbieten
    3. oder ist einfach nur faul und meint wir coden das für ihn

    In solchen Fällen erlaube ich mir, die Anfrage einfach zu ignorieren. ;)

  • nur ein Gedanke wo man bei der Verschlüsselung heutzutage ansetzen könnte ...

    Naja, das hängt von der Verschlüsselung ab, es gibt eigentlich drei Hauptarten:

    One Time Pads

    Der Schlüssel ist zufällig und genauso lang wie der Rohtext. Zudem gibt es diesen Schlüssel nur ein mal, er kann nicht für andere Texte verwendet werden (nicht mal für Teile anderer Texte). Diese Verschlüsselung ist unknackbar.

    Stromchiffren

    Es gibt einen Schlüssel, der über ein beliebiges Verfahren benutzt wird um einen oder mehrere Rohtexte zu verschlüsseln. Dabei muss der Schlüssel nicht so lang wie der Text sein, sondern ist beliebig. Der Output ist allerdings genauso lang wie der Rohtext, d.h. mit einer heuristischen Analyse kann man schnell feststellen welches Zeichen welchen Buchstaben darstellt. Beispiel: ROT13 (der Schlüssel ist 13) oder Caesar (Schlüssel ist eine Zahl von 1 bis 26).

    Blockchiffren

    Siehe AES.

    -----

    Die beiden letzteren sind mit Bruteforce auf den Key in jedem Fall (theoretisch) knackbar.

  • jetzt muss ich einmal einen naive vll. dumme Frage stellen.

    Verschlüsselung bedeutet heutzutage doch nicht mehr, dass ich eine Information unkenntlich mache und "nur" der mit dem richtigen Schlüssel kann es wieder kenntlich machen.

    Heutzutage ist das Spiel doch eine Information so unkenntlich zu machen, dass deren Wiederherstellung ohne passenden Schlüssel länger dauert als der Inhalt Wert ist. Oder?

    nur ein Gedanke wo man bei der Verschlüsselung heutzutage ansetzen könnte ...

    Eindeutig, so sehe ich dies auch.
    So wie ichs im kopfhabe, würde dies ohne das exact selbe "bild", nicht möglich zu "entschlüsseln" sein.
    evt sollte ich mich in den nechsten tagen mal ransetzen und das ganze im detail durcharbeiten wie ichs im kopf habe, da es wie gesagt nur eine idee war die mir kahm, hab ich nur die basis der idee ohne gross ins details zu gehen niedergeschrieben.
    nun okay, darf ich feststellen, das bei solchen themen, wo die frage im detail, sehr wichtig ist und doch, kann man mit der basisidee, sehen was andere davon halten, wie und ob es umsetzbare wäre und ob es sinvoll wäre.
    Ich weiss leider nicht ob dies in autoit (als theorie zur veranscheulichung) umsetzbar ist, jedoch weiss ich, das autoit befähigt ist, pixel auszulessen (ein thema, welche hie nicht gerne gesehen ist) und auch keineswechs in die richtung eines solchen gehen wird! *hoffe ich zumindest* nun, natürlich kann man jetz sagen "ja aber wenn du ein bsp in genau diesem berreich machst, kann man die art für anderes missbrauchen", stimmt so, leider :( aber das trifft auf sehr, sehr vieles zu, so genug davon.

    Wie gesagt, ich schau ob ich mich in den nächsten tagen im detail dransetzen kann und versuche danach das ganze dan hoffentlich verständlicher auszudrücken :)

  • das heißt für mich, dass sobald jemand den gesamten verschlüsselten Inhalt hat, er diesen auch knacken kann.

    Vll muss man da ansetzen, dass man diesen nur in "Häppchen" serviert, wenn die vorherigen Teilstücke in x-Ansätzen erfolgreich entschlüsselt und ein Hash zurückgesendet wurde, oder oder oder ... lol

    MfG Schnuffel

    "Sarkasmus ist die niedrigste Form des Witzes, aber die höchste Form der Intelligenz."
    Val McDermid

    ein paar Infos ...

    Wer mehr als "nur" Hilfe benötigt, kann sich gern im Forum "Programmieranfragen" an uns wenden. Wir helfen in allen Fällen, die die Forenregeln zulassen.

    Für schnelle Hilfe benötigen wir ein ! lauffähiges ! Script, dass wir als Demonstration des Problems testen können. Wer von uns erwartet ein Teilscript erstmal lauffähig zu bekommen, der hat
    1. keine wirkliche Not
    2. keinen Respekt vor Menschen die ihm in ihrer Freizeit Ihre Hilfe anbieten
    3. oder ist einfach nur faul und meint wir coden das für ihn

    In solchen Fällen erlaube ich mir, die Anfrage einfach zu ignorieren. ;)

  • So wie ichs im kopfhabe, würde dies ohne das exact selbe "bild", nicht möglich zu "entschlüsseln" sein.

    Dann ist es das was du suchst: https://de.wikipedia.org/wiki/One-Time-Pad

    Ein Bild dafür zu nehmen ist aber eben nicht sinnvoll, da es nicht zufällig genug ist. Es funktioniert, aber es ist nicht das Optimum, was sich mit weniger Aufwand erreichen lässt.

    das heißt für mich, dass sobald jemand den gesamten verschlüsselten Inhalt hat, er diesen auch knacken kann.


    Mit einem Text aus einer OTP Verschlüsselung kann man gar nix anfangen, egal wie viel Zeit man hat ^^

  • One Time Pads

    Der Schlüssel ist zufällig und genauso lang wie der Rohtext. Zudem gibt es diesen Schlüssel nur ein mal, er kann nicht für andere Texte verwendet werden (nicht mal für Teile anderer Texte). Diese Verschlüsselung ist unknackbar.

    der Transport eben solcher Schlüssel ist aber dann das Problem.
    Ist ja auch nicht der Weisheit letzter Schluss hoffe ich... ^^

    MfG Schnuffel

    "Sarkasmus ist die niedrigste Form des Witzes, aber die höchste Form der Intelligenz."
    Val McDermid

    ein paar Infos ...

    Wer mehr als "nur" Hilfe benötigt, kann sich gern im Forum "Programmieranfragen" an uns wenden. Wir helfen in allen Fällen, die die Forenregeln zulassen.

    Für schnelle Hilfe benötigen wir ein ! lauffähiges ! Script, dass wir als Demonstration des Problems testen können. Wer von uns erwartet ein Teilscript erstmal lauffähig zu bekommen, der hat
    1. keine wirkliche Not
    2. keinen Respekt vor Menschen die ihm in ihrer Freizeit Ihre Hilfe anbieten
    3. oder ist einfach nur faul und meint wir coden das für ihn

    In solchen Fällen erlaube ich mir, die Anfrage einfach zu ignorieren. ;)

  • Sensorrauschen (Dunkelrauschen/Photonenrauschen), hat immer den gleichen Grund, physikalische Beeinträchtigung vom Sensor(Material) und dem unbeeinflussbaren "Beschuss" mit Photonen. Und ein Photonenstrom ist zufällig. Wo/wann eins eingeschlagen hat, weiß man immer erst nachher.

    Und der Unterschied von einem RAW-Bild und einem RAW-Bild besteht in dem, was der Kameraprozessor dir als "RAW" rauswirft! RAW<>RAW!
    Wenn du glaubst, dass RAW "Sensor-Rohdaten" heißt, dann frag dich mal, wieso du die Hälfte des Kamerapreises für einen Prozessor bezahlen musst, der ein Bild "schönrechnet"!
    Selbstverständlich werden auch RAW-Daten vor dem herausgeben bearbeitet, um zigtausende Hotpixel uvam, wegzubügeln! Vom Filtern bevor überhaupt Lichtpartikel auf den Sensor fallen garnicht zu reden. Der "Zufall" in Form des Photonenstroms wird demnach nicht in Form eines Bildes wiedergegeben. Wäre ja auch zu einfach/schön, einen "sicheren" Zufallsgenerator zu haben ;)

    Mach mal Bilder mit geschlossener Blende, einmal mit im Ofen auf 60°C vorgewärmter Kamera, einmal Kamera im Eisfach runtergekühlt auf -10°C.
    Dann siehst du deutlich, dass schwarz (geschlossene Blende) <> schwarz (geschlossene Blende) ist!
    Und dann weißt du auch, wieso ich Langzeitbelichtungen vom Sternenhimmel nur noch im Winter mache 8o
    Im heißen Sommer hab ich schon Bilder von der Milchstraße trotz draufgelassenem Objektivdeckel gemacht :rofl:

    Ich schau mal, was man an "rohen" Daten (Rauschen) aus einigen Fotodioden mit Hilfe des Arduino rausholen kann. Zufall kann man immer gut gebrauchen!