Това не е възможно и обяснението е просто.
Да предположим, че имаш "криптиран низ". Колко голяма ще ти стане въпросната таблица примерно за всички пароли от 10 символа съставени от малки/големи букви и цифри? Ще ти издам тайната за ZIP и RAR - и двете хващат паролата и я трансформират в 128-битов (обикновено) ключ за AES декриптиране на компресирания файл. Това става чрез някаква форма на key stretching, чиято цел е да е изчислително-сложна операция, за да отблъсква bruteforce атаките. Най-често това е итеративно викане на някаква хеш функция, примерно няколко хиляди пъти.
Сега да предположим, че искаш да пазиш такава таблица с всички пароли с дължина 10 символа, малки и големи букви (горния пример). Таблицата ще излезе няколко хиляди петабайта, това са милиони харддискове. Като изключим това, дори да ги имаше (и да можеше да си позволиш да им плащаш тока), времето за което ще ги изчетеш, за да сравниш паролата, твърде вероятно е по-голямо от времето, за което дори един от тях ще откаже, което ще ти съсипе акуратността на сметките. Обаче нещата всъщност са по-лоши от това, защото RAR ползва 32-битова псевдо-случайна salt стойност, която е различна за всеки архив. Това означава, че ще ти трябват 4 милиарда по толкова диска, за да покриеш всички salt стойности.
Обаче криптиран низ няма. С горепосоченият ключ, генериран от паролата ти, декриптираш компресираният файл и после го декомпресираш. Ако ключът е грешен, има известна вероятност да го декриптираш до безсмислици, които ще дадат грешка при декомпресията, но ако файлът е достатъчно малък е възможно и да не даде грешка. Затова има една крайна CRC32 стойност, която се смята от декомпресирания файл и се сравнява, така че шансът грешна парола да декомпресира файла до безсмислици без да даде грешка е в най-лошият случай 1 на 4 милиарда.
Тъй като обаче можеш да имаш компресиран един мнооооого голям файл, с цел при проверката за грешна парола да не отнеме декриптирането и декомпресирането на големия файл, авторите на формата са въвели и една стойност, наречена verifier, която е CRC16 сума от ключа или нещо от сорта. При това положение, само в 1/65535 от случаите, грешната парола ще доведе до декриптиране с грешен ключ, декомпресиране и в краен случай сравнение на крайната CRC32 сума.
Като последствие от това (и поради начина по който са написани почти всички архиватори) е много лесно да генерираш грешна парола, която минава проверката с verifier-а и програмата ти връща обикновено грешка че архивът е corrupt-нат, а той си е напълно здрав. Не че последното има някаква практическа употреба, но е забавно
Както и да е, къде в цялата схема виждаш "криптиран стринг", който да пазиш в таблица? Можеш да пазиш 16-битовия verifier примерно, но това по никакъв начин не е индикативно, че паролата е същата, освен че ти дава по-голяма вероятност за това. Освен което, въпреки че така се намалява големината на таблицата няколко пъти, това не я прави много по-практична - където са няколко хиляди петабайта, почти толкова недостижими са няколкостотин петабайта. Също така не съм много сигурен, че в RAR е реализирано по този начин, в ZIP е реализирано така и това дава известни предимства. Може да са са изхитрили и да са го направили зависимо от съдържанието, примерно вместо CRC16 от ключа, да вземат CRC16 от първите няколко блока, декриптирани с този ключ - последното обезсмисля цялото упражнение.