))
ну ппц вы нас тут весилите не слабо...

Вы не гуманитарий, случайно?..

Так вроде на вид совсем не чайник, но иногда такие штуки выкидываете, что просто диву даешься... 
(хотя хз, может это просто разница в подходах старого хакера...  Кстати, как у вас с хаком, с дизассемблерами и тп дружите?.. )


В данном случае - это как раз САМЫЙ криптостойкий вариант - _даже если использовать для хэширования СОВСЕМ не криптостойкую функцию_!    Хоть готовую теорему объяснить сможете?..



PS  подскажу еще:  криптостойкость и _равномерность распределения_ - это совсем разные параметры!..
И если использовать не стойкую, но _равномерную_ функцию - то тут ппц ваше не взломаешь - поскольку именно этот самый XOR с со случайным ключом и обеспечит уже высокую криптостойкость!   Равномерность более равномерна у специальных хэширующих функций - они могут быть не стойкие, но равномерные - в этом случае никакие танцы с бубном никак не позволяют ускорить перебор!..
А вот в вашем случае AES даже если считать криптостойким(в чем кстати некоторые криптологи сомневаются) - то никакой гарантии что после многих циклов он будет иметь _равномерное_ распределение нет!!!  Понимаете идею?..
То есть возможно что будет найден алгоритм ускоренного перебора - будут перебирать только те диапазоны кодов, где вероятность выше, _причем миллионы циклов хэширования никто крутить не будет_ тк это просто не нужно, проще перебирать уже НА УРОВНЕ ГОТОВОГО КОДА, что _очень быстро_!!!    Сюрприз?..


PPS  да, вот насчет факториала у вас была классная идея!   Это стоит обдумать!!    Возможно даже новые особо стойкие методы удастся изобрести - не хотите поработать с математиками (потом получим патенты)?..
(с факториалом шикарно то, что таблица кодов, из которых делается комбинация - может быть вообще открытой!!!
А это как раз дает возможность использовать действительно ДЛИННЫЕ и _по-настоящему случайные_ коды!!!
Понятна идея?   То есть счас у вас проблема запоминания больших данных - а тут длины ключей могут быть на порядки больше...)