Blake?

[ethel]

wäre imho eine bessere alternative gewesen. zwar nicht ganz so leicht zu implementieren, dafür aber resistenter gegen brute-force angriffe mit gpus.

PS: Hier noch die Original Pressemitteilung vom NIST - die hat golem nämlich nciht verlinkt: http://www.nist.gov/itl/csd/sha-100212.cfm



1 mal bearbeitet, zuletzt am 03.10.12 16:50 durch ethel.

[c3rl]

ethel schrieb:
--------------------------------------------------------------------------------
> wäre imho eine bessere alternative gewesen. zwar nicht ganz so leicht zu
> implementieren, dafür aber resistenter gegen brute-force angriffe mit
> gpus.

Das is aber garnicht das Ziel der SHA-Algorithmen. Die sollen möglichst schnell sein und sicht nicht speziell auf sicherheitsrelevante Bereiche ausgelegt. Da emfpiehlt sich dann z.B. BCrypt oder PBKDF2.



1 mal bearbeitet, zuletzt am 03.10.12 17:50 durch c3rl.

[__destruct()]

2^63 Möglichkeiten wie bei dem seit 2005 bekannten Angriff auf SHA-1 überzeugen aber nur noch Politiker von angeblicher Sicherheit und werden von jedem, der Wert auf Sicherheit legt, als Witz empfunden. Zum Vergleich: Bei einem Pool von 95 Zeichen entspricht das nur 9-10 Zeichen.

Und wenn ich schon bei Sicherheit von Passwörtern bei Verschlüsselungen bis: Ab 2^256 Möglichkeiten kann man imho von Sicherheit sprechen. Dann lohnt es sich in den meisten Fällen nämlich, alle realistischen Passwörter auszuprobieren. 2^256 Möglichkeiten entsprechen einem Passwort von 39 Zeichen Länge bei einem Pool von 95 Zeichen.

Ich komme mir verarscht vor, wenn ein normales Passwort viel schwerer zu erraten ist, als das, das dahinter steckt, zu bruteforcen. Hat man ein Passwort von 30 Zeichen Länge, dann sollte es im Hintergrund auf jeden Fall mehr als 2^197 Möglichkeiten (entspricht einem 30 Zeichen langen Passwort) geben.

[bstea]

Ich spiele mal den Erklärbär für dich, weil du offensichtlich Lücken hast; dein geschriebene Text ergibt nicht besonders viel Sinn.

Wenn ich zwei beliebige Texte so gestalten kann, dass die krypt. Prüfsumme identisch ist, dann ist eine Kollision gefunden.

Dein Beispiel mit dem Passwort ist somit völlig daneben.

--
http://www.heise.de/open/meldung/Linux-auf-dem-Desktop-Europa-fuehrt-1243708.html
http://www.heise.de/newsticker/meldung/Immer-mehr-Linux-auf-dem-Desktop-1404775.html

[__destruct()]

bstea schrieb:
--------------------------------------------------------------------------------
> Ich spiele mal den Erklärbär für dich, weil du offensichtlich Lücken hast;
> dein geschriebene Text ergibt nicht besonders viel Sinn.
>
> Wenn ich zwei beliebige Texte so gestalten kann, dass die krypt. Prüfsumme
> identisch ist, dann ist eine Kollision gefunden.
>
> Dein Beispiel mit dem Passwort ist somit völlig daneben.

Dann spiele ich auch mal den für dich: Mein Text ist in 3 Absätze gegliedert. Im ersten geht es ums eigentlich Thema. Am Anfang des zweiten Absatzes steht "Und wenn ich schon bei Sicherheit von Passwörtern bei Verschlüsselungen bis:" (das "bis" sollte "bin" heißen, ich kann den Beitrag aber nicht mehr verändern, da man das nur in den ersten Minuten nach dem Posten kann) und ab dann rede ich über Verschlüsselungen.

[bstea]

Im ersten vergleichst du die Sicherheit von SHA1 ggü Schlüsselraum, Fehler 1.
Zweiter Absatz ist völliger Bockmist, Sicherheit hängt nicht alleinig vom Schlüsselraum ab. 2^256 kann ebenso sicher sein wie 2^128. Das habe ich hier schon mehrfach geschrieben. Schlimm genug das deine Rechnungen stets davon ausgehen, dass der Alg. entweder unbekannt ist oder Brute Force zwingend benötigt also keine krypt. Schwächen hat.
Drittens Absatz ist eine Kombination beider Sachverhalte, wobei ich deine Rechnung nicht nachvollziehen kann.

--
http://www.heise.de/open/meldung/Linux-auf-dem-Desktop-Europa-fuehrt-1243708.html
http://www.heise.de/newsticker/meldung/Immer-mehr-Linux-auf-dem-Desktop-1404775.html



1 mal bearbeitet, zuletzt am 03.10.12 21:45 durch bstea.

[Vermillion]

@bstea
Ich glaube ich verstehe die Rechnung. Das ganze macht dann aber nicht mehr Sinn x)

@destruct()
Es ist nicht sclhimm, wenn man nicht alles weiss ;) Meistens kann man sich mit ein bisschen lesen abhelfen.

Ich denke dir fehlt es an den Grundlagen. Das könnte dir weiterhelfen:
http://de.wikipedia.org/wiki/Kryptologische_Hashfunktion

[__destruct()]

bstea schrieb:
--------------------------------------------------------------------------------
> Im ersten vergleichst du die Sicherheit von SHA1 ggü Schlüsselraum, Fehler
> 1.

Es handelt sich dabei nur um einen Vergleich, damit klar ist, dass 2^63 nicht sicher ist.


bstea schrieb:
--------------------------------------------------------------------------------
> Zweiter Absatz ist völliger Bockmist, Sicherheit hängt nicht alleinig vom
> Schlüsselraum ab. 2^256 kann ebenso sicher sein wie 2^128. Das habe ich
> hier schon mehrfach geschrieben.

Das sehe ich genauso und habe es von Anfang an auch so geschrieben. Nach dem bisher besten bekannten Angriff ist SHA-1 auf 2^63 Möglichkeiten runter, weswegen ich auch damit rechne und nicht mit der Bitanzahl. Sonst würde ich mit 2^160 rechnen.


bstea schrieb:
--------------------------------------------------------------------------------
> Schlimm genug das deine Rechnungen stets
> davon ausgehen, dass der Alg. entweder unbekannt ist oder Brute Force
> zwingend benötigt also keine krypt. Schwächen hat.

Das tue ich nicht, siehe Absatz darüber.


bstea schrieb:
--------------------------------------------------------------------------------
> Drittens Absatz ist eine Kombination beider Sachverhalte, wobei ich deine
> Rechnung nicht nachvollziehen kann.

Vielleicht kannst du das ja jetzt.

[bstea]

__destruct() schrieb:
--------------------------------------------------------------------------------
> bstea schrieb:
> ---------------------------------------------------------------------------
> -----
> > Im ersten vergleichst du die Sicherheit von SHA1 ggü Schlüsselraum,
> Fehler
> > 1.
>
> Es handelt sich dabei nur um einen Vergleich, damit klar ist, dass 2^63
> nicht sicher ist.
>
Deine 2^63 zielen auf ein Problem bei collision resistance, das ist für Passwörter völlig uninteressant, deshalb ist der Vergleich ziemlich Banane. Ich teste auch nicht einen Traktor mit einen Mercedes um zu den Schluss zu kommen, der Verbrauch unterscheidet sich zu sehr.

>
> bstea schrieb:
> ---------------------------------------------------------------------------
> -----
> > Zweiter Absatz ist völliger Bockmist, Sicherheit hängt nicht alleinig
> vom
> > Schlüsselraum ab. 2^256 kann ebenso sicher sein wie 2^128. Das habe ich
> > hier schon mehrfach geschrieben.
>
> Das sehe ich genauso und habe es von Anfang an auch so geschrieben. Nach
> dem bisher besten bekannten Angriff ist SHA-1 auf 2^63 Möglichkeiten
> runter, weswegen ich auch damit rechne und nicht mit der Bitanzahl. Sonst
> würde ich mit 2^160 rechnen.
>
> bstea schrieb:
> ---------------------------------------------------------------------------
> -----
> > Schlimm genug das deine Rechnungen stets
> > davon ausgehen, dass der Alg. entweder unbekannt ist oder Brute Force
> > zwingend benötigt also keine krypt. Schwächen hat.
>
> Das tue ich nicht, siehe Absatz darüber.
>
siehe oben, 2^63
>
> bstea schrieb:
> ---------------------------------------------------------------------------
> -----
> > Drittens Absatz ist eine Kombination beider Sachverhalte, wobei ich
> deine
> > Rechnung nicht nachvollziehen kann.
>
> Vielleicht kannst du das ja jetzt.

Ich kann mir's denken, auch wenn 10er Potenzen zum nachrechnen einfacher sind.
Nun noch abschließend, preimage als auch second preimage sind immer sicher nach heutigen Stand. Wenn du nicht einer dieser Leute bist, die blind alles digital unterschreiben, kannst du auch mit SHA1 ruhig schlafen.

--
http://www.heise.de/open/meldung/Linux-auf-dem-Desktop-Europa-fuehrt-1243708.html
http://www.heise.de/newsticker/meldung/Immer-mehr-Linux-auf-dem-Desktop-1404775.html

[__destruct()]

bstea schrieb:
--------------------------------------------------------------------------------
> Deine 2^63 zielen auf ein Problem bei collision resistance, das ist für
> Passwörter völlig uninteressant, deshalb ist der Vergleich ziemlich Banane.

Das war nur als Vergleich gedacht.

Aber ich bin dennoch (obwohl ich das nicht so geschrieben habe, wie auch schon erklärt!) davon ausgegangen, dass das auch für Passwörter interessant sei. Basiert die Reduzierung auf 2^63 Möglichkeiten (ich mag die 2 als Basis bei so etwas lieber, da man dann ganz klar die Bit-Anzahl sieht, weswegen es auch oft so angegeben wird, aber für dich sind das 9,223372037×10¹⁸ Möglichkeiten, wenn du die 10 als Basis bevorzugst) etwa nicht mehr darauf, dass sich manche Teile des Eingabestrings unter bestimmten Umständen als irrelevant herausgestellt haben?