[metadat]

Given the length of Windows serial keys is not that long, why couldn't one extract the check function and run an iteration attack to generate valid keys?

Edit: @ale42: makes sense, thanks for putting this one to rest. 36^25 is approximately 8 x 10^38 which is a really, really big number.

[ale42]

There are 25 characters, each of which has 36 possible values. So 36^25 possibilities, and log2(36^25) = 129.2. There are basically 129 bits of entropy in there, so good luck bruteforcing it.

This makes me think of a shareware app (I think an icon editor) for Windows 3.1 back in 1994 or so... I could find a valid registration key by entering random numbers by hand in around 2 minutes. And I wasn't lucky as I tried and succeeded several times ;-) But the rule (figured out after I had 10 or so valid keys) was simple maths with the digits, no crypto behind.

[ilyt]

> There are 25 characters, each of which has 36 possible values. So 36^25 possibilities, and log2(36^25) = 129.2. There are basically 129 bits of entropy in there, so good luck bruteforcing it.

Kinda depends what is encrypted there. If it is just "magic number + SKU + licence ID" and there is no online check whether that combination is valid then you're "just" trying to hit one that's valid and that cuts few bits off equation as there is spectrum of keys that will be valid but not generated by Microsoft.

[aaronax]

Not used characters: 015AEILNOSUZ

So less possible combinations.

[scambier]

I get why some chars aren't used, but why the N and U?

[deznu]

Maybe to prevent certain words from being spelt? I have no idea though

[ale42]

Still 114 bits of entropy...

[AlotOfReading]

Not if their cryptography is done properly. Cryptosystems are designed to maintain their security even if the complete algorithm is known to the adversary. You'll commonly see this phrased as "don't rely on security through obscurity".

[staunton]

> don't rely on security through obscurity

Which doesn't mean you shouldn't also use obscurity. NIST recommends it [1], and the industry widely uses it. In practice "don't rely on obscurity" usually means "have enough security besides obscurity to give you a grace period to switch out the obscurity". That's for whole systems, you might get away with people knowing you use standardized primitives like AES.

[1]: https://csrc.nist.gov/news/2021/revised-guidance-for-develop...

[AlotOfReading]

Everything we know about the subject of this discussion (windows product key validation) comes from reverse engineering the relevant DLLs because none of it has been discussed publicly. I think MS is probably of a similar opinion regarding publishing unnecessary details.

[ranger_danger]

> don't rely on security through obscurity

if it's not obscure enough that it will be found, then you are correct.

but what's more secure than a password that you don't know? not knowing there is a password in the first place. if the answer is never found, how can it be insecure? I dub this schrodinger's security.