A Simple Open DRM

We love to hate DRM, because we associate it with degraded quality or loss of data control. Sometimes we associate it with loss of privacy when we register. 

Here is a formative "Open DRM."

The kernel of the system is going to be the idea that a salted hash is a member of a class of some kind. If I start with a MEMBER md5 hash and run 200,000 iterations of the correct salt, I hit a control value predictably. 

The potential problem arises not from providing 199,999 different possible keys, but from providing a registered customer with his own valid replacement, on that rare occasion when he proves he has purchased it, and we must re-present his original key.

Standing behind the warranty is what makes us reputable.

To preserve his privacy AND the security of our system, we do not want to store the enumerated value on the server. 

However, we can reasonably suppose that we can manage to keep a secret value secure.

I propose that the DBM or LLC choose a passphrase of some kind, and hash it a proprietary number of times WITH AN APPROPRIATE SALT to generate a secret value. This value will now become the basis for the member class.

Valid keys will be the first 30th to the 200,030th values derived from hashing the secret value with a particular salt. The company would keep a record of the date, the salt and the 30th value.

The salts change monthly, with additions when there are more than 200,000 sales in a particular month. 

Here, write once, compile many is part of my plan. However, I am not suggesting recompiling for every customer. I am suggesting recompiling every month/200,000 sales. 

For my DRM, I am going to select salts composed of object code looking bytes, to obfuscate decompiling. This devolves from suggesting syntactically valid reserved words, but these would remain ascii or unicode in compiled data, whereas the idea is to render them difficult to retrieve. 

Distribution would be accomplished by hashing the starting key by the integer of the customer number, using the salt of the month. 

At the start of each month, the administrator would hash the secret value 200,030 times with the salt of the month, and hard code the result in the source code. Then he would compile it.

Evaluation would be accomplished by hashing the customer key 200,000 times, checking if it matches at each iteration. A successful match authorizes execution. Failing to arrive at the final value proves the key is invalid. This is the same principle as a rainbow table.

At the time of this writing, I acknowledge that 200,000 iterations of a hash is a time-killing obstacle for customers who want their game to load instantly. I speculate that storing an intermediate value in the range of 30 might resolve it, but as it stands I have not resolved how 30 hashes is enough to arrive at the final value without ultimately reducing "key space," to 30.

This represents an Open DRM.

Comments

Popular posts from this blog

A Question About Erasthmus' Sieve

Notice of corrupted results: Vigenere may yet be found to be a "group."

A Simple Rule for the Stock Market