Dokumentace zmiňuje, že parametr -salt je implicitní volba, takže není asi třeba jej explicitně uvádět, jestli to dobře chápu.
Také bych trochu rozvinul tvrzení, že solení hesel komplikuje útok hrubou silou ... pokud se nepletu, tak reálně pouze znemožňuje použití předpočítaných hodnot klíčů/hashů. Pokud by se někdo snažil hrubou silou prolomit zašifrovaný soubor, tak pravděpodobně bude napodobovat chování uživatele a zkoušet zadávání hesel, kde solení není žádnou překážkou.
Jinak děkuji za pěkný článek a co se pokračování týče, tak o vytvoření vlastní jednoduché CA tu už něco kdysi bylo, ale hlasoval bych pro téma "ručních" operací s certifikáty jako jsou třeba podpisy dokumentů/mailů a jejich ověřování
ale přeci při dekódování (= ověřování hesla, když to tak řeknu) je sůl známá, takže ji útočník může vesele použít, ne?
komplikuje to útoky, kdy přijde člověk a má několik GB spočítaných hashů a jenom vyhledává shody, aniž by je přímo počítal ... tuším, že na tomhle principu jsou založené Rainbow Tables k prolamování WinXP (ale nevím jestli je to aktuální)
Je to o řád složitější. Máš řady v Rainbow tables a vygeneruješ řadu z hashů prolamovaného systému. A když máš štěstí, tak se potkáš. Pak nastoupíš o stupeň výše v rainbow table a dogeneruješ hashe až ke kolizi. Nakonec použiješ onu kolizi. Při troše snahy pak odfiltruješ i tu sůl (ultimate win).
Rainbow table totiž zásadně neobsahuje všechny řetězy možných hashů, jen jejich část.