RC5 Stats

Da die Rc5 stats ja nun auch offiziell wieder da sind, und da dieser Thread eh leer ist und das ganze auch zu "Statistik" paßt, kommt jetzt meine schon lang versprochene (natürlich gaaanz grobe aber ich werds zu gunsten der Rc5 Fans ansetzen) Hochrechnung, wie lange es dauern würde einen Rc5-X verschlüsselten Text zu brute forcen.
Leech und co werden mich dann wohl steinigen)

Also hier wieder was worüber ihr euch aufregen könnt
13,314,875,358,969,855 keys wurden gesten berechnet.
nun gehen wir mal davon aus der Wert war zu niedrig (was er nicht war aber egal) und rechnen mit 15,000,000,000,000,000
gehen wir weiter davon aus, daß sich dieser Wert täglich nun konstant erhöht.
Und zwar so, daß nach einem Jahr bereits der doppelte speed erreicht wird durch mehr member und schnellere Rechner (völlig utopische Annahme btw wenn man das vergangene Jahr betrachet).
Also nimmt der Speed jeden Tag um 1/365 also für diese Angabe ca. 41,095,890,410,959 keys zu.
Nach einem Jahr sind dann die 30,000,000,000,000,000 keys/Tag erreicht.
Dann nehm ich weiter ein 365-stel von dem Wert, so daß dann wieder nach 365 Additionen der doppelte Speed erreicht wird. (und kommt ma btte jetzt net mit Schaltjahren...)
Die keys/tag zieh ich dann immer vom noch übrigen Gesamtkeyspace (beim 72er z.b. aktuell 4722366482869646000000 - 4517664073306866000 = 4717848818796339134000 keys) ab.

Wenn ich auf 0 bin nehm ich Anzahl der Abzüge geteilt durch 365 dann hamma die Jahre.
Alles klar soweit ?

Als kleines hingeklatschtes VB Proggi sieht das dann z.b. so aus:

x = 4.72236648286965E+21
y = 1.5E+16
z = y

Do Until x <= 0
x = x - z
z = z + (y / 365)
zähler = zähler + 1

If zähler = 365 Then
y = z
zeit = 0
End If

tage = tage + 1
Loop
MsgBox tage
MsgBox tage / 365


Die "grafische" Darstellung hier auf meinen Screen erspar ich euch besser
aber das Ergebnis ist für 100 % des keyspace von heute an:

10718 Tage oder ca. 29,3 Jahre.

Angenommen der key wird nach durschnittlichen 50 % gefunden so wären das für diese, so ziemlich optimistischste mögliche Rechnung, noch ca. 15 Jahre Rechenarbeit. (ich halte eine Speedverdopplung alle 2 Jahre für realistischer, das wären dann also knapp 30 Jahre für 50 %).

Das ganze kann man nun natürlich wunderbar auch für 80 bit, 88 bit, usw. hochrechnen.

Bei 128bit dauerts mit Schleife allerdings bissi zu lange, da müßt ich erstmal drüber grübeln wie ich da draus ne Formel bastel.
Wird dann ggf nachgreicht wenn ichs hab

Hier aber mal paar Werte, ausgehend davon, daß die keys bei diesen Projekten genau so schnell überprüft werden könnten (was auch nicht der Fall ist).

Würde man die Projekte also jetzt starten und jedes Jahr eine Speedverdopplung annehmen (!!!) , so wäre der Zeitaufwand für 100 % Keyspace:

Rc5-80: 171515 Tage oder ca. 470 Jahre
Rc5-88: 274232 Tage oder ca. 7518 Jahre
Rc5-96: 43907692 Tage oder ca. 120295 Jahre

Rest wird noch nachgreicht irgendwann aber ich denke jeder kann hieran erkennen, daß wir das brute-forcen von 128 bit keys definitiv NICHT mehr erleben werden

Wo hast du denn die Info über Quantencomputer her ?
Ich hab ein Buch über Verschlüsselung (ein recht gutes/professionelles so weit ich das beurteilen kann) und dort wird geschrieben, daß es bisher KEINEN Algorithmus gibt, der von Quantencomputren bei symmetrischen Verfahren besonders profitieren könnte.

Lediglich für Assymetrische wie RSA wird angenommen, eine "halbierung" der Bitstärke erreichen zu können, also so daß z.b. 256 bit nur noch 128 bit Sicherheit haben (wegen effizienterer Primfaktorisierung).

Was sich da noch tut muß man zwar abwarten (naja wir werdens auch nimmer erleben...) aber auch Quantencomputer könnten keine Wunder bewirken.

edit: Naja das 72er Projekt wird zumindest noch zu unseren Lebzeiten fertig

jetzt sans nurmehr 30 Jahre? wosn aus deinem "des dalebts sowiso nimmer" worden?

ah des packma schon burschen, auf gehts.

*crunching*

Zitat

Overall Rate: 136,714,691,050 Keys/sec

und fast 55 mkeys davon mach ich...

ich rechne einfach ab und zu in den bunker von freunden...
hab zb. grad mitgeholfen ihren silvesterflush ein bissi fetter zu machen.

ich selbst seh' das ganze dann eher als dauerstabilitätstest für meine aktuellen oc-settings.

me:
http://fritz.distributed.net/partic...8&id=454646

ich wär für einen GPU client...