Talk:LM hash

From Wikipedia, the free encyclopedia

	This article is within the scope of Computing WikiProject, an attempt to build a comprehensive and detailed guide to computers and computing. If you would like to participate, you can edit the article attached to this page, or visit the project page, where you can join the project and/or contribute to the discussion.
???	This article has not yet received a rating on the quality scale.
???	This article has not yet received an rating on the importance scale.

Contents 1 Relevant historical question 2 Disabling LM hashes 3 fact check request (moved from main article) 4 Weird notes

[edit] Relevant historical question

Does anyone know where the KGS in "KGS!@#$%" comes from? For some reason I'm thinking it's related to the designers initials or something, but I can't really remember. This could be a point of interest for the main page if we can find the answer.

--Tom

[edit] Disabling LM hashes

Shouldn't this page have a note saying how to disable the use of LM hashes? --Wayne

(At least) an external link would be worthwhile; does Microsoft describe how to do this in any of their support pages? — Matt 18:49, 2 Nov 2004 (UTC)

Added. --Hawke666 22:45, 2 Nov 2004 (UTC)

[edit] fact check request (moved from main article)

The number of combinations seems incorrect. Usually the formula is (number of valid characters)^(length of password), or for a 7-character password using upper-case letter and numbers only, 36^7. 2^36 is far too small, unless there's a bug in LM Hash that I don't understand.

24.81.71.14

I get log2(36⁷) = 36.189475... (so 2³⁶ is about right.) I'm not sure about 2⁸⁴ for mixed case and numbers, though. I get (26 + 26 + 10)⁷ = 2^41.68. — Matt 19:21, 2 Nov 2004 (UTC)

For the record, . That’s not quite exact, but close enough. —xyzzy_n 14:40, 14 June 2006 (UTC)

[edit] Weird notes

I’ve moved the following from the article:

The effects of splitting the password into two and having two independent (note the emphasis) hashes on each half is that it enables a cryptanalyst to consider only one half at a time. In the context of a typical brute-force approach, this means the effective halving of the search schemata, which will yield a reduction in the search space by a factor of 2^18. This is because together, the two halves correspond to 2^36 discrete password combinations.

Given the ability to consider one half at the time amounts to 2 * 2^18 = 2^19 effort, as opposed to a full 2^36 effort, had the halves been made dependent. The effect is not different to a mergesort, which recursively splits the search space into halves which are each significantly simplier, and merges these together in a O(NlogN) effort.

I don’t think it’s correct; 2³⁶ is already the size of the search space for one seven-character hash, which yields a size of 2³⁵ per hash when looking for two hashes. Anyway, 2³⁶ is the relevant number. —xyzzy_n 14:40, 14 June 2006 (UTC)

Explanation: When we have a concatenation 2, 7-bit fields, such that the 2 fiels are related and, thus, inseparable, we have an equivalent of a 14-bit field. When you halve the number of combinations, yes, you subtract one from the index (power). But in this case are taking the square root of the entire search space, because we've managed to split the field in half.

Regarding 2^36. I made a mistake thinking that 2^36 is the entire search space. Actually, since we assume that a 7 bit field can take only 36 values (lower case plus digits), a 7 character password is 36^7. This is approximately 2^36.2 (found logarithmically). So for 2 halves, it is 2^37.2 ~ 2^37. I'm not sure where you got 2^35 from :) [Emil Koutanov]

When using brute force, it’s only necessary to do the search space once (in the worst case). This means checking 2³⁶ combinations (the exact number doesn’t really matter there—it’s an estimate anyway). Since this gives solutions for both hashes (because the hash function is the same in both cases and checking for two matches instead of just one match for each combination is negligible for the time complexity), the number of combinations per one hash is the total number of combinations divided by the number of solutions we got, i. e. 2³⁵. The total number of combinations checked remains 2³⁶, of course. 2³⁷ should not happen unless you actually run the entire brute force algorithm separately for each hash, which is an unnecessary (and costly) complication. Anyway, I think the article already covers the arithmetical aspect adequately.

By the way, please sign your posts using the Wikipedia method, by appending ~~~~ to your posts on talk pages (but never to your contributions in articles; those are automatically attributed in the article history). This automatically inserts an identifier and a timestamp. If you want to have a custom signature, why not create an account? —xyzzy_n 22:17, 22 June 2006 (UTC)

In many of the discussions above, you guys assume that only alphanumeric characters are used. Actually, passwords hashed using LM hashes do use symbols and space in addition to letters and numbers. Assuming that only the 95 printable ASCII characters are used, minus the 26 lowercase letters, that would make 69 charaters in the character set to consider. --Spoon! 10:47, 31 August 2006 (UTC)

Most people don't use special characters, but a fully random LM password selected from a 69 character alphabet would require searching a space of 2^43 possibilities. Because salt is not used, time-memory tradeoffs can be used to make searches very fast.--agr 21:39, 31 August 2006 (UTC)