Knackbar?

[gdfsdgfsgdf]

Mal ne ernst gemeinte frage:
Kann ein heutiger Supercomputer solch eine Datei nicht in einem akzeptablen Zeitraum entschlüsseln?
Und wenns einen Monat dauert, die Datei ist schon länger on und könnte bereits "bearbeitet" werden...

[bwe47]

Nein.

[Anonymaus]

Grob nach dem gerechnet, was Wiki (http://en.wikipedia.org/wiki/Brute_force_attack) schreibt:

Hättest du einen Cluster, der 10 Billiarden (Milliarde x Milliarde, 10^18) Schlüssel pro Sekunde durchprobieren kann, so würde dein Cluster 3x 10^51 Jahre (das Universum ist grob 17x 10^9 Jahre alt) brauchen.

Der schnellste Supercomputer schafft allerdings "nur" knapp 3 PFlops, d.h. 3x 10^15 Fließkommaoperationen pro Sekunde. Und mit einer einzigen Fließkommaoperation hast noch lange keinen Key ausprobiert und verifiziert.

[fsafas]

also es ist (theoretisch) möglich :-)

[jucs]

Nehmen wir mal an, ein heutiger 3-Ghz-Prozessor könnte in jedem Takt einen Schlüssel probieren. Nehmen wir weiter an, ein Supercomputer verfüge über 10 Million Prozessoren.

Beide Annahme sind weit über der Realität. Insgesamt könnte man also pro Sekunde

3*10^9*10^7 = 3*10^16

Schlüssel durchprobieren. Es gibt

2^256 = 1.16*10^77

solche Schlüssel bei AES256. Der Supercomputer bräuchte also

(1.16*10^77)/(3*10^16*3600*24*365) = 1.23*10^53

Jahre. Das ist ca.

8.92*10^42 ~= 10000000000000000000000000000000000000000000

mal so lange, wie es das Universum schon gibt.

Ja, es gibt Angriffe auf AES, die die Zeit verkürzen. Keiner bringt, nach meinem Wissen, den Aufwand aber auch nur in irgendeiner noch so entfernten Weise in absehbare Reichweite.



1 mal bearbeitet, zuletzt am 02.08.10 20:04 durch jucs.

[lcg]

gdfsdgfsgdf schrieb:
--------------------------------------------------------------------------------
> Mal ne ernst gemeinte frage:
> Kann ein heutiger Supercomputer solch eine Datei nicht in einem akzeptablen
> Zeitraum entschlüsseln?
> Und wenns einen Monat dauert, die Datei ist schon länger on und könnte
> bereits "bearbeitet" werden...

Die kurze Antwort "Nein" hast du schon bekommen. Die längere ist folgende: Das Verfahren verwendet einen 256bit Schlüssel, ein brute force Angriff müsste alle Schlüssel durchprobieren. Statistisch findet man den korrekten Schlüssel nach der Hälfte der Versuche, was uns den Schlüssel um ein bit verkürzt. Bleiben also 2^255 oder rund 5,79*10^76 Schlüssel. Angenommen, man könnte mit einem Rechner 100.000 davon in jeder Sekunde überprüfen (was hoffnungslos unrealistisch ist), dann brauchen wir dazu 5,79*10^71 Sekunden. Das sind über 10^64 Jahre. Das können wir nun mit dem Alter des Universums vergleichen, das beträgt wohl rund 14*10^9 Jahre.

Beantwortet das deine Frage? ;)

HTH,
lcg

[Anonymaus]

Irgendein populärwissenschaftliches Buch hat mal vorgerechnet, in wie vielen Jahre das letzte Proton im Universum zerfällt. Ich finde leider die Zahlen nicht mehr. Sollte das aber vor Ablauf der 3x 10^51 Jahre passieren, ist es nicht einmal theoretisch möglich ;).

[lcg]

fsafas schrieb:
--------------------------------------------------------------------------------
> also es ist (theoretisch) möglich :-)

Klar, man rät einfach nichtdeterministisch den richtigen Schlüssel, dann reicht schon ein Versuch. ;)

Gruß,
lcg

[sdfe]

Kommt das nicht in der neusten Futurama Folge vor?

[iFACE]

Da wir hier bei Golem sind (also Kindergarten) noch was zur Info JEDER Brute-Force angriff auf die Datei ist Sinnlos wenn man nicht den Salt kennt. Das File verwendet auf jedenfall einen Salt, wer mir nicht glaubt sieht sich das file mal näher an...

[fräger]

Selbst wenn man alle Schlüssel durchprobieren könnte, wie verifiziert man denn, wann die Entschlüsselung gelungen ist? Eventuell ist das Verschlüsselte selbst noch einmal verschlüsselt und nicht als etwas "sinnvolles" erkennbar.

[gdfsdgfsgdf]

Top!
Viele Beiträge, eine Antwort.
thx.....

[RC Shad0w]

wieso keine antwort? hast du überhaupt gelesen was die anderen dir vorgerechnet haben. wenn du die zeit hast, ist es knackbar. da du sie aber nicht hast und auch niemand so einen computer besitzt, der für diese aufgabe geeignet wäre, ist es nicht knackbar.

was willst du noch als antwort??

[asdasdasd]

In dem Beitrag steht
Viele Beiträge, EINE Antwort.

[James]

Hab den Schlüssel!!! Mein selbst gebauter Quantenrechner hat ihn in wenigen Sekunden ausgespuckt (Windows hochfahren mit eingerechnet). Nun hab ich diesen wieder verschlüsselt und ins Netz gestellt um mich selber abzusichern!

[Idiotenalarm]

iFACE schrieb:
--------------------------------------------------------------------------------
> Da wir hier bei Golem sind (also Kindergarten) noch was zur Info JEDER
> Brute-Force angriff auf die Datei ist Sinnlos wenn man nicht den Salt
> kennt. Das File verwendet auf jedenfall einen Salt, wer mir nicht glaubt
> sieht sich das file mal näher an...

a) das Salt
b) da scheint jemand seine Captain Crunch Frühstücksflocken nicht ordnungsgemäß gemampft zu haben. Du scheinst wirklich keine Ahnung zu haben, welches Resulat das "Salzen" eigentlich erzielen möchte.
Das ist nur zum Verhindern von der Verwendung von Rainbow Tables und diese würden in diesem Fall auch absolut nichts bringen.

Der Entschlüsselungsaufwand wird sich nicht wirklich erhöhen, selbst wenn ein "salt" verwendet wird. (was sicher nicht der Fall ist.)
Der "Schlüssel" ist logischerweise Zufallsgeneriert beispielsweise über Stellen wie /dev/random
Weswegen es auch relativ lange dauert, bis man einen Schlüssel generiert hat, weil erst weiter gemacht wird, wenn sich wieder genug "Zufallsdaten" angesammelt haben.
Und dann gibt es eben ein Passwort bzw. eine Passphrase, ob das nun ein salt hat oder nicht, macht herzlich wenig unterschied weil man nicht einfach das Passwort-Hash irgendwo auslesen kann.

[Anonymaus]

Idiotenalarm schrieb:
--------------------------------------------------------------------------------
> Der "Schlüssel" ist logischerweise Zufallsgeneriert beispielsweise über
> Stellen wie /dev/random
> Weswegen es auch relativ lange dauert, bis man einen Schlüssel generiert
> hat, weil erst weiter gemacht wird, wenn sich wieder genug "Zufallsdaten"
> angesammelt haben.

Wobei /dev/random nicht unbedingt das beste Beispiel für Zufallszahlen ist ;)

[tinytroll]

Nice to know!
Das stand im PM auch schon mal, lese ich aber nicht mehr, da werden entschieden zu viele Protonen für geschwafel verschwendet.


Anonymaus schrieb:
--------------------------------------------------------------------------------
> Irgendein populärwissenschaftliches Buch hat mal vorgerechnet, in wie
> vielen Jahre das letzte Proton im Universum zerfällt. Ich finde leider die
> Zahlen nicht mehr.

[anonym]

Ich frage mich schon die ganze Zeit, warum die keine One-Time-Pad verwenden. Dann wäre es möglich, jeden denkbaren Inhalt aus den 1,4 GB zu generieren und wüsste nicht, welcher der richtige ist. Somit könnte alles darin stehen.

[Idiotenalarm]

In Verbindung mit entsprechender Hardware wohl schon und /dev/random wird auch als Kryptographisch sicher angesehen. Es gibt keine bekannten Angriffe darauf.

/dev/urandom hingegen ist das "unsichere Pendant", wobei es für ein "zufallsgeneriertes" Passwort wohl noch alle Male ausreichend ist.
Und wohl auch besser als fast alle anderen Implementierungen ist.

"Wirkliche Zufallsdaten" können wohl nur mit entsprechender Crypto-Hardware bezogen werden.

Anonymaus schrieb:
--------------------------------------------------------------------------------
> Idiotenalarm schrieb:
> ---------------------------------------------------------------------------
> -----
> > Der "Schlüssel" ist logischerweise Zufallsgeneriert beispielsweise über
> > Stellen wie /dev/random
> > Weswegen es auch relativ lange dauert, bis man einen Schlüssel generiert
> > hat, weil erst weiter gemacht wird, wenn sich wieder genug
> "Zufallsdaten"
> > angesammelt haben.
>
> Wobei /dev/random nicht unbedingt das beste Beispiel für Zufallszahlen ist
> ;)