my $key = crypt("irgendeinwort", 134345);

for(AAAA..ZZZZ)
{
my $key2 = crypt("irgendeinwort", "$_");
print $key2."\n";
}

einfach mal laufen lassen:
die kommandozeile gibt nicht bei jeder iteration einen neuen schlüssel aus..warum nicht???

mfg steinwolf

weil crypt vom ersten Parameter nur die ersten 8 und vom zweiten nur die ersten 2 Zeichen auswertet.

weil es so sein soll. Das "Salt" ist als zwei Zeichen definiert. Crypt muß mit dem gleichen Salt und dem gleichen Klartext immer den gleichen verschlüsselten Text liefern. Sonst funktionieren davon abhängige Programme nicht mehr richtig ;)

und das soll sicher sein????

perldoc -f crypt:
Traditionally the result is a string of 13 bytes:
two first bytes of the salt, followed by 11 bytes
from the set "[./0-9A-Za-z]", and only the first
eight bytes of the encrypted string mattered, but
alternative hashing schemes (like MD5), higher
level security schemes (like C2), and implementa-
tions on non-UNIX platforms may produce different
strings.

When choosing a new salt create a random two char-
acter string whose characters come from the set
"[./0-9A-Za-z]" (like "join '', ('.', '/', 0..9,
'A'..'Z', 'a'..'z' )[rand 64, rand 64]").\n\n

<!--EDIT|pq|1063730799-->

[quote=steinwolf,16.09.2003, 18:30]for(AAAA..ZZZZ)
{
[...][/quote]
Bareword "AAAA" not allowed while "strict subs" in use at -e line 4.
Bareword "ZZZZ" not allowed while "strict subs" in use at -e line 4.

[quote=steinwolf,16.09.2003, 18:42]und das soll sicher sein????[/quote]
heute ist es nciht mehr wirklcih sicher, da ein Haushalts-PC crypt in einigen Tagen knacken kann. Als Crypt eingeführt wurde, hätte die kummulierte Rechenkapazität dr Welt nciht ausgereicht.

ishka: ein haushaltspc kann ein passwort in ein paar tagen knacken?
ok, wenn du von einem dict-passwort redest... aber bei a-zA-Z0-9 und ein paar sonderzeichen sind das locker mal 70 zeichen ... wären das nicht 8^70 möglichkeiten, die er da ausprobieren müsste? also rund 1,6455045573212060421549691825574e+63 passwörter? bei tausend passwörtern pro sekunde (was wahrscheinlich recht hoch ist...) blieben da, wenn ich mich nicht irre, immer noch 1,9045191635662106969386217390706e+55 tage.
ist der computer natürlich schneller als 1000 passwörter pro sekunde, sagen wir mal, 1000000 passwörter pro sekunde, dann bleiben nur noch 1,9045191635662106969386217390706e+52 abzuwarten.
ja, doch, ich sehe, dass crypt da nicht besonders sicher ist...

a-zA-Z0-9 ohne sonderzeichen und kürzer als 7 Zeichen decken wohl (leider) so ca. 80% aller pw ab. Und da crypt relativ schnell ist, gehen da etwa zwei millionen pws pro Sekunde. (meiner schafft etwa 1,7 Mio).

das macht dann 62**6/1700000=33412 Sekunden

naja, das meine ich. wenn man crypt mit unsicheren passwörtern füttert, kann es daraus keine sicheren machen. nimmt man einfach ein wort aus dem wörterbuch, lässt es sich noch schneller finden. nimmt man einfach den usernamen als passwort, braucht man nichtmal einen check dagegen laufen lassen, da reicht ein ausprobieren.
das ist aber kein fehler in crypt, sondern ein systemischer fehler. egal, wie kompliziert du eine verschlüsselung machst, bei einem unsicheren passwort nützt das nichts.
und wenn jemand crypt richtig nutzt und ein 8zeichen-passwort nutzt, dann ist da kein problem. das problem ist also nicht crypt anzulasten, sondern dem anwender - und davor würde ihn auch kein anderer algo schützen...