Entwickler-Ecke :: Thema anzeigen - Bitlänge bei Passwort berechnen

Tristan - So 04.12.05 15:37
Titel: Bitlänge bei Passwort berechnen

Hallo,

Das Verfahren BlowFish ermöglicht ja eine maximale Schlüssellänge von 448Bit. Wenn ich jetzt z.B. das Passwort "Test" verwende, wieviel Bit sind das dann und wieviele Möglichkeiten müsste man durchprobieren um dieses Passwort zu knacken?

Ist das nicht von den verwendeten Zeichen abhängig - also z.B. a-z, A-Z, 0-9?

und gibt es eine Seite, wo man ausrechnen könnte, wie lange man mit einem leistungsstarken Rechner dafür braucht?

Wäre echt interessant ;-)
Tristan

Alstar - So 04.12.05 15:46

Anzahl der Bits eines Strings:

Delphi-Quelltext

1:	intBitCount := Length(strString) * 8;

Alstar

Chryzler - So 04.12.05 16:39

Wenn du in deinem Passwort wenigstens einen Großbuchstaben, einen Kleinbuchstaben, eine Zahl und ein Sonderzeichen verwendest, kannst du Alstar's Formel verwenden.

Eine Seite wo die schnellsten Rechner der Welt aufgeführt sind: http://www.orange.co.jp/~masaki/rc5/rfratee.html
Ich weiß nur nicht ob die Liste aktuell ist.

Kombinationen = Zeichenanzahl ^ Passwortlänge

k-weddige - Di 06.12.05 21:44

:?: Warum sollte man Alstars Methode nur bei wenigstens einem Großbuchstaben, einem Kleinbuchstaben, einer Zahl und eim Sonderzeichen verwenden können?

Die Menge der Möglichkeiten hat nichts mit dem Passwort zu tun.

Selbst, wenn das Passwort "aaaaaaaaa" ist, gibt es bei den erlaubten Zeichen [a..z][A..Z][0..9] immernoch 36^9 Möglichkeiten.

k-w

Benutzername - Di 06.12.05 22:12

k-weddige hat folgendes geschrieben:

Selbst, wenn das Passwort "aaaaaaaaa" ist, gibt es bei den erlaubten Zeichen [a..z][A..Z][0..9] immernoch 36^9 Möglichkeiten.

Hmm, ich komm da aber auf 62^9 Möglichkeiten.

a..z = 26
A..Z = 26
0..9 = 10
------------
ergibt 62

;)

Es sei denn du arbeitest nicht case-sensitive (wäre aber blöd, denn dann hast du pro Schlüsselbyte 26 Möglichkeiten weniger.
62^9 = 13537086546263552
36^9 = 101559956668416

Macht 13435526589595136 Möglichkeiten weniger, du hast also nur etwa 1/133 der Möglichkeiten, die du hast, wenn du mit Case-Sensitivity arbeitest ;)

Sirke - Mi 07.12.05 22:43

Warum unterhaltet irh euch, wenn ihr über Verschlüsselung redet nur über die ASCII-Zeichen die einen Text darstellen. Also a-z, A-Z 0-9 und nicht über alle möglichen Kombinationen für ein Byte ? Das sind 265 und damit wesetlich mehr als eure 36 oder 62 und damit auch um einiges sicherer!

root_at_localhost - Do 08.12.05 00:00

Sirke hat folgendes geschrieben:

Du kannst doch die Passwörter in Hex eingeben.

echt? Also wie mach ich das z.B. bei meinem Windows? Oder im Bios? Noch wichtier: Mail! Ich geh auf gmx.de, melde mich an, geh auf Passwort ändern und gebe in das Formular einen Hex-Wert ein? Ich versteh nicht worauf du hinaus willst, mein Passwort tippe ich üblicherweise in eine Edit-Feld und da gehen halt nur alphanummerische Zeichen und ein paar Sonderzeichen.

Sirke - Do 08.12.05 11:57

Du hast doch oben von einem Verschlüsselungsalgo gesprochen und nicht von GMX oder dem BIOS Passwort. Dort kannst du natürlich nur Buchstaben und Zahlen verwenden.

Für "richtige" Verschlüsselungsalgos würde ich immer eine Hex Eingabe wählen, weil du damit wesentlich mehr Möglichkeiten abdecken kannst.

Benutzername - Do 08.12.05 15:11

Hm, bei ner Hexadezimalen-Eingabe hast du 0..9 + A..F, also 16 Möglichkeiten pro Schlüsselelement
Nutzt du a..z + A..Z + 0..9 hast du wieder 62 Möglichkeiten für ein Element im Schlüssel, also mehr.

Außerdem ist doch ein hexazezimaler Schlüssel nicht sicherer als ein bspw. Dezimaler. Es ist doch eh nur ne andere Darstellungsweise, dahiterstecken tut bei beiden das gleiche.

Sirke - Do 08.12.05 17:19

Wenn du sorum denkst, ist das richtig, aber wenn du zB DES verwendest und dabei eine Schlüssellänge von 256 Bit. Dann kannst du 32 Zeichen verwenden.
Wenn du jetzt deine 26 Buschsteben und 10 Zahlen verwendest, dann hast du 36 der 256 Möglichkeiten für ein Byte benutz und damit lediglich ~14% und nicht alle 256 Möglichkeiten die du mit 2 Hex-Zeichen ausschöpfen könntest. Der Schlüssel wird damit zwar länger aber auch wesentlich sicherer!

Alstar - Do 08.12.05 17:55

Ich glaube du werwechselst Anzahl der Zeichen, Anzahl von Byte und Kombinationsmöglichkeiten.

1 Byte (also 1 Zeichen) lässt sich mit 1 Hex-Wert (also 2 Zeichen) darstellen. Wie du aber mehrere Bytes kombinierst ist die andere Sache.

Alstar

root_at_localhost - Do 08.12.05 17:57

Als Passwort kommen halt definitiv nicht alle Zeichen in Frage. Daher zählt man bei einem Passwort auch Länge und in Frage kommende Zeichen. Bei einem Schlüssel wie z.B. einem PGP-Key oder sowas is das klar was anderes, aber den muss ich irgendwo speichern, das Passwort kann ich mir merken. Es sind einfach verschiedene Anwendungsgebiete denk ich.

Sirke - Do 08.12.05 18:36

Tristan hat folgendes geschrieben:

Das Verfahren BlowFish ermöglicht ja eine maximale Schlüssellänge von 448Bit. Wenn ich jetzt z.B. das Passwort "Test" verwende, wieviel Bit sind das dann und wieviele Möglichkeiten müsste man durchprobieren um dieses Passwort zu knacken?

Da hast du doch nach einem Verschlüsselungsalgo gefragt und darauf habe ich geantwortet! Und da hast du nun mla mit einer Hex-Eingabe mehr Möglichkeiten als mit Buschstaben die du mittels ord() in ein Byte umwandelst!

Alstar hat folgendes geschrieben:

Ich glaube du werwechselst Anzahl der Zeichen, Anzahl von Byte und Kombinationsmöglichkeiten.

Das glaube ich nicht, denn ich habe geschrieben, dass man ein Byte einmal mittels Hex darstellen kann, dann hat man 256 Möglchkeiten für ein Byte, und dass man das mittels eines Buschstaben und ord() darstellen kann, dann hab man weniger Möglichkeiten.

root_at_localhost hat folgendes geschrieben:

Es sind einfach verschiedene Anwendungsgebiete denk ich.

Das stimmt, aber du hast am anfang auch nach einem verschlüsselungsalgo gefragt(s.o.) oder nicht ?

Entwickler-Ecke.de based on phpBB
Copyright 2002 - 2011 by Tino Teuber, Copyright 2011 - 2025 by Christian Stelzmann Alle Rechte vorbehalten.
Alle Beiträge stammen von dritten Personen und dürfen geltendes Recht nicht verletzen.
Entwickler-Ecke und die zugehörigen Webseiten distanzieren sich ausdrücklich von Fremdinhalten jeglicher Art!