Diskussion:RC4

message: 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)
thread_title:  RC4 gebrochen? 

message: 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)
thread_title:  RC4 ist nicht wirklich gebrochen 

message: 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)
thread_title:  Was heißt denn gebrochen ? 

message: 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)
thread_title:  RC4 ist inzwischen definitiv angezählt 

message: 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)
replies: text: 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)
thread_title: SSL und RC4

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

message: 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)
thread_title:  Einleitung: [[Data Encryption Standard|DES]]?! 

message: Sobald das Papier [] 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)
replies: text: Der Angriff von Klein ist mittlerweile veröffentlicht [] 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)
thread_title:  Korrelationsangriff von Klein 

message: 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)
replies: text:  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)
thread_title:  Veralgemeinerung des Pseudocodes 

message: 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)
replies: text: 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)
thread_title:  RC4 die fast perfekte Verschlüsselung 

message: 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)
thread_title:  [[Stromchiffre]] mit [[Hashfunktion]] 

message: 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)
thread_title:  Stimmt - das Verfahren ist nach menschlichem Ermessen sicher! 

message: 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)
replies: text: 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)
replies: text:  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)
replies: text:  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)
replies: text:  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)

text:  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)
thread_title:  Ist die Zufallsfolge von einer echten zu unterscheiden? 

message: 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)
replies: text: 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)
replies: text:  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)
replies: text:  Die Länge ist 256. [] --88.152.231.121 23:58, 10. Mär. 2012 (CET)
thread_title:  S-Box 

message: 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)
replies: text: 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)
thread_title:  Probleme mit addbot 

message: – GiftBot (Diskussion) 01:48, 30. Nov. 2015 (CET)
thread_title:  {{Anker|deadurl_2015-10}} Defekte Weblinks 

message: 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)
thread_title:  Spritz ist nicht allein ein Zufallsgenerator zum Verschlüsseln 

message: 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)
replies: text: Korrigiert. --Matthäus Wander 12:16, 20. Mär. 2023 (CET)
thread_title:  Spritz Performance