ad 1)
Jenom poupravím: slabé místo LM nespočívá v délce hesla, ale v komplexitě obecně. Pracuji s daleko menší množinou danou jednak délkou (jak píšete), jednak rozmanitostí (jen velká písmena, čísla a speciální znaky), druhak s rozdělováním na dvě části (teoreticky mi stačí uhodnout pouze polovinu hesla).
ad 2)
S tím bych si dovolil nesouhlasit. Rainbow tables u např. LM by TEORETICKY generovaly ca. 12,5 TB dat ((při zohlednění vlastností LM, tedy velká písmena, čísla a speciální znaky): 51 znaků ^ 7 řádků * 15 bajtů). Proto pracuje s délkou hashovacího řetězce (chain length), která určuje, kolikrát je heslo hashováno. Na mnoha místech keyspace (to je soubor všech možných hashů) se hash opakuje (tj. opakuje se ve více řetězcích hashů). Tyto řetězce zase ve většině softů figurují jako chain count.
Vhodným poměrem hodnot chain length a chain count lze ovlivňovat, jaký charakter spíše bude hledání mít. Čím nižší hodnota délky řetězce (a vyšší hodnota počtu řetězců), tím větší keyspace (tedy tím náročnější na úložiště/RAM operace apod.). Čím vyšší hodnota délky řetězce (a nižší hodnota počtu řetězců), tím více se hledání bude blížit charakterem brute force attacku.
Tedy, LM heslo lze velmi dobře lámat rainbow tabulkami, právě pro jeho omezení (viz bod 1). Dle testů, které jsem provedl pomocí Caina a freerainbowtables.com se na Core2duo bez podpory CUDA (Cain neumí, ale např. Elcomsoft DPR ano
) prolomit LM v řádu minut až desítek minut. U složitějších hesel je třeba a) mít čas na generování tabulky, b) mít peníze na zakoupení NTLM Rainbow Tables. Tedy, RT lze za jistých podmínek aplikovat i na silnější typy šifrování.
Otázkou je, co stojí za takovou námahu. Btw. CUDA ca. dokáže zkrátit brute force (v současné době) ca. o jeden řád. do pěti let je očekávaný nárůst CUDA 16x. 