Diskussion:RC4

RC4 gebrochen?

Hallo zusammen,

warum gilt RC4 als gebrochen? Ist eine Schwachstelle im Algoritmus entdeckt worden? Meines Wissens nach, ist der Algorithus immer noch als sicher einzustufen. Oder liege ich damit falsch?

MFG Alex (nicht signierter Beitrag von 195.233.250.6 (Diskussion) 14:52, 10. Sep. 2004 (CET))

RC4 ist gebrochen. Als erstes wurde der Key-Schedule von RC4 gebrochen. Fängt man die ersten 255 Byte oder so ab, erlauben diese Rückschlüsse auf die S-Boxen der Chiffre und damit auf den Zustand von RC4. Damit kann ein zweiter RC4 initialisiert werden und dieser liefert dann fortlaufend die gleichen Ergebnisse wie der erste. Desweiteren ist RC4 biased. Bei einer sicheren Chiffre sollte die Wahrscheinlichkeit, dass ein Byte x and stelle n steht gleich 1/255 sein. Bei RC4 weichen diese Wahrscheinlichkeiten für einige signifikante Bytes ab. Dazu kommt auch noch, dass die ersten Bytes sehr stark vom verwendeten Schlüssel abhängen, sprich, kennt man die ersten paar Bytes des Schlüsselstromes, kann man schon sehr gute Rückschlüsse auf den Schlüssel ziehen. Ich verweise dich hier mal auf Klein's Attack, Fluhrer, Mantin and Shamir attack, Biased Outputs of the RC4.
--Psygate 10:20, 30. Okt. 2009 (CET)

RC4 ist nicht wirklich gebrochen

Hallo! in RC4 wurde eine Schwachstelle gefunden, die den Autor wohl dazu bewegte zu schreiben, RC4 sei gebrochen.

Und zwar liefern die ersten paar Ausgaben Rückschlüsse auf den Zustand der S-Box zurück, was u.U. zur Kompromitierung des Algorithmus führen könnte. Das lässt sich allerdings ganz einfach umgehen indem man die ersten 256 Ausgaben verwirft.

Weiterhin ist es natürlich empfehlenswert dem Schlüssel eine zufällige beigabe ("Salt") hinzuzufügen, wodurch auch bei gleichem Schlüssel eine unterschiedliche Zufallsfolge austritt. (nicht signierter Beitrag von 84.128.107.163 (Diskussion) 12:03, 13. Sep. 2004 (CET))

RC4 ist quasi gebrochen. Selbst wenn mand ie ersten 256 Bytes des Schlüsselstroms verwirft, ist es immer noch möglich durch statistische Attacken den Schlüssel zu erahnen.

-- Psygate 10:20, 30. Okt. 2009 (CET)

Was heißt denn gebrochen ?

Wenn der Entwickler oder Verkäufer behauptet der Algorithmus hätte eine bestimmte Eigenschaft, könnte man sagen er sei gebrochen, falls der Algorithmus diese Eigenschaft nachweislich nicht hat. Es gibt aber wenig klare Aussagen zu den Eigenschaften des RC4.

In jedem Fall darf der Schlüssel bei RC4 nur einmalig verwendet werden und wie bei WEP gezeigt, dürfen die einmaligen Schlüssel nicht durch einfaches Zusammensetzen mit einem festen geheimen Schlüssel gebildet werden. Unter diesen Voraussetzung dürfte der RC4 weitgehend sicher sein. Dies ist allerdings auch kein Kunststück.(nicht signierter Beitrag von Fsswsb (Diskussion | Beiträge) 11:14, 5. Mär. 2006 (CET))

Gebrochen bedeutet im kryptographischen Sinne eine Attacke, die schneller ist als die Exhaustion-Search (Brute Force).

-- Psygate 10:20, 30. Okt. 2009 (CET)

RC4 ist inzwischen definitiv angezählt

Inzwischen (2013) gibt es einen neuen Angriff, der die Verwendung von RC4 mit TLS (und auch in einigen anderen Fällen) längerfristig gesehen nicht empfehlenswert macht. Ich habe den entsprechenden Satz aus der englischsprachigen WP frei übersetzt. Es wäre soll, wenn sich jemand den Satz anschauen könnte. Insbesondere mit "mehrmals" bin ich noch nicht ganz zufrieden, weil doch einige Übertragungen nötig sind.

--2001:4CA0:200:3:200:5EFE:8D54:4514 18:53, 14. Aug. 2013 (CEST)

SSL und RC4

Wird nicht bei SSL sehr häufig RC4-128 eingesetzt? Das wäre dann ja sicherheitsmäßig äußerst "suboptimal". --Captain Crunch 14:45, 9. Okt 2005 (CEST)

Das SSL Protokoll ist als sicher anzusehen, obwohl RC4 suboptimal ist. [1]

--vPsygate 10:20, 30. Okt. 2009 (CET)

Inzwischen wird von RC4 abgeraten, bis alle Browser TLS1.2 und AES-GCM unterstützten ist es aber noch immer sinnvoll, es zu verwenden. "Siehe RC4 ist inzwischen definitiv angezählt" oben. -- 2001:4CA0:200:3:200:5EFE:8D54:4514 18:53, 14. Aug. 2013 (CEST)

Bedeutung von RC

Laut FAQ Nr. 3 auf der Homepage von Ron Rivest [[2]] bedeutet RC "Ron's Code" und nicht "Ron's Cipher".(nicht signierter Beitrag von Lipilly (Diskussion | Beiträge) 21:54, 9. Feb. 2006 (CET))

Einleitung: DES?!

Im 5. Absatz der Einleitung ist plötzlich – und für mich ziemlich unmotiviert / deplaziert – von DES die Rede bzw. die Schreibe; ich finde, das sollte jemand ausbügeln (d.h. entweder Erwähnung von DES ganz vermeiden, oder Zusammenhang / Bezug zu RC4 erklären), ich fühle mich aber nicht dazu berufen. — Nol Aders 14:29, 30. Mär. 2007 (CEST)

Korrelationsangriff von Klein

Sobald das Papier [[3]] von Andreas Klein in der Zeitschrift "Designs, Codes and Cryptography" veröffentlicht wird, sollten wir einen Abschnitt und eine Literaturangabe dazu einfügen. Der neue Angriff ist allgemeiner als der von FMS und deshalb erwähnenswert. --HeikoStamer 21:15, 5. Apr. 2007 (CEST)

Der Angriff von Klein ist mittlerweile veröffentlicht [[4]] und hat alle Prüfungen überstanden. Hiermit ist es bei beliebiger Wahl des Schlüssels möglich, RC4 rein statistisch anzugreifen, die Anzahl der benötigten beobachteten Sitzungen liegt je nach Angriffsversion unter 100000. Auch ein verwerfen der ersten 256 Ausgabewerte reicht nicht mehr, um den Algorithmus zu schützen. Dies sollte in dem Artikel unbedingt erwähnt werden. --81.210.194.83 14:13, 13. Jun. 2009 (CEST)

"Sicherheit"

Zitat: Durch ein einfaches XOR mit entsprechend berechneten Masken lassen sich Beträge und Kontonummern verändern (z.B. 1000 addieren), wobei der Betrug nur mit einer gewissen Wahrscheinlichkeit auffällt. Allerdings besteht für den Angreifer lediglich die Möglichkeit der ungezielten Fälschung. Er kann kein bestimmtes Zielkonto angeben und auch den verschlüsselten Text nicht lesen.

Zitat Ende

1. 1000 zu addieren ist eine gezielte Fälschung, da sie sich nur unter Kenntnis des tatsächlich veranlassten Betrags zu einer Bitmaske umformen lässt, die dann ge-XOR-t den Betrag um 1000 erhöht. Als Beispiel ist es also falsch Kennt man den Klartext, so kann man WEP-Pakete an beliebiger Stelle gezielt verändern.

2. Da CRC auch auf XOR basiert, kann ein MIM-Angreifer diesen Teil des Paketes in jedem Fall konsistent zu seinen anderen Modifikationen ändern. Es besteht also auch keine "gewisse Wahrscheinlichkeit" im WEP-Verfahren, mit der eine Veränderung bemerkt werden kann, sondern höchstens ein Plausibilitätscheck auf derAnwendungsebene.

Außerdem möchte ich die Frage aufwerfen, was die WEP-Schwachstelle in diesem Detailgrad in einem Artikel zu RC4 zu suchen hat. Thematisch sollte das m.E. hier stehen: Wired_Equivalent_Privacy#Schwachstellen

Veralgemeinerung des Pseudocodes

Ich wollte anfragen, ob der Pseudocode nicht veralgemeinert werden muss um allgemein gültig zu werden!

Die Zahl 256 erscheint hier als 'Magic-Number'

Der Algorithmus funktioniert aber für jeden beliebigen Zeichensatz (nicht nur für Zeichen (Bytes) der Grösse eines Oktets)

Folgender Vorschlag:

Initialisierung:

 Setze j = 0
 Setze k[] = (Schlüssel-Zeichenfolge beliebiger Länge > 0)
 Setze s[] = (sBox-Zeichenfolge in der sämtliche möglichen Zeichen Platz finden)
 Für i= 0 bis LängeVon(s)
   s[i] = i
 j = 0
 Für i = 0 bis LängeVon(s)
   s[i] = i
   j = (j + s[i] + k[i mod LängeVon(k)]) mod LängeVon(s)
   vertausche(s[i],s[j])

und

Code:

 Setze i = 0 und j = 0
 Wiederhole für alle Zeichen des Nachrichtenstroms
   i = (i + 1) mod LängeVon(s)
   j = (j + s[i]) mod LängeVon(s)
   vertausche(s[i],s[j])
   Zufallszeichen=s[(s[i]+s[j]) mod LängeVon(s)]
   ChiffreZeichen=Zufallszeichen XOR (nächstes Zeichen des Nachrichtenstroms)

--Reto.koenig 11:01, 22. Jul. 2008 (CEST)

Beim Durchforsten der anderen Artikel ist mir der Russische ins Auge gesprungen, welche als mod stets $2^{n}$ wählte!

Somit würde folgende Anmerkung in den Hauptartikel einfliessen:

 Die verwendeten Zeichen basieren auf einem Zeichensystem der Grösse $2^{n}$ (so z.B. $2^{8}$ für ein Byte)

Und der Pseudocode würde folgendermassen lauten:

Initialisierung:

 Setze j = 0
 Setze k[] = (Schlüssel-Zeichenfolge beliebiger Länge > 0 )
 Setze s[] = (sBox-Zeichenfolge der Länge 2^n)
 Für i= 0 bis LängeVon(s)
   s[i] = i
 j = 0
 Für i = 0 bis LängeVon(s)
   s[i] = i
   j = (j + s[i] + k[i mod LängeVon(k)]) mod LängeVon(s)
   vertausche(s[i],s[j])

und

Code:

 Setze i = 0 und j = 0
 Wiederhole für alle Zeichen des Nachrichtenstroms
   i = (i + 1) mod LängeVon(s)
   j = (j + s[i]) mod LängeVon(s)
   vertausche(s[i],s[j])
   Zufallszeichen=s[(s[i]+s[j]) mod LängeVon(s)]
   ChiffreZeichen=Zufallszeichen XOR (nächstes Zeichen des Nachrichtenstroms)

Falls also niemand einen Einwand erhebt, werde ich ab dem 30.07.2008 den Hauptartikel dahingehend ändern.

--Reto.koenig 11:34, 22. Jul. 2008 (CEST)

Rein mathematisch gesehen benötigt RC4 kein Alphabet mit 2^n Zeichen. Dies ist lediglich daher sinnvoll, dass im Binärsystem Alphabete dieser Art besonders einfach darstellbar sind und somit optimal für effiziente Algorithmen geeignet. In der allgemeinen Beschreibung des Algorithmus kann denke ich allerdings trotzdem ein allgemeines n stehen, vielleicht mit dem Hinweis, dass in den gängigen Anwendungen n=256 gewählt wird. --81.210.194.83 14:18, 13. Jun. 2009 (CEST)

RC4 die fast perfekte Verschlüsselung

Um so länger ich darüber nachdenke, um so mehr muss ich mit dem Kopf schütteln. Dieser RC4-Algorithmus ist ja nun tatsächlich extrem simpel, aber trotzdem lässt sich damit eine nahezu perfekte Verschlüsselung realisieren. Was sind die Anforderungen an eine perfekte Verschlüsselung?

• Die Geheimhaltung ist immer gewährleistet, sofern der Schlüssel oder das Passwort nicht vollständig bekannt ist.

• Selbst wenn das Verfahren öffentlich bekannt ist und sogar wenn größere Mengen an Klartext und zugehörenden Chiffren vorliegen, bleibt die Geheimhaltung gesichert.

• Das Verfahren ist öffentlich von vielen Experten geprüft.

• Die Implementierung ist mit praktisch jeder Soft- und Hardware möglich.

• Der Resourcenverbrauch, Arbeitsspeicher, der Umfang des Quelltexts und die Laufzeiten minmal sind und der Quellcode so überschaubar ist, dass die Implementierung leicht geprüft werden kann.

RC4 erfüllt all diese Anforderungen, falls das Passwort einmalig verwendet wird. Zum Beispiel als:

Passwort_Neu = h(Passwort + laufende Nummer) oder

Passwort_Eeu = h(Passwort + Tagesdatum) mit der Hashfunktion h gleich SHA-1 oder SHA-256 

gewählt wird.

Stromchiffre mit Hashfunktion

Eine Stromchiffre auf Basis von SHA mit

Zufall( counter ) = SHA-X ( Passwort + counter )

mit X größer oder gleich 1 unterscheidet sich praktisch nicht von einem One-Time-Pad, wenn das Passwort nur zur Berechnung einer einzigen Zufallsfolge benutzt wird. Dies folgt aus den Eigenschaften der SHA-Algorithmen. Das Argument der Hashfunktion SHA-X wiederholt sich unter diesen Voraussetzung niemals. Da sogenannte Kollisionen für SHA-X praktisch nicht berechnet werden können wiederholt sich auch die Zufallsfolge nicht und es ist ausgeschlossen das Passwort aus der Zufallsfolge zu bestimmen. Diese Verfahren können praktisch nicht verbessert werden. Sie sind schneller als die Datenübertragung, so sicher wie das Passwort, leicht zu implementieren, auf jeder Hard- und Software. Was will man mehr?

Auf Details der Implementierung etwa bei der Berechnung des Zählers

 counter = start + step

können die Werte für Startwert und Schrittweite nahezu beliebig gewählt werden. Diese Parameter könnten auch abhängig vom Passwort gewählt werden. Die Zufallsfolge könnte auch in Abhängigkeit der bereits berechneten Chiffre berechnet werden.

 Zufall( counter ) = SHA-X ( Passwort + counter + chipher (counter - 1) )

Jeder kann auch seine persönliche Chiffre mit einem persönlichen Schlüssel key benutzen.

 Zufall( counter ) = SHA-X ( key + Passwort + counter + chipher (counter - 1) )

Was will man also mehr? --84.59.236.35 13:05, 23. Nov. 2008 (CET)

Stimmt - das Verfahren ist nach menschlichem Ermessen sicher!

Zitat aus Stromchiffre:

Bei hohen Sicherheitsanforderungen ist eine Grundforderung, dass sich der Schlüsselstrom nicht wiederholen darf. Dies kann beispielsweise dadurch erreicht werden, dass eine Einwegfunktion zur Erzeugung des Schlüsselstroms implementiert wird und kein zyklischer Pseudorandomgenerator. Stromchiffrierungen können dann nahezu die Sicherheit vom One-Time-Pad Verfahren erreichen.

Durch die Verwendung des Zählers (counter) ist der „Pseudorandomgenerator“ definitiv nicht zyklisch. Es kann definitiv ausgeschlossenen werden, dass sich Werte des Zählers und damit der Argumente der Hashfunktion (Einwegfunktion) wiederholen. Der Zähler kann als Zustandsgröße des „Pseudorandomgenerator“ betrachtet werden, die sich niemals wiederholen kann. Die Sicherheit erreicht nahezu die Sicherheit des One-Time-Pad also nahezu beweisbare absolute Sicherheit. In der Praxis bedeutet dies, das Verfahren ist so sicher wie die Geheimhaltung der Passworte. Dies gilt auch für RC4 falls das Passwort als

 password ( counter/date ) = SHA-X ( master password + counter/date )

berechnet wird. --88.68.100.230 20:48, 24. Nov. 2008 (CET)

Was ist daran so merkwürdig?

Die Tatsache dass es längst ein Verfahren, eigentlich eine ganze Menge ähnlicher Verfahren zur Verschlüsselung gibt, die allen sinnvollen Anforderungen genügen. Wobei die Performance faktisch nur durch die Datenübertragung oder das Schreiben bzw. Lesen von einem Speichermedium begrenzt ist. Die Verfahren also faktisch nicht wesentlich verbessert werden können. Aber noch Anfang dieses Jahrtausends wurden Software-Implementierungen bestimmter Algorithmen unter Exportverbot gestellt, weil diese wundervollen Entwicklungen ungeheuer wertvoll und sogar kriegsentscheidend seien. Um die Jahrtausendwende erschien jede Menge Literatur zu dem Thema, eine merkwürdige Diskussion über „starke Kryptographie“ wurde angestoßen. Weltverbesserer führten einen heldenhaften Kampf gegen die Geheimdienste, um die Bürger dieser Welt mit Software für starke Kryptographie zu versorgen. Dann werden auch noch ganze Firmen gegründet, die mit dem Public Key Sicherheit ohne Vertrauen in irgend einen Menschen versprachen, die an der Börse für Milliarden gehandelt werden. Die wundersamen „Produkte“, die diese grandiosen Firmen vertreiben und die Programme der Weltverbesserer erweisen sich aber im Nachhinein als eher unsicherer im Vergleich mit den verschmähten zuverlässigen Algorithmen, die vermeintlich vom Geheimdienst manipuliert waren. Ja, da kann ich nur den Kopf schütteln. --84.59.133.33 14:15, 21. Nov. 2008 (CET)

"Weltverbesserer führten einen heldenhaften Kampf gegen die Geheimdienste"

Gäbe es die "Weltverbesserer" nicht lebten wir immer noch in der Steinzeit. Sehr reaktionär Herr Gartenzwerg.

"im Vergleich mit den verschmähten zuverlässigen Algorithmen, die vermeintlich vom Geheimdienst manipuliert waren."

Gemeint ist wohl DES entwickelt von der NSA dem Welt-Spitzelverein,der sogar Industriespionage betreibt. Ganz zu schweigen von der Ganz normalen Computerkriminalität von der der Geheimdienst selbst auch nicht gefeit ist; zumal Geheimdienste meistens selbst krimminell handeln (Ist Ja alles geheim ! Und den G-10-Ausschuss kann man in der Pfeife rauchen) Man muß sich nur mal die Spoinageaffäre 2013 ansehen (de.wikipedia.org/wiki/Überwachungs-_und_Spionageaffäre_2013). 31.19.66.70 11:33, 25. Jul. 2013 (CEST)

Ist die Zufallsfolge von einer echten zu unterscheiden?

Würde RC4 eine echte Zufallsfolge benutzen, wäre RC4 ein One-Time-Pad und somit exakt mathematisch beweisbar absolut sicher. RC4 kann folglich nur geknackt werden, wenn die Pseudo-Zufallsfolge von einer echten Zufallsfolge zu unterscheiden ist. Um die Frage zu klären wie schwer dies ist habe ich einmal ein Statistik-Programm geschrieben:

#include<stdio.h>

main(){

unsigned char s[256];
char key[] = "Key";
char txt[] = "Plaintext";
int h[256];

int i,j;
int k=0;
for (i=0;i<256;i++) s[i] = i;
for(i=0,j=0;i<256;i++){
  unsigned char tmp;
  j = (j + s[i] + key[i % strlen(key)]) % 256;
  tmp = s[i];
  s[i] = s[j];
  s[j] = tmp;
}
i = j = 0;
do {
   unsigned char tmp;
   i = (i + 1) % 256;
   j = (j + s[i]) % 256;
   tmp = s[i];
   s[i] = s[j];
   s[j] = tmp;

   printf ("%02x",
          (unsigned char) txt[k] ^
          (unsigned char) ( s[(s[i] + s[j]) % 256] )
          );
}  while (txt[++k] != 0);
printf("\n");

for (k = 0; k < 256; k++) h[k] = 0;

for (k = 0; k < 1000000; k++){
   unsigned char tmp;
   i = (i + 1) % 256;
   j = (j + s[i]) % 256;
   tmp = s[i];
   s[i] = s[j];
   s[j] = tmp;
   h[ s[(s[i] + s[j]) % 256] ]++;
}

for (k = 0; k < 256; k++)
     printf("%02x %d\n", k, h[k]);

}

Erst wird für einen Testfall (siehe en:RC4) die RC4-Verschlüsselung berechnet, um zu zeigen, dass der Algorithmus korrekt implementiert ist. Dann werden von der Pseudozufallsfolge noch eine Million weitere Werte (Bytes) berechnet, wofür ein üblicher Rechner weniger als eine Sekunde benötigt. Die Häufigkeit der einzelnen Byte-Werte wird berechnet und zum Schluss ausgegeben. Im Mittel liegt die Häufigkeit bei einer Million geteilt durch 256 und weicht nur in etwa einem Drittel der Fälle mehr als die Wurzel aus dieser Zahl von diesem Erwartungswert ab. Die Verteilung ist also nahezu perfekt statistisch verteilt. Zumindest wenn der Zufallsgenerator wirklich zufällig initialisiert wird, gibt es nicht den geringsten Anhaltspunkt für die Entschlüsselung.

Mein Fazit: Stromchiffren sind praktisch nicht praktisch nicht zu knacken, es sei denn ein Schlüssel würde mehrfach verwendet. Die Sicherheit entspricht der Geheimhaltung der Schlüssel oder Passworte. --84.59.226.31 12:44, 27. Nov. 2008 (CET)

Welchen Bezug haben Deine Aussagen zum Inhalt des Artikels? Die Diskussionsseiten dienen AFAIK der Diskussion des Artikelinhalts und nicht der Theoriefindung. --HeikoStamer 22:37, 27. Nov. 2008 (CET)

Unter welchen Bedingungen der RC4 sicher ist, also nicht geknackt werden kann ist doch durchaus Gegenstand des Artikels. Weit überraschender als die Tatsache, dass RC4 bei nicht zufälliger Wahl der Passworte unsicher sein kann, ist dass dieser eher simple Algorithmus bei einer vollständig zufälligen Wahl des Passworts keine wirklich entscheidenden Schwächen besitzt, obgleich er über Jahrzehnte so genau studiert wurde, wie kaum sonst ein Verfahren. Auffallend ist dabei, dass es beim RC4 nicht mehrere Runden, also mit etwas geänderten Parametern mehrfach durchgeführte Berechnungen, gibt. Denkbar wäre es zum Beispiel nur jedes zehnte berechnete Byte zur Verschlüsselung zu nutzen oder die Summe modulo 256 von je zehn Bytes zu benutzen. Der Algorithmus wäre dann immer noch schnell genug. Auffallend ist auch, dass der Schlüssel nur in die einmalige Initialisierung der S-Box eingeht und danach nicht mehr gebraucht wird. Es wäre aber möglich die Addition des Schlüssels auch in der weiteren Berechnung fortzuführen. Ich könnte mir tausende Variationen des RC4 vorstellen, die höchst wahrscheinlich keinen negativen Effekt auf die Sicherheit hätten. Tatsächlich gibt es ja auch eine Reihe anderer Stromchiffren, die als mindestens so sicher wie der RC4 gelten. Wenn sich jetzt irgend jemand, zum Beispiel Herr Müller, irgend einen simplen Algorithmus ausdenkt und auch noch selbst programmiert, ist dies wahrscheinlich mindestens so sicher wie der RC4. Ja, selbst wenn er einen groben Schnitzer einbauen würde, solange der Algorithmus geheim bleibt, würde trotzdem niemand den Algorithmus knacken, weil es sich kaum lohnt den privaten Algorithmus von Herrn Müller zu knacken. Eine einfache Stromchiffre ist für den Hausgebrauch praktisch nicht zu knacken. Warum wird da ständig geforscht, wenn es die (fast) perfekte Verschlüsselung längst gibt. --88.68.102.151 19:10, 2. Dez. 2008 (CET)

Du bist herzlich eingeladen Deine Gedanken in der wissenschaftlichen Gemeinde zu diskutieren, z.B. indem Du Deine Argumente zur (Un-)Sicherheit von RC4 in schriftlicher Form bei einer Fachkonferenz einreichst. Wikipedia ist doch kein allgemeines Diskussionsforum. Es sollten nur wissenschaftlich gesicherte Aussagen im Artikel stehen. Ich sehe nicht, wo Deine Ausführungen zur Qualität des Artikels beitragen. --HeikoStamer 19:40, 6. Dez. 2008 (CET)

Es gibt doch schon unzählige Veröffentlichungen zur (Un-)Sicherheit von RC4. Ich denke es reicht wirklich! Der Witz bei der Sache ist doch, dass trotz all dieser eingehenden Untersuchung des RC4 nichts bekannt ist, wie er geknackt werden kann, wenn die Passwörter einmalig und auch nicht sehr ähnlich, wie etwa geheimnis1, geheimnis2, geheimnis3, … oder so ähnlich gewählt werden. Sollte etwa dieser RC4 wirklich extrem raffiniert sein, so dass gerade diese Stromchiffre nicht zu knacken ist? Unsinn – es gibt etliche gut untersuchte Stromchiffren, die mindestens ebenso sicher sind, wahrscheinlich aber noch viel schwerer zu knacken sind. Tatsächlich lassen sich quasi unendlich viele Zufallsreihen konstruieren. Zum einen könnte statt mit der Identität, s[i] = i, auch mit einer anderen Permutation begonnen werden, der RC4 also in einem kleinen Details variiert werden, etwa s[i] = (i + 7) mod 256, statt s[i] = i. Wobei statt der Sieben natürlich auch eine andere Zahl genommen werden könnte. Jetzt könnte aus zwei oder mehreren Zufallsreihen eine neue Reihe gewonnen werden, in dem die Zufallszahlen etwa per XOR verknüpft werden oder sonst irgendwie „addiert“ werden. Damit werden die Eigenschaften bezüglich Sicherheit, etwa die statistische Verteilung, keineswegs schlechter. Es gibt also unendlich, mal unendlich, mal unendlich viele Möglichkeiten, alle mindestens so sicher wie RC4. Noch besser, wenn niemand weiß, wie die Zufallsreihe genau berechnet wird, ist es noch viel schwerer das Verfahren zu knacken. Bleibt das Passwort geheim und kann nicht erraten werden, ist eine solche Chiffre praktisch nicht zu knacken. --84.59.253.114 22:13, 6. Dez. 2008 (CET)

Stimmt, eine (geheime) Arcfour-Variante ist total einfach, aber quasi unknackbar. (nicht signierter Beitrag von 88.152.231.121 (Diskussion) 17:25, 25. Jan. 2012 (CET))

S-Box

Wieso von 0 bis 255? Hängt die Länge der S-Box nicht von der Länge des Schlüssels ab? Oder sind alle Schlüssel 8 Bit lang? (nicht signierter Beitrag von 89.53.202.139 (Diskussion | Beiträge) 14:35, 20. Jun. 2009 (CEST))

Die S-Box enthält 256 Bytes also 2048 Bit. Die Schlüssellänge ist beliebig bis zu 256 Bytes wählbar. Hmmm - stimmt, im Artikel steht es etwas anders. Eigentlich ist die Darstellung des Algorithmus Artikel nicht korrekt (vergleiche en:RC4). Der dargestellte Algorithmus ist eine Verallgemeinerung. --OlbersD 16:32, 24. Jul. 2010 (CEST)

Genauer untersucht wurde der Algorithmus nur mit der Länge 256. Zumindest bei bei kleinerer Länge erscheint die Sicherheit eher fraglich. Mit größerer Länge wird der Speicherbedarf unnötig erhöht. Für die Länge 256 werden je 8 Bit, also ein Byte, gleichzeitig berechnet. Da die Daten üblicher Weise byteweise verarbeitet werden, ist damit die Implementierung besonders einfach. Die Länge zu variieren erscheint daher nicht unbedingt sinnvoll. --OlbersD 16:43, 24. Jul. 2010 (CEST)

Die Länge ist 256. [[5]] --88.152.231.121 23:58, 10. Mär. 2012 (CET)

Probleme mit addbot

Dieser sch**** Addbot hat meine Änderung zurückgesetzt mit der Begründung ARC4=RC4. Dies stimmt aber nicht. ARC4 ist RC4 bei dem die ersten 256 Bits bzw. Die Ausgabe der ersten 12 Runden aus Sicherheitsgründen verworfen wird. Kann das bitte jemand wiederherstellen und Sichten bevor irgendein Bot das macht? (nicht signierter Beitrag von 91.19.36.59 (Diskussion) 18:32, 13. Jun. 2013 (CEST))

wie kommst du auf Addbot? das war ich, die begruendung habe ich im kommentar angegeben. deine quelle hat einfach unrecht, ARC4 ist die oeffentlich bekanntgewordene version von RC4 und die beiden werden auch im RFC gleichgesetzt. --Mario d 19:16, 13. Jun. 2013 (CEST)

Defekte Weblinks

Dieser Baustein verhindert die automatische Archivierung dieses Abschnitts und seiner Unterabschnitte.

Die folgenden Weblinks wurden von einem Bot („GiftBot“) als nicht erreichbar erkannt.
Ausführliche Erläuterungen und Hilfe zur korrekten Behebung dieser Fehler finden sich auf Wikipedia:Defekte Weblinks. Ist ein von einem Bot als defekt gemeldeter externer Link doch erreichbar, dann bitte berichten – wie auch sonstige Probleme.

• http://www.wisdom.weizmann.ac.il/~itsik/RC4/Papers/Rc4_ksa.ps
  • Vielleicht ist eine archivierte Version geeignet: archive.org
  • Wechsel zwischen http und https erforderlichhttp://giftbot.dwl.invalid/http://www.wisdom.weizmann.ac.il/~itsik/RC4/Papers/Rc4_ksa.ps
• http://www.deutsche-finanzagentur.de/private-anleger/publikationen/aktuelle-meldungen/einzelnews/?tx_ttnews%5Btt_news%5D=10&cHash=96be0f72bff99b1135ae62ae2be1369c
  • Vielleicht ist eine archivierte Version geeignet: archive.org
  • Wechsel zwischen http und https erforderlichhttp://giftbot.dwl.invalid/http://www.deutsche-finanzagentur.de/private-anleger/publikationen/aktuelle-meldungen/einzelnews/?tx_ttnews%5Btt_news%5D=10&cHash=96be0f72bff99b1135ae62ae2be1369c
• http://www.wisdom.weizmann.ac.il/~itsik/RC4/rc4.html
  • Vielleicht ist eine archivierte Version geeignet: archive.org
  • Wechsel zwischen http und https erforderlichhttp://giftbot.dwl.invalid/http://www.wisdom.weizmann.ac.il/~itsik/RC4/rc4.html

– GiftBot (Diskussion) 01:48, 30. Nov. 2015 (CET)

Spritz ist nicht allein ein Zufallsgenerator zum Verschlüsseln

Spritz ist damit nicht nur als Nachfolger von RC4 zu betrachten. Spritz ist auch eine Hashfunktion. --Franz Scheerer aus Wiesbaden (Diskussion) 13:06, 16. Jan. 2023 (CET)

Spritz ist der Nachfolger - warum gibt es dazu nicht mehr Informationen?

• https://eprint.iacr.org/2016/856.pdf

--Franz Scheerer aus Wiesbaden (Diskussion) 10:47, 26. Jan. 2023 (CET)

Weil du die noch nicht in den Artikel oder einen ggf. neu dafür anzulegenden Artikel eingearbeitet hast ;-)

Sei mutig und mach' das! --2A02:8070:6382:ECE0:54DE:BF2D:99E8:D274 09:03, 22. Mai 2023 (CEST)

Spritz Performance

Der Algorithmus ist nur etwa halb so schnell wie RC4, aber noch immer wesentlich schneller als standardisierte Blockchiffren wie der Advanced Encryption Standard.

Laut den Einzelnachweisen 15 und 16 ist Spritz wesentlich langsamer als AES. Die Squeeze-Funktion von Spritz erreicht 94 MB/s, AES-CTR 152 MB/s. Hier ist noch eine Quelle Seite 39: AES in Software 59 MB/s, AES in Hardware 329 MB/s, RC4 227 MB/s, Spritz 51 MB/s. --Matthäus Wander 22:35, 19. Mär. 2023 (CET)

Korrigiert. --Matthäus Wander 12:16, 20. Mär. 2023 (CET)