N    чит оригн время(сек) 001   2    3    0.574 002   2    4    0.952 003   2    2    3.744 004   2    3    1.416 005   2    4    1.769 006   3    3    0.731 007   5    5    0.551 008   5    4    1.804 009   5    4    0.698 010   2    2    3.408 011   4    5    0.584 012   2    3    1.411 013   4    3    1.736 014   3    3    1.221

Тонкости не стал приводить, так как их по большому счёту было только две:
1) Досрочный выход из циклов, когда все пароли найдены
2) Вычисление хэша для каждого из слова только один раз, а не для каждого из паролей.
Можно к тонкостям отнести использование функции file() вместо fopen()+fgets() - но это спорное утверждение, так как при расширении словаря придётся наоборот отказываться от file() в пользу fopen()+fgets() - приимущества есть и у того и у другого подхода.

Сначала хочу извениться, так как отсутствовал n-ое время, да и сейчас времини нету практически, отчет по 5 задаче подготовлю но немного позже.

На самом деле есть одни претензии )))
Вопрос к Хеопсу, как вы (можно на ты?) считаете читабельность? Если как истенный программист "объему кода" (чем меньше тем лучше), то я немного в недоумении. Разве в этом дело. Если скрипт будет на 200 строк, не значит что он не "читаемый", это вообще не о чем не говорит, пока не будет видно самого кода.
Разве
if( $hash == md5(strtolower(trim($word[$i]))))
лучше
$p = trim($word[$i]);
$p = strtolower($p);
$p = md5($p);
if ($p == $hash)
???
И если считать что "финчи" типо учета времини "уменьшают читаемость" тогда я в шоке.

Теперь непосредственно по задачам.
Рекомендации по file не очень понятны. ведь мы делаем "универсальное решение" для "задачника", а значит словари могут быть любые, а не только "на 1 мб в unix стиле", а значит лучшем решением будет fopen + fgets (fread), так как мне приходилось работать со словарями свыше 32 мб. Предлагаю впредь, подчеркивать именно универсальность, а не привязвываться к конкретному примеру.

И несколько слов по примерам что я успел посмотреть.
break это прошлый век. В любом случае можно обойтись или доп условием в for либо сделать цикл через while. Вот что действительно уменьшает читаемость.
Использование "оформления" тоже мягко говоря меня удивляет. Скажите зачем!? Это же пример, код, который будут оценивать, и если хотите чтобы в нем разобрались, уберите все лишее от туда. Ведь в первую очередь смотрят (ну хотя бы я) php код, который будут потом разбирать. Кому надо тот сам сделает оформление как ему надо, и не придется вырезать вашы html-теги.

Все.

>Теперь непосредственно по задачам.
>Рекомендации по file не очень понятны. ведь мы делаем
>"универсальное решение" для "задачника", а значит словари
>могут быть любые, а не только "на 1 мб в unix стиле", а
>значит лучшем решением будет fopen + fgets (fread), так как
>мне приходилось работать со словарями свыше 32 мб. Предлагаю
>впредь, подчеркивать именно универсальность, а не
>привязвываться к конкретному примеру.
И как долго такой подбор будет продолжатся?
Я считаю пхп не надо лезть в те области в которых он не силен.
У меня есть словари и побольше(43 мег), но я не собираюсь подключать их к такова рода скрипту.

1) Читабельность оцениваю субъективно - сколько бы мне времени потребовалось самому понять то, что делает код и приспособить для своих нужд.
2) С file принимаю, согласен.
3) С break не соглашусь - его очень хорошо видно, а лишнее условие в цикле - это как раз снижение читабельности.