At 20:43 04-02-03 +0700, Adrian Korten wrote: >Good day, > >For the future when program development starts up again, I have a request from my >supervisor. I have been compiling some text module files for one of the versions of >the Thai Bible (sold and distributed by the Thailand Bible Society). They would like >to have a combined Name and Code combination that could then equate to an encryption >key. It is quite likely (possible anyways) here in Thailand that if someone gets a CD >with the Bible module and some note with the unlock code that they would then pass it >on to friends or even sell it themselves. > >Other share-ware programs that I have bought usually have require my name and some >code provided by the seller. Is this possible with the Sword data engine? I don't >think that this increase the security that much but it makes the improper usage a >little more obvious to the user.
You have mentioned two separate problems that people try to solve with encryption: 1. Point of sale control. 2. Copy prevention. Problem #1 is solvable, because one of the parties involved is presumably trustworthy (i. e. you, the seller). Really, all you do is withhold the encryption key until payment is made, instead of withholding the plain text of whatever is encrypted. This way you can unlock whole CD-ROMs full of stuff with just a little bit of key text. How well this works depends on (1) the strength of the encryption, and (2) how well you control the keys and keep them secret until the time to be revealed. Note that problem #1's solution says nothing about your customer giving away or selling either keys or decrypted products, and does nothing to prevent that. Problem #2 is not possible to totally solve without dedicated hardware. Microsoft & Intel are trying to do just that with their "trustworthy computing" initiative. In the mean time with general-purpose computers and especially with open source systems, you can't really solve this one totally. All you can do is discourage copyright violations with personalized keys and moral barriers to theft of intellectual property. Personalizing the decryption keys is one way to at least give the appearance of doing that, and it can make tracing violations an easier problem. Part of the difficulty in doing this is that we usually just want to encrypt a locked file one way with one key, because we want the freedom to distribute identical copies on CD. (On a web site, you could have it encrypted on the fly, but that could be a real bandwidth hog compared to the distribution model we like.) Therefore, what you really need is (1) an algorithm to derive a personal key from the master key that a! ctually locks the product plus some personal information from the user (i. e. name, email address, etc.), and (2) the inverse of that algorithm implemented in the product such that given the same personal information and personal key, it can generate the master key. The weak link, of course, in open source software especially, is that someone may get one valid personal key and hack the software to save or use the actual master key, then distribute both that and the hacked software. This is more work than just distributing the working personal key and personal information, but with less risk of getting caught since the personal information is also needed to cheat the easy way. The solution that I just described can be made stronger (from the seller's standpoint, and more obnoxious from the user's standpoint) by (1) using closed source proprietary software to do the security computations, and (2) requiring some of the personal information to be derived from each users' individual hardware setup (i. e. network card Ethernet address and other unique items that could be found). If you change your hardware setup any, then you have to buy another copy or beg for a free unlock. (This sounds like the seller stealing back the product if you upgrade your hardware, but Microsoft and Intuit like this idea a lot and use it.) I can see distributing a free but closed source unlock module along with a GPL product for the purpose of controlling access to clearly non-GPL copyrighted texts, but I don't advocate stooping to the levels of Microsoft's current operating systems and office products or TurboTax. (I won't be using TurboTax this year.) I think it is enough ! to tie the key to, for example, name & email address. You could link that to whatever other information you received for payment (i. e. verified address through PayPal or whatever) if you wanted to for the purpose of tracking violations. That is sufficient, in my opinion. Of course, my opinion isn't the opinion that counts. It is the opinion of the copyright owners that counts. I could construct the algorithms easily enough (and actually, I think I did once before), but it is something that publishers must agree with for it to be effective. If it allows us to distribute more Bible texts than we could with just a constant (non-personalized) key, then it is worth it. Rev. Michael Paul Johnson Servant of Jesus Christ [EMAIL PROTECTED] http://eBible.org/mpj/ _______________________________________________ sword-devel mailing list [EMAIL PROTECTED] http://www.crosswire.org/mailman/listinfo/sword-devel
