[HaBo]

weltio

Anzeige

Ahoi,
wie so viele hier beschäftige auch ich mich neuerdings mit Kryptograpie.
Meine erste Überlegung war also, jedes Bit mit XOR (und einer Zufallszahelnfolge X) zu verschlüsseln.
Diese Zufallszahlenfolge muss dann ja "nur" noch verschlüsselt werden und als Schlüssel übergeben werden. Solange die Algorithmen nur im Source stehen und diese Sources fernab von Internet und Persönlichem Computer gespeichert werden, sollte die Sicherheit des Schlüssels gewährleistet sein, dieser also nicht ohne Algorithmus entschlüsselt werden.
Aber wieso sollte man sich um den Schlüssel kümmern, wenn man einfach die verschlüsselte Datei entschlüsseln könnte? Deshalb frage ich mich, wie sicher XOR eigentlich ist. Ich habe gehört, es sei sehr unsicher, habe aber auf die Schnelle keine Gründe dafür gelesen. Andererseits sagt das überaus unzuverlässige Wikipedia, XOR sei für Verschlüsselungen relevant - aber wieso wenn es unsicher sei?
Wisst ihr mehr?

XOR soll meinem Programm nur als Basis dienen und natürlich mit anderen Methodiken kooperieren.
Darüber muss ich aber keinerlei Worte verlieren ;)

Elderan

Hallo,
Ist nichts neues, wird als Stromverschlüsselung bezeichnet.


Ich zitiere mal Kerckhoffs? Prinzip

Also:
Die Sicherheit von 'XOR' hängt vom zugrunde liegendem Schlüsselstream ab. Ist dieser absolut zufällig (nicht Pseudozufällig!) und wird er nur 1 mal verwendet, hast du ein nachweisbar 100% sicheres Verfahren (sogenanntes One-Time-Pad).
Das Problem ist aber, du musst um 1 kb Text zu verschlüsseln eben auch 1 KB zufällgen Key dir merken (_dieser darf nicht reproduzibel sein_), aber dann kannst dir auch gleich den Text merken.

Deswegen sind One Time Pads ansich unpraktisch, dennoch werden Stromchiffren häufig verwendet.
Der generierte Zufallstrom hängt aber nicht von der Geheimhaltung des Algorithmus ab, was nicht funktioniert, sondern basiert auf der Eingabe eines kürzeren Passwortes, z.B. 128 Bit lang.
Der Angriffspunkt liegt hier nicht auf der XOR-Verknüpfung sondern man versucht dann den Algorithmus zu knacken, der den Schlüsselstream berechnet zu knacken.
Lässt sich der Schlüsselstream relativ gut vorhersagen[1], ohne den Key zu kennen, kann man den Geheimtext sehr leicht knacken.
Setzt man aber ein sicheren Algorithmus ein, z.B. AES im Counter Modus, basiert die Sicherheit eben auf AES, welche momentan noch hoch ist.


[1]
Wenn man z.B. den Stream so berechnet (äußerst schlechter Algo):
XOR-Verknpüfen der letzten beiden Klartext-Bytes und des letztes Streambyte.
Kennt jmd. den Klartext (Know Plaintext Attack), kann er auch das Streambyte berechnen und so den gesamten Key-Stream erhalten.
Selbst ohne Know Plaintext könnte man mit Brute Force schnell ans Ergebnis kommen

IsNull

Dir ist schon klar, dass man auch bei einem kompilierten Programm (exe/dll) den Programmcode anschauen bez. debuggen kann (entsprechende Kentnisse vorausgesetzt)?! Das ganze zwar nur auf ASM Ebene, dies reicht jedoch um den Algo zu rippen.

Was hier sehr oft zelebriert wird: Ein Verschlüsselungs-Algo ist nur sicher, wenn er öffentlich bekannt und einsehbar ist.

Gruss
IsNull

weltio

Das hab ich ja auch nicht behauptet

Also:
X * Nachricht = Schlüssel
Letztenendes ist es doch sowieso immer nur vom Schlüssel abhängig. Ich kann eine "Zufallszahlenfolge" (Definitionssache was "Pseudozufall" ist ) mit dem ASCII-Wert des dirtten Zeichens des PWs multiplizieren und schon kann man die "Zufallsfolge" als "verschlüsselt" gelten lassen.

Wie gesagt, bei "Pseudozufall" liegt ein semantisches Problem vor. Meines Erachtens gibt es so etwas wie "Zufall" ganz und gar nicht Aber du hast insofern recht, als dass eine einmalige Zahlenfolge für eine XOR-Verknüpfung ein hohes Maß an Sicherheit bieten würde, sicherlich aber keine 100% (Das impliziert eine Wahrscheinlichkeit von 0, dass man es schafft. Aber würden wir an deiner Zufallstheorie hängen bleiben, würde sich nach n+1 Versuchen das Gegenteil herausstellen, da eine XOR-Verknüpfung, mit heutiger Computertechnik, "nur" mit einer endlichen Zahlenfolge stattfinden kann Ergo ist das Ergebnis auch endlich. Ergo ist der Zeitaufwand auch endlich. Wie hoch letzterer ist, hängt wiederum von der Zahlenfolge selbst und dem verwendeten Dekodierungstechnik ab

Naja natürlich kann ich das. Wir brauchen auch keine Verschlüsselung, da wir uns unsere Daten merken können und auch keine Geheimnachrichten verschicken wollen
Sicherlich hast du mit der Größenordnung recht. Was kann man dagegen denn tun? (und nein, bitte verlinke jetzt nicht zu irgendwelcher Fachliteratur )
Wieso darf der Key nicht reproduzierbar sein? (Wo ist denn der "Zufall" geblieben? (endliche Ausgangspunkte, endliche Ergebnisse => "Zufällig" das gleiche Ergebnis (wenn ggf. auch mit anderem Ausgangspunkt - hängt vom Algorithmus ab)))

Meine Frage ist dann aber, was man damit anfangen kann, wenn man weiss, wie man einen Schlüssel erzeugt, dieser aber beispielsweise von einer "Zufallszahl" abhängig ist. Diese sollte ja im besten Fall die Wahrscheinlichkeit 1/n haben, wobei n = die Wertemenge des Zahlenbereiches ist.

Aber neben dem Algorithmus benötigt man noch den Ausgangspunkt, also die Nachricht, um den Schlüssel zu erhalten.
Nachricht * Algorithmus = Schlüssel + Verschlüsselter Text

Um ehrlich zu sein, dachte ich, das ginge nicht. Aber auch auf die Gefahr mich wiederholen zu müssen frage ich mich, wie relevant der Algo ist, wenn das Ergebnis von einer "Zufallszahl" und einem individuellen Passwort abhängt.

IsNull

Du beschreibst ein verfahren, in dem der eigentliche xor schlüssel verschlüsselt wird, welcher letzt endlich dazu verwendet wird, um die eigentliche Nachricht zu verschlüsseln.

=> Davon ausgehend, dass also dein verschlüsselter xor Schlüssel im Programm hartcoded ist und somit einsehbar, ist es nur noch interessant, mit was den nun dein xor Schlüssel verschlüsselt ist. Und da lässt du uns im dunkeln.

valenterry

Da liegst du falsch. Es stimmt schon, dass die Länge des Schlüssels natürlich endlich ist und man somit nach einer gewissen Zeit alle Schlüssel durchprobiert hat. Das Problem ist aber ein ganz anderes. Angenommen, du hast den Ciphertext mit sämtlichen möglichen Schlüsseln entschlüsselt. Welcher ist nun der gesuchte Klartext?

weltio

Was ist hardcoded?
Also stellen wir uns ein Beispiel fernab einer Implementation vor.
Eine Datei mit einer Größe von 1kb wird mit Zufallszahlen XOR-verknüpft.
Diese Zufallszahlen werden meinetwegen alle mit einer Zufallszahl multipliziert.
Der resultierende Schlüssel wird versendet, die Zufallszahl wird irgendwie anders mitgeteilt. (Hängt ja vom Gegenüber ab. Kann also auch die Wortlänge des 25. Wortes auf Seite 3. des Lieblingsbuches sein - das hängt ja auch von der Zufallszahl ab )

Von diesen tausendmilliardenmilliarden Texten kann nur einer lesbar sein

Eydeet

Also, um das ganze mal zu klären:
Wenn du beliebige Daten mit einem gleich langen, zufälligen Schlüssel verknüpfst, hast du ein One-Time-Pad, das nachweislich unknackbar ist.

Was das ganze so sicher macht:
Das Wort "Hallo" könnte genau so als "Hacks" entschlüsselt werden. Beides ist lesbar, und du hast keinen Anhaltspunkt, welches die richtige Entschlüsselung ist.

Schwachstellen in der Praxis sind:
* Der Schlüssel ist kürzer als die Daten, der Schlüssel muss wiederholt werden => Daten in bestimmten/regelmäßigen Abständen sind mit dem gleichen Schlüssel verschlüsselt worden
* Die verschlüsselten Daten/der Schlüssel weisen bestimmte Muster auf (z.B. Text, Datei-Header), sodass einige Möglichkeiten ausgeschlossen werden können, die diese nicht enthalten
* Der Schlüssel ist nicht wirklich zufällig => wenn man den Seed und den benutzten Pseudozufallsgenerator herausfindet, hat man die komplette Nachricht.

valenterry

Du nimmst mir die Worte aus dem Mampfgerät.

Elderan

Hallo,
Naja Psueodzufällig ist eigentlich relativ eindeutig definiert, zumindest in der Kryptographie

) mit dem ASCII-Wert des dirtten Zeichens des PWs multiplizieren und schon kann man die "Zufallsfolge" als "verschlüsselt" gelten lassen.

Da liegst du falsch. Es gibt viele Prozesse die _nachweislich_ wirklich Zufällig sind (gut, daran zweifel auch wieder irgendwelche Philosophen), dazu gehört z.B. radioaktiver Zerfall (wann zerfällt ein instabiler Kern) oder viele Effekte aus der Quantenmechanik (z.B. Photonen die auf einen Strahlenteilerwürfel treffen).
Auch Rauschen ist eine gute Quelle für zufällige Zahlen.

Die Quantenmechanik wird z.B. für Quantenkryptographie verwendet.


Wie schon Eydeet sagte, man kann zwar bei einem 5-stelligen verschlüsselten Text alle Passwörter austesten, erhählt dann aber als Ergebnis alle 5-stelligen Klartexte.

Wenn 'brMve' mit einem One-Time-Pad verschlüsselt wurde, kann daraus:
Hallo, Hacks, Bombe, Krieg, Allah (jetzt wird das Habo bestimmt als Terror-Zelle eingestuft)
resultieren, und jedes dieser Wörter hat die gleiche Wahrscheinlichkeit.
Wie willst du also nun entscheiden, wozu 'brMve' gehört?

(Das impliziert eine Wahrscheinlichkeit von 0, dass man es schafft. Aber würden wir an deiner Zufallstheorie hängen bleiben, würde sich nach n+1 Versuchen das Gegenteil herausstellen, da eine XOR-Verknüpfung, mit heutiger Computertechnik, "nur" mit einer endlichen Zahlenfolge stattfinden kann Ergo ist das Ergebnis auch endlich. Ergo ist der Zeitaufwand auch endlich. Wie hoch letzterer ist, hängt wiederum von der Zahlenfolge selbst und dem verwendeten Dekodierungstechnik ab


Kannst du mir verraten, wie ein zufälliger Ausgang sicher reproduzierbar ist?
Wenn du eine (ideale) Münze 10 mal hochwirfst, erhälst du 10 (mehr oder weniger) zufällige Bits.
Diese 10 zufälligen Bits lassen sich aber nicht wirklich reproduzieren, sofern man den gesamt Ausgang des Ergebnisses nicht kannte.

Anders ist dies bei Pseudozufallsgeneratoren. Gleicher Startwert (gleiche Seed), gleiche 'Zufalls'zahlen, sprich, die (Pseudo-)Zufallszahlen sind reproduzibel sofern man den Startwert kennt.


(endliche Ausgangspunkte, endliche Ergebnisse => "Zufällig" das gleiche Ergebnis (wenn ggf. auch mit anderem Ausgangspunkt - hängt vom Algorithmus ab)))


Wie gesagt, in der Praxis werden echte Zufallsgeneratoren nicht verwendet, weil man dann immer den gesamten Zufallsstream behalten müsste um den Text zu entschlüsseln, welches ja nur das Problem verlagert (vorher musste der Text geheim gehalten werden, jetzt der gleichlange Key).
Deswegen verwendet man einen (determinierten) Algorithmus, der i.d.R. auch noch deterministisch ist, der eine Pseudozufällige Zeichenfolge generiert.
Um an die pseudozufällige Zeichenfolge zu kommen, muss man nur den Startwert des Algorithmus kennen und kann diese gesamte Folge dann generieren.
Wenn der Algorithmus schlecht gewählt ist, lässt sich z.B. die Folge generieren selbst wenn man den Startwert (den Key) nicht kennt.




Nicht unbedingt. Bei schlechten Algorithmen ist alles möglich.
Ansonsten kennt man fast immer Teile der Nachricht bzw. kann sie leicht raten.
Ein Word Dokument mit dem Inhalt 'Hallo Welt' wird ca. 15 KB Speicherplatz brauchen, wobei nur 10 Byte Inhalt vorhanden sind.
D.h., der Angreifer kennt 1490 Byte und kann bei schlechten Algorithmus damit auf die letzten 10 Byte schließen.

Auf die Gefahr hin mich zu wiederhohlen: Wenn der Algo. schlecht ist, sehr hoch.


D.h. du versendet den Geheimtext + die Zufallszahlen ('verschlüsselt') für die XOR-Verknüpfung?

Dann dividiere ich einfach den 'verschlüselten' Zufallsstream durch alle möglichen Zahlen, entschlüssel damit den Geheimtext und gucke ob der Klartext Sinn macht.

Oder anders:
Wenn ich weiß, dass der Text ein deutscher Text wahr ohne Formatierungen etc. nehm ich als an der Klartext wäre 'eee[...]eee'.
Dann schaue ich, mit welcher Zahl ich den Zufallsstream dividieren/entschlüsseln muss, um im Klartext ein 'e' zu erhalten.
Da e sehr oft in der deutschen Sprache vorkommt, wurde es eine Häufung für den richtigen Schlüssel (also deine Wortlänge 25. Wortes auf Seite 3) geben.


PS:
Das ist schonmal eine sehr schlechte Einstellung. Wenn man einen Fachausdruck o.ä. noch nicht kennt, sollte man Google (o.ä.) verwenden und sich entsprechend informieren.
Wenn du dich informierst was ein One-Time-Pad ist, was Pseudozufälligkeit bedeutet (bzw. wie Zufallsgeneratoren funktionieren) oder wie Stromchiffren arbeiten, so düften dir dann vermutlich auch so einige Fragezeichen genommen werden.

weltio

Das dumme daran ist, dass man Zufall schlecht beweisen kann Wieso sollte in einer Welt, in der alles auf dem Prinzip der Aktion und der Reaktion basiert, aufeinmal etwas "zufällig" geschehen?
Kleines Beispiel: Du wirfst eine Münze - der Ausgang ist natürlich (im Idealfall) Kopf oder Zahl.
Nehmen wir an du wirfst Zahl.
Dann nimmst du dir flux ne Zeitmaschine, reist zurück an den Zeitpunkt, an dem du die Münze geworfen hast (du darfst allerdings nur dir beim Münzwurf zugucken ). Dem Zufall zufolge müsste die Wahrscheinlichkeit GENAU dieselbe sein, wie das letzte mal, als du geworfen hast. Nur schade, dass es der Münze scheissegal ist, da ihre Bewegung berechenbar ist, da sie nur von Faktoren abhängig ist. D.h. du würdest in die Zeit zurückreisen und dasselbe Ergebnis nocheinmal sehen, da du ja mit exakt denselben Voraussetzungen geworfen hast (sprich: Stärke, Luftdruck, Konzetration der Edelgase in der Luft Chinas, etc.). Das kannst du tausendmilliardenmilliarden mal probieren und es wird genau aus diesem Grund kein anderes Ergebnis kommen. Also gibt es keinen Zufall.
Selbiges gilt für deine anderen Beispiele.

Ich weiss nicht genau. was dort für Daten entnommen werden. Aber nehmen wir mal an, es werden Zahlen von 1-1000 übernommen. Es gibt zwar viele Möglichkeiten (wird ja pro Pixel berechnet werden müssen, nehme ich an), aber sicher ist das dennoch nicht Aber ich weiss nicht, wieviele Mrd. TFLOPS so ein NASA-Rechner schafft

Also soweit ich weiss, werden bei Zufallsgeneratoren Daten wie die Anzahl der Prozesse, die die CPU bearbeitet hat, Temperatur der Festplatten, Geschwindigkeit des Lüfters etc. abgefragt und irgendwie verrechnet (^^). Von diesem Punkt aus, ist es doch nahezu unmöglich, diese zu reproduzieren. Wo liegt da mein Denkfehler?
Ich kann auch einfach 15 "Pseudozufälle" multiplizieren - da müsste man schon mindestens 15 Werte des PCs kennen. Wie soll man daran kommen? (gehen wir davon aus, dass der Rechner nicht kompromitiert ist, da das die ganze Kryptographie auf den Kopf stellen würde)

Wenn es dir hilft, das modellhaft darzustellen, dann ja.
Gehen wir davon aus, ich habe jedes Bit einer Datei mit einer Zahl, der 46465189,55454866 verXORt. Die Datei und die Zahl bekommt mein Gegenüber, der einfach nur den Algorithmus drüber laufen lässt. Meinem Wissenstand entsprechend, sollte mein Gegenüber nicht in der Lage sein, die Datei ohne Algorithmus und Schlüssel (schon gar nicht ohne Nachricht) entschlüsseln zu können.


Unendliche Zahlenmenge = Unendliche Rechenzeit
Gut, ein Computer kann jetzt nicht mit unendlich Zahlen rechnen, aber die Rechenzeit ist dennoch sehr groß (wie groß ist die größte Zahl, mit der ein Computer rechnen kann?)
S=alle Zahlen; X= "Zufallszahlenstrom"
X*S -> Eine Zahl (oder Zahlenfolge) mit einer "Zufallsgröße" multipliziert.
X*S? -> Eine Zahl (oder Zahlenfolge) mit zwei "Zufallsgrößen" multipliziert.
=> X*S^n, wobei n=Anzahl der Multiplikationen mit "Zufallszahlen"

Aber "e" kann einmal mit 5 und einmal mit 51684169 vverXORt werden... -> Kein Muster

Das sind Dinge die zwei Sätzen bedürfen. Dafür muss man nicht mit Autornamen und anderem um sich schmeißen

valenterry

Nein.

Harry Boeck

Wieder mal eine hübsch zu lesende Diskussion.

Ich würde die Diskussion um die Zufälligkeit allerdings in Bezug auf die kryptographische Sinnfälligkeit auf den praktischen Aspekt beschränken, ob ein betrachteter Prozeß berechenbar (alias vorhersehbar) ist oder nicht. Solange etwas nicht berechenbar ist - tja - KANN es eben nicht berechnet werden und ist damit hinreichend für die Verschlüsselung:
Die philosophischen Auslegungen sind davon vollkommen unberührt: Egal, ob es "tatsächlichen" Zufall nun gibt oder nicht, reicht jeder nicht berechenbare Prozeß als Zufallsgenerator für jenes Anwendungsgebiet aus.

Und unter dieser Beschränkung gibt es viele hinreichende Zufallsfunktionen, angefangen bei dem genannten Rauschen.

Schlagt Euch aber ruhig weiter die Argumente um die Ohren! Den Thread halte ich dadurch empfehlenswert für den Einstieg in das Thema.

+++ATH0

Bei allen gängigen Runtime Librarys, die ich kenne (VB, Delphi, C,...) ist das nicht so wie du sagst. Der Startwert (Random Seed) wird meistens aus der Systemzeit gewonnen und ein bestimmer Algorithmus erzeugt daraus eine Sequenz an Pseudo-Zufallszahlen, die man durchaus nachvollziehen bzw. reproduzieren kann, vorrausgesetzt man kennt den Startwert.
Welcher Algorithmus genau dahintersteckt, weiss ich nicht. Ich vermute mal sowas ähnliches wie der [1] Mersenne-Twister.

[1] http://de.wikipedia.org/wiki/Mersenne_Twister

Elderan

Hallo,

Dies ist so nicht richtig, nicht alles basiert auf dem Aktion-Reaktion. Da ich keine Lust habe dir einen Exkurs in Quantenmechnik zu geben verweise ich mal auf Google, Wikipedia und co.


oO, an Zufall in der Natur nicht glauben aber mal flux ne Zeitmaschine bauen.

Das ist so nicht richtig.
Mal angenommen, du kannst so eine Zeitmaschine bauen wie wir sie aus 'Zurück in die Zukunft' kennen, dann beobachtest du ja einen Prozess der bereits stattgefunden hat und dessen Ausgang bereits feststeht.


Der Münzwurf ist in der Tat nur von Faktoren abhänig, allerdings macht dies ihn noch lange nicht berechenbar. Bekannt auch unter der Chaos-Theorie.
Bei radioaktivem Zerfall bzw. in der Quantenmechanik ist dies anders. Nach den aktuellen Erkentnissen sind diese zufällig.

Das ist aber nicht richtig.
Da du ja anwesend bist beim Wurf, aber nur zuguckst, kann diese minimale Änderung im System schon dazu führen, dass du ein anderes Ergebnis beim Münzwurf erhälst.
Wie dir hoffentlich bekannst ist, ziehen sich alle Massen an, sprich, wenn du beim Münzwurf zuguckst wirkst du anziehend auf die Münze (), und nach der Chaos-Theorie kann diese minimalistische Änderung schon zu einen komplett anderem Ergebnis führen.
Du veränderst aber noch deutlich mehr 'Umgebungsvariablen', z.B. durch deine Anwesendheit beim Münzwurf ändert sich auch (minimalistisch) die Raumtemperatur, somit der Luftdruck usw. usw.

Ähnliches Ergebnis beim Teilchen-Welle-Dualismus bzw. Heisenbergsche Unschärferelation. Nur durch das "(genau) Beobachten" des Vorganges kann man das Ergebnis verändern (ist ja auch bei Schrödigners Katze so, nur wenn man die Kiste aufmacht muss die Katze sich nun entscheiden, ob sie tot oder lebendig ist )

Auch wenn du beim 'zweiten' Wurf, also nachdem du in die Vergangenheit gereist bist, ein anderes Ergebnis erhalten würdest, könntest du nicht feststellen, dass du ein anderes Ergebnis erhalten hast.
Angenommen du wirfst die Münze, es kommt 'Zahl', schreibst dieses auf einen Zettel, flitzt schnell in deine Garage, stetzt denn Brennstab in deine Zeitmaschine und reist in der Zeit zurück zum Zeitpunkt des Münzwurfes.

Jetzt, in der Vergangenheit, wirfst du die Münze und es kommt 'Kopf', du schaust auf deinen Zettel und dort wird 'Kopf' stehen, denn dein Ich in der Vergangenheit hat beim Münzwurf 'Kopf' gesehen und dieses auf den Zettel geschrieben.

Ähnlich (oder eindeutiger) ist es beim Großvaterparadoxon.
Eine Theorie wie es nach dem Mord am Großvater weitergeht ist es, dass dadurch ein parallel Universum entsteht, in einem, indem der Großvater ermordet wurde und in einem, indem er weiterlebt.


Wie du siehst, eignet sich Zeitreisen sehr schlecht um gegen Zufall zu argumentieren.





Dies ist eine gängige Praxis für _sichere_ Zufallszahlen, z.B. bei manchen Linux-Varianten werden die Zahlen die dir /dev/random liefert so generiert, oder der Computer der die Keno Ergebnisse auspuckt ermittelt diese so.
Solche Zufallsgeneratoren füttern dann auch gerne mal kryptographisch sichere (Pseudo)Zufallsgeneratoren, z.B. /dev/urandom




Hä?
Also, wie bereits mehrfach erwähnt, kann man fertigen Programmcode disassemblen und somit an deinen 'geheimen' Algorithmus gelangen. Deswegen sollte man auch stets darauf achten, dass man dem Kerckhoffs? Prinzip 'treu' bleibt.

Dann solltest du ihn aufbessern

Wie gesagt, den Algo. geheim zu halten funktioniert nicht.

Ich seh in deinem Modell oben nicht, wo nun der Schlüssel zum Einsatz kommt.
Wie sieht die Verknüpfung von Schlüssel und '46465189,55454866' aus? Wie generierst du überhaupt diese komische Zahl?




Dann hast du die Vorgehensweise nicht verstanden. Man hat den Zufallsstream, welcher mit einer festen Konstante (deinem Passwort) multipliziert wurde.
Was man nun sucht, ist diese Konstante. Diese zu finde ist relativ leicht, bischen abhängig davon wie du nun den Zufallsstream mit der Konstante multiplizierst.
Dort treten dann Probleme auf, wie z.B. vergrößert sich der Zufallsstream wenn ich ihn multipliziere oder bin ich in einem endlichen Körper/Ring?
Und warum multiplizierst du nicht gleich den Plaintext mit dieser Konstante? Du verlagerst so nur das Problem unwesentlich.

Außerdem, wie würde denn 'e' XOR 51684169 aussehen?


Also deine gesamte Methode ist extrem konfus, ein kleiner Pseudo-Code (verschlüsselung und entschlüsselung) würde helfen, so dass man dir die Schwächen deiner Methode dir aufzeigen kann.

Leider lassen sich Stromchiffren oder OTP's etc. nicht in 2 Sätzen ausreichend beschreiben. Außerdem ist es eigentlich eine Selbstverständlichkeit, sich über entsprechende Wörter zu informieren. Und ich hoffe das dies bei dir nicht anders ist...

Die Glaubwürdigkeit von Aussagen hängt stark vom Anssehen (bzw. der 'Expertenstatus') des Autors ab.
Wenn du sagst, dass IPSec potenziell unsicher ist, könnte man darüber getrost lächeln.
Die gleiche Aussage, dass IPSec potenziell unsicher ist, aus dem Mund von Bruce Schneier und Niels Ferguson hat eine komplett andere Wichtung.

Hat man selber nicht das Anssehen wie Bruce Schneier oder Niels Ferguson, muss man seine Aussagen mit entsprechenden Referenzen untermauern, wobei, selbst diese entsprechend viele Referenzen angeben (Im Buch 'Angewante Kryptographie von Bruce Schneier' sind fast 2000 Referenzen enthalten), da dies gängige Praxis in der Wissenschaft ist.
Eine Aussage, die nicht mit Referenzen gestützt ist, hat nicht viel Wert, sofern diese Aussage nicht der Mehrheit der Leser bereits bekannt ist (z.B. Eis taut bei 0°, hierfür benötigt man i.d.R. keine Referenz).

@+++ATH0:
Leider ist es meistens noch ein deutlich schlechterer Algorihmus.
Aber nicht nur der Startwert entscheidend, sondern auch der Zufallsgenerator an sich.

Es gibt viele Zufallsgeneratoren, wo es ausreicht, eine Zufallszahl zu kenne um dann alle nachfolgenden Zahlen zu berechnen, dies ist der Fall, wenn z.B. die Zahl nur vom Vorgänger abhängt.

Ein Beispiel wäre:
x = (5*x + 7) % 23

In PHP beispielhaft:
Erzeugt folgende Ausgabe:
Solch ein Algorithmus, bzw. eine Abart von diesem, wird in vielen Bibliotheken unter der rand() Funktion implementiert. Für den Alltag auch absolut ausreichend.
Das Problem am obigen Zufallsgenerator ist, wenn ich den Zufallswert '15' kenne, kann ich alle nachfolgenden Zufallswerte (13, 3, 22 ...) berechnen ohne den Startwert kennen zu müssen.

Selbst der Mersenne-Twister eignet sich so nicht für kryptographische Dienste.