Not an issue-sorta...

[Pat Trainor]

Bitlocker recovery keys are not random strings. Each of the first 7 groups of 6 characters must be divisible by 11, making the field of possible solutions far smaller than random. In addition, the last group of 6 is a computed checksum of the others-again, not random.

Does your tool narrow the solution field, and thus solution time, by taking this into account?

If you check here: https://wikileaks.org/hbgary-emails//fileid/45244/13483 (a PDF) you will see that M$ documentation is in error.

Implementing BitLocker Drive Encryption for Forensic Analysis
Jesse D. Kornblum, ManTech International Corporation
[e-mail]

excerpt:

#5.4 Recovery Password
When BitLocker is installed on a system volume the system encourages the user to create a recovery password. The user can also create a recovery password from the BitLocker Control Panel at any time. The recovery password can either be written directly to a text file or displayed on the screen. The “password” is actually a 48 digit number, eight groups of six digits, with three properties for checksumming described in [6, 7]. These properties are:

1. Each group of six digits must be divisible by eleven. This check can be used to identify groups mistyped by the user.

2. Each group of six digits must be less than 720,896, or 216 ∗ 11. Each group contains 16 bits of key information. The eight groups, therefore, hold 16 ∗ 8 or 128 bits of key.

3. The sixth digit in each group is a checksum digit. If the digits in each group are represented as x1, x2, x3, x4, x5, and x6, then x6 must equal (x1−x2+x3−x4+x5) mod 11. Note that the Microsoft documentation for the check digit calculation is incorrect. In [7] Microsoft claimed that x6 must equal (−x1 +x2 −x3 +x4 −x5) mod 11.

The error may be attributable to the fact that many programming languages do not compute the modulus operator correctly. In C, for example, -5 % 11 yields -5, and not the correct result, 6. A method to compute the check digit correctly in C is: check digit = (11 - (-x1 + x2 - x3 + x4 - x5)) % 11;.

The author believes that whomever wrote the documentation for Microsoft may have relied on the source code. If that source code resembles the version of the checksum above, it would account for the discrepancy in [7].

Wouldn't only supplying the possible characters lower the solution time? Or is the overhead of making each entry valid more than just hitting it with random characters?

[drdunn858]

This is not an answer, but rather an additional question for the asker. Can you give me an example of a 6 digit number divisible by 11 in which the 6th digit is NOT the checksum as per the documentation? I am at a loss as to any number which meets 1 and 2 without automatically meeting 3?