From: Matias Klein >I would not guarantee the validity of what I am about to suggest because >I am not a security expert. However I believe that one way to write an >application such as Dr. Slater described is to wrapper the data access >algorithms within a "secure run-time" (i.e. something like a java >application server). These wrapper classes can handle the >authentication, data access, and encryption/decryption.
Aside from violating the license agreement, there would be no need to use the supplied front-end in a situation like this (or, in fact, in many similar situations. In Java particularly, all one would have to do is run a debugger (or closely examine the .class files) to identify the methods handling decryption, and then write a tight loop to "slurp" the entire database through this decryption. Even lacking the wrapper classes, there has yet to be a form of encryption which will resist a serious effort to decrypt it. For example, a cluster of computers could "easily" be programmed to try a "dirty dialler" sequence of every possible decryption key to obtain the information from a database. Think of the old Unix /etc/passwd file. At one time, the actual (encrypted checksums of) passwords were kept in this file. Today, we have /etc/shadow, because it was found that any user could make a copy of /etc/shadow and run a long-running program like crack(3) against it to obtain the list of passwords. Just using a standard US keyboard, there are only 185 characters that can be typed (92 keys, 92 keys with Shift, and spacebar). Since most users choose passwords in the 8-10 character range, there are only about 185**10 possible combinations -- 46_958_831_761_893_056_640_625 - 4.6e25 may seem like quite a large number, but it's achievable on even modest hardware with a decent investment of time. Taking on PK/PK-type encryption, of course, might mean having a 4096-bit key, a much larger search space, but is still achievable within a reasonable time with sufficient CPU power behind it. As far as building an Open Content-type database of this kind: the "No warranty" clause would seem (in the US at least) to make it quite difficult to encourage the use of such a thing. Certainly, I agree that government intervention would be The Right Thing; whether the US or EU governments might actually be convinced to provide such a reference, though, seems dubious. When it comes to replacing a large corporate oligarchy with a government agency, the US gov't a least has been wont to side with the corporate oligarchy. (Witness recent works on the behalf of Microsoft, the RIAA, Disney, et al.) A subscription model was mentioned; this might be the most workable concept. A database could be presented as a "web service" with a subscription policy, and offer the data to authenticated clients over an XML channel of some kind for viewing in an open source application. In such a case, the agency would have reasonable guarantees that their users would at least be aware of the illegality of duplicating the database, in the same way as a cinema is reasonably guaranteed that no one brings in a camcorder without having to search each guest.
