Hmm. To be honest, I know more of Phil Zimmermans battle with the NSA, than I do his technology. Already on my list is PGP. But what I intend to do, is make my own, then make it work with PGP. It sounds a bit weird, but I wanted to first come up with my way, then start looking at existing stuff, then try to merge them. But I want to merge them by working with the authors of the existing stuff. I also plan on sending royalty payments to the authors of the public domain RIPEMD hash function, which I use in the design a lot. I figure if I make money, they should too. The trust system works like this: a set method is used for authenticating the files, by contacting the nearest "Virtual Server", which is a server formed automatically in order to address bandwidth issues. I use New Zealand as a scenario because they spend a lot on international bandwidth, they a lot of international companies don't put servers there. I use a scenario of when Microsoft releases a new service pack for NT, a Virtual Server in New Zealand provides it. Microsoft does not know of this virtual server. This virtual server "subscribes" to a higher level virtual server, in Hawaii or Washington for example. These levels of virtual Microsoft servers end up subscribing to microsoft's site directly. Anyhow, the trust is 1 way, from the lower level the the higher level. The central authentication service comes into play by being the third party. By removing the authentication responsibility from cnn, and making it a shared responsibility between cnn an the central authority, it kinda works out better. Think of it this way, if A and B want to verify each other, they must have a neutral third party in order to truly do so. The business model Verisign uses, where they are hoping to be the Switzerland of the internet, is similar to how UNI-ID works with MFS. They are 2 separate systems. MFS simply uses UNI-ID's for its servers and users. Eventually, I hope to legally separate the two into different entities. It will be UNI-ID who must interface with the law enforcement of the world. I want to build the MFS standard. I hope to get some good lawyers, and a bunch of retired feds to run the organization. I used to dream of all the ways MFS can be used, now I think about all the political ramifications that UNI-ID will have to deal with. Essentially, we will have the NSA begging us to cooperate, when the plans for the B2 stealth bomber are placed onto the internet. And because of the anti virus features, we will have the ability to lock down newly arrived files (not delete them). End users can turn this on or off (its off by default). I can imagine the NSA begging us to do a virus lockdown on the B2 files. Hell, I could write a thesis just thinking of all the crap UNI-ID will have to deal with. Hell, I even made the part numbering so that 1900 is the configuration values, and value 1984 specifies what "big brother" options are enabled. See, funny thing is, big brother can stomp viruses quite well. I keep delaying the patent, because I keep adding features to it, and the attorneys have dedicated a filing cabinet to me. (those poor guys). >From a security standpoint, I'm having a problem getting the multi-authority model to work, so I'm sticking with the single authority for now, and after I release, I hope to have people like you join in and help me improve on it. Right now, I'm adding a Syncrhonization Group feature, that is essential to make the Office 2004 scenario work, where office is a native MFS program that runs from URL's. Imagine this: Installing office is the following steps: 1. Modify registry. 2. Make shortcuts in start menu, pointing to "mfs://files.microsoft.com/office2004/word.exe" etc. 3. Either run the program immediately and put up with the hourglass the first time, or wait for the files to be made local. The permanent caching then kicks in, and its fast from then on. When Microsoft sells office, they simply add your UNI-ID to the office UNI-ID group. Its up to you to get a copy of the files. You can get them from your neighbor, and your ISP will probably direct your requests for them to your neighbors, to save the bandwidth. When restricted files like office are sent, they are first encrypted with the office UNI-ID group's public key. That way, Microsoft can't complain about their stuff getting pirated, because only members of the group can retrieve the private key. And the keys can be made obsolete. Basically, it will be easier to rip off the non-MFS version of office, than the MFS version. The same features that would allow me to save my tax return to MFS, end up being the same features that will respect the copyrights. Copyrights become a decryption issue. (!!!) Basically, with this design, www.cnn.com can exist as a single server on the internet, and the internet can shoulder the load. Because storage is cheaper than bandwidth, and ISP would rather buy more hard drives than pay for repetitive international bandwidth. If people in new Zealand access many Microsoft files, or cnn files, thru this usage pattern Virtual Servers will naturally form in new zealand, and thru location independence, they will be the source of microsofts files. Each virtual server has the shared secret of the lower levels. Its gets a bit tricky to summarize how it works. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Mika Hirvonen Sent: Sunday, May 13, 2001 9:11 PM To: [EMAIL PROTECTED] Subject: Re: [freenet-tech] RE: [freenet-chat] RE: I've designed a global file system,... -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - ----- Original Message ----- From: "Josh" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, May 14, 2001 4:41 AM Subject: RE: [freenet-tech] RE: [freenet-chat] RE: I've designed a global file system,... > Good points! > > The system will operate fine when the central authentication (not > security) is taken out, its just that at that point in time User X will > not be able to validate that file Y is authentic and really came from > domain Z, for the first time. It's design so that existing trusts, from > www.cnn.com to their ISP, for example, will continue to operate. So the > ISP and CNN will still be sure they have authentic files, but a new > party, lets say another ISP, who wishs to get the cnn files from the > first ISP, will not be able to validate that they are authentic files, > while the central authentication system is down. How about using a web of trust (like PGP does)? Everyone could create keys and trust whoever they want, but sites could gain trust automatically by caching content and not corrupting it. The original site (www.cnn.com in this case) could sign everything it posts. Clients could then download the stuff www.cnn.com posted from any site that cached the content. The client then automatically retrieves the signatures for the content and compares them with the files it got. If the signature is good, the site the content was downloaded from gains a certain amount of trust. If the signature doesn't match, the site loses a great deal of trust. After a site gains a certain amount of trust (which can be set by the user), the client automatically signs the site's public key, knowing that it is a "honorable" site. Like in PGP, users can choose to trust other users' signatures, so sites could immediately gain the "honorable" status, if they have served good (unchanged) content to friends of an user. This system has its flaws, though. The most obvious one is that aan attacker could generate a bogus (but trustworthy-sounding) key and post fake information with it. If an user has not previously visited the real site and does not know anyone who has, the user could still be fooled to get the fake content. - -- Mika Hirvonen <[EMAIL PROTECTED]> http://www.saunalahti.fi/hirvox/ PGP key @ http://www.saunalahti.fi/hirvox/stormshadow.asc -----BEGIN PGP SIGNATURE----- Version: 6.5.8ckt http://www.ipgpp.com/ iQA/AwUBOv8+xaSfrEHp33TBEQIMWgCeOqN/pa6xk41wwIJsn0tnjs0PpagAnA6l dIaap/qeF4M2tiE0AXO4wa0M =pO28 -----END PGP SIGNATURE----- _______________________________________________ freenet-tech mailing list [EMAIL PROTECTED] http://lists.freenetproject.org/mailman/listinfo/tech _______________________________________________ freenet-tech mailing list [EMAIL PROTECTED] http://lists.freenetproject.org/mailman/listinfo/tech
