[jsword-devel] Locked Modules

[DM Smith]

Please provide feedback:

Within the last few months and over the course of the near future we are 
seeing locked modules coming available (NET, NASB, ...). In each of the 
cases the publisher will be selling the unlock key. In some cases the 
publisher will be hosting the module on their website.

In BibleDesktop, when a module is locked it is shown with a small lock 
overlay icon in the Book Installer. When the user selects a locked 
module, the "Install" button is greyed out. This leaves the user with 
manually downloading the module, unzipping it in the correct location, 
finding the module's conf and editing it, entering the unlock key.

I would like to change this so that at a minimum, the user can download 
and install the module. Further, ideally the application should allow 
the user to enter the unlock key at download time and also later. The 
key would then be checked for validity*. I'm kinda working against a 
deadline of the next SWORD CD being created. It would be nice to get 
this done before the CD is mastered. So at a minimum, instructions 
should be given to the user to manually insert the unlock key.

The unlock key represents an asset that the user owns. I am wondering 
where and how we should store the unlock key. In order to maximize 
sharing with other SWORD applications it needs to be in the module's 
conf. I'm wondering if it should be double stored in a file that is not 
deleted when the module is deleted? (A simple properties file should 
suffice.)

*WRT a unlock key validity check there has been much discussion on 
sword-devel on how this should be done.

The best solution was to change the locking process to encode a random 
sequence of bytes in two known locations in the module before 
enciphering. Then a check would to have been to decipher the module and 
compare the random sequence at the beginning and the end. If they 
matched the key was valid. This solution is not be used because it was 
deemed as being too intrusive. (There are locked module already created 
that would have to be relocked.)

So this leaves us with guessing. Turns out that we can guess fairly 
well. There are certain characters that should not be in a module, 
namely most 7-bit ASCII unprintable, control characters. If any of these 
control characters are found any deciphered chunk of text, then the 
unlock key is bad.  The accuracy of the test increases with the length 
of the text being deciphered. (The fundamental nature of the cipher 
algorithm is that of a random byte generator, seeded with the unlock key 
and all input prior to the current byte.)