[geekmaster]

We typically used PBKDF2 key generation when I worked on this stuff. It converts a text key (passphrase, or serial number in this case) into a larger 128-bit key. It is designed to run slowly to prevent exhaustive brute-forcing.

If you plan to search the raw keyspace without doing slow key generation, you have to search a much larger keyspace (128-bits) which would take a LONG time.

Slow key generation is WHY encryption (done well) is still secure. Even for rainbow tables, it took a LOT of CPU time to generate those tables. You can crack the raw keyspace quickly by using rainbow tables to lookup the key precursors for a quick and small raw keyspace subset search.

I am no encryption expert -- but that is how I understand it. It has been awhile, so I may not remember it all correctly...

P.S. You are talking about SLOWLY GENERATING 10 alphunumeric character keys, or quickly searching a HUGE 128-bit raw keyspace. Either way takes a lot of time...

EDIT: Again, I do not know how the kindle DRM does it. I suspect that generating keys for all possible kindle serial numbers would be very slow. Using a fast hash for key generation would be vulnerable to brute-forcing the much smaller serial-number space instead of the full 12-bit encryption keyspace, so it would be foolish to use a fast hash for DRM key generation. After you have the right key, decryption is fast. But FINDING the right key is slow, which is why you need to know the serial number of the kindle that owns the DRMed media, or otherwise extract its key from it.