[jsword-devel] Locked Modules

[Martin Gruner]

Hi,

this is true, but the user will have to unlock the module whenever they update 
the module if the key is only stored in the .conf file... That should be 
reason enough to store it in a separate location.

Martin

Am Freitag, 21. Juli 2006 16:26 schrieb Joe Walker:
> I would guess that in most cases the process of getting the unlock key
> would include either an email or some "keep this safe" instruction.
> Suppose someone pays for a module, and then deletes it (I guess by
> mistake), and then wants it back again. Are they likely to find it stashed
> away in the properties file?
> Maybe we should simply add a note of our own during module delete "Keep
> this key safe".
>
> Joe.
>
> On 7/21/06, DM Smith <dmsmith555 at yahoo.com> wrote:
> > 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.)
> > _______________________________________________
> > jsword-devel mailing list
> > jsword-devel at crosswire.org
> > http://www.crosswire.org/mailman/listinfo/jsword-devel