A few technical observations about your problem On Wed, Mar 11, 2009 at 2:47 PM, Peter von Kaehne <[email protected]> wrote: > Karl's question is probably the one I will need to answer first: > > What problem do I want to solve? > > a) A bible which has not been (will not be) distributed sufficiently on > paper to allow recipients to compare with known good texts.
Electronic distribution can solve this - but if the people don't have access to enough Internet to download the very-small libsword source code, they probably don't have enough connection to download the modules either. > > b) A hostile environment in which the Bible is considered a societal evil. Not sure how having it installed on a computer helps the person in this regard. > > c) A hostile environment where cults will try and undermine genuine > Christian growth by producing a counterfeit "Christianity" Computing a hash of the module and signing it with a public/private key setup, where the private key is held by only one or a very small number of people (e.g. Chris) for signing the versions that come out of the SWORD repository. There are a few things to worry about here, though: if we select a particular small passage to compute the hash over, the cult could just modify other portions and leave the hash and tested text untouched. Computing the hash over the entire module could easily run performance issues on even fast, modern hardware depending on the size of the data to say nothing of older hardware that has performance issues. Choosing a good but fast hash would certainly be required - something that can be done. > > On the plus side: > > d) An environment in which genuine computing knowledge is rare and not > by necessity in the hand of those who oppose. Security by obscurity like this is no security at all. It only takes one person with technical knowledge somewhere to publish a, "This is how you hack the SWORD Project's modules" and even the non-technical user could probably accomplish it. > > e) An environment where Bibles are ripped out of your hand due to > genuine hunger. Not sure there's any technical matters to address here. =) > > f) An environment where theoretical access to source code will not > significantly allow subversion of whatever scheme we chose as the source > code on our servers is essentially not accessible due to slow internet > connections. Again - see point (d). Also, someone with more knowledge of the GPL will have to comment on the legality of distributing the binaries in this type of environment without also providing the source code in a matter at least as accessible as the binaries. If there are no Internet connections of reliable natures there, presumably the binaries are being distributed with the modules on some other type of media (CD, DVD, pen drive) and the stipulations of the GPL, as I understand them, require that the source code either already be part of the distribution or that the person giving out the binaries offer a way to distribute the source code. Short of re-licensing the SWORD Project under a different license for this particular situation, relying on the method you mention for security smacks of illegality in the face of the GPL to me, but I might be mistaken there. > > This is not a theoretical scenario, but one which affects in this or > similar form several areas of this sad world. Sadly - but this is what we are told to expect and "rejoice and be exceedingly glad" during, is it not? > > The challenge is to create sufficient protection to the text to make it > easier to distribute an intact module then to mess with it. Easier for > someone with less knowledge than me, a non programmer. Someone who is > used to ripped Windows XP, has possibly some tools, but can neither > compile nor is mentally capable of learning this within sufficient time > scale. Someone with evil intent but not sufficient stamina to copy 66 > books per chapter by hand, re-insert encoding and produce an equivalent > but distorted module. Due to the nature of the SWORD Library being open source, writing a tool to do exactly that is very straightforward, only a few lines of code when only a single module is being targeted, and no bigger than the mod2osis.cpp already included in the source tree. As I mention above, it only takes one person with the knowledge of how to bring up a simple ./configure --enable-utilities && make && make install to have the mod2osis already available to them which they could then distribute to their heart's content and render the above point. However, signing the module with a hash/private key and distributing the public key with the source and executable would at least allow anyone who wanted to test the integrity of a module to do so. Again, with a very limited knowledge of programming someone could comment out the checks and build a binary that didn't check the content of the module. And I daresay that front-ends would probably demand there be a flag to indicate possible tampering but still have the text available to show the user after having alerted them to the possibility of tampering. So you can't stop people from altering the material, but you can make it much easier for a user to check that the module is as CrossWire intended. > > The challenge is to do this while maintaining the ease of copying a > module + programme allowing viral redistribution. This isn't an issue - the issue is allowing ease of creating a signed module by anyone who wants it. If we do the public/private key signing, then either we must distribute the keys to anyone or any organization who wants to create a signed module - which diminishes the security of that approach - or we must provide a mechanism for supporting multiple sources of authentication which leaves the task of whose modules to believe up to the user and increases the possibility of any one of those modules being corrupted, leading to a need for us to deauthorize keys lest any compromised key pair become available to a party wishing to tamper with the module. We can build something like this, but it becomes a massive undertaking in computer security infrastructure which is well beyond the scope of this project. Of course, the simple and straightforward alternative is we only program in a key pair from CrossWire and if other parties want to sign modules themselves let them rebuild the program from source with their key. But then you couldn't use their modules with our build or our modules with their build. Clearly the signing issue is the tough one. It falls to policy makers to decide which method to implement - the hash and signing is relatively straightforward to implement. Is that a decent description of the technical aspects of your problem? Implementing is rather simple if we decide to do a single signing source (us) and are happy with our encryption algorithm. It will allow us to distribute the source with the public key and rest assured that our modules we have signed will hold their integrity (at least to the extent we trust the hash and encryption we've used). --Greg _______________________________________________ sword-devel mailing list: [email protected] http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page
