-----BEGIN PGP SIGNED MESSAGE-----
My comments below are not meant to cast doubt on Ryan Lackey's scheme, but just to raise some questions.
I am surprised, I have to admit, that Ryan is talking so much about raising money, getting investors, etc., when no _working model_ of his scheme has been deployed for people to play with, find weaknesses in, etc.
No working model has been deployed by me as of yet. However, most of the components are "solved problems", with existing working models. Worst case, it would be possible to accomplish equivalent functionality by linking these by remailers and hoping no one shuts down the remailers.
(In comparison to, say, remailers, which have existed for more than five years now, with literally thousands of articles--some good, some bad--written about them in all of their various facets. Even specialized lists for remailer operators, Mixmaster-type remailers, etc. And yet there have been no serious calls for investors to pour money in.)
I believe no one has seriously called to pour money into remailers because there is no money to be made from them, and making them commercial exposes them to additional pressure and liability, not because they are technically poorly designed.
Frankly, in reading Ryan's summary, including assertions like "In my system, no one knows (ideally) who is actually storing the data, only those on the edges of the system (who will hopefully only be known by a logical address)," I find no real discussion of the *core idea*, the _reason_ his data base is in fact secure.
It's not a database. A technical design document describing it, security assumptions made, and implementation guidelines has been under development. I have been working on small demonstration components only in order to test ideas -- I have identified technical problems which are essential to an Eternity implementation, and I have been looking into literature for solutions. In some areas, no good solutions exist in research, so I've been trying to find technical solutions.
(I apologize if a full discussion is contained in his earlier documents. Even if his earlier documents had a fuller description, there has certainly been an almost complete lack of discussion of his system here in Cypherpunks. Given the additional complexitities an Eternity type data base has over something as conceptually simple as a remailer, the lack of discussion is not confidence-inspiring that Ryan somehow got it all right.....)
A full discussion is included in a document which has not yet been released. It's not finished, even in draft form. Classes and leaving the country to talk to people and work on a side project got in the way of finishing it. Once a draft is done, I'm planning to release it to a small set of people, get their comments, then finish the demo and send it to the cypherpunks community, with a pointer to the demo. I do not want to release a half-finished draft for fear that then progress will slow to a standstill on the unfinished parts.
Anyway, I can think of all sort of threat models, and ways of (maybe) attacking any system of linked machines I can think of, except ones using message pools (which is why I'm biased in favor of Blacknet, I suppose).
(The motivation for Blacknet was to a) demonstrate message pools, b) show that anyone could be a node, c) build a system where the links between nodes are all of the traffic in "speech space," and that so long as encrypted messages could be posted in speech space (Usenet, boards, etc.), then the system could not be shut down. Basically, to stop Blacknet one would have to ban remailers in all jurisdictions, or ban speech coming from certain jurisdictions. Otherwise, it's too distributed to stop.)
I don't believe in the protection of being in "speech space" vs. being in network space as substantially different. Extralegal means will be used to shut down servers in either case, if it is sufficiently important to the attackers.
(Note: But Blacknet has long latency, derived from its "speech" underpinnings. There is the temptation to go to faster links, to move away from speech space into traditional network links. But this reduces the number of nodes and links, and makes an attack on the reduced-but-faster network no longer equivalent to interfering with free speech. A technological win but a political lose.)
It does not necessarily reduce the number of nodes and links (it may for a given amount of traffic).
Until we see a mathematical model--forget the details of implementation, the epiphenomenal stuff about Oracle, AOLServer, Alphas, and K6s!--of how N distributed nodes store incoming files in such a way that the goals of Eternity can be satisfied...
Yes, a mathematical and technical model is critical. However, certain technical questions not directly related to security are easiest to solve by experiment.
(And we need to discuss in more detail just what the goals can realistically, and economically, be.)
Yes, this is true. I've prepared a list of goals and assumptions -- I will post them at some point in the near future. Debate over them would be more fruitful than any technical debate at this point.
There are a bunch of issues which come up, motivated by Ryan's comments that he already has the design of a file system in mind:
- why won't all machines in the network in Country A simply be shut down, regardless of whether the Authorities can prove which machine in particular is storing the banned material?
If every single machine in country A is shut down, then Eternity access to that country fails. This is why it is essential that all machines involved in the network retain anonymity, both from users and from untrusted other nodes. Several methods exist for this, including a cellular structure, anonymous writing by using remailers or other technical means, etc.
- given the problems remailer networks have to deal with, with traffic analysis and correlation analysis (an area we have alluded to but not done serious work on), why would not the same methods be applicable to tracking movements through the system Ryan is apparently proposing?
Components of the system will take their own security into account when pricing service. It won't necessarily be linear. Since they have their own security in mind, they will not willingly send a file which will lead to their demise unless the reward for doing so is higher than the penalties of being caught.
(I believe a 20 MB child porn video MPEG sent into the Eternity network would leave "footprints" an analyst or watcher could track. I am willing to be show the error of my ways, but only with some calculations of diffusion entropy, for example.)
- In short, I want to see some simple descriptions of WHAT IS GOING ON.
I agree.
It has always been very easy for us to describe how networks of remailers work--so simple that at the very first Cypherpunks meeting in '92 we played the "crypto anarchy game" with envelope-based remailers, message pools, digital cash, escrow, etc. (Running this simulation took several hours, but taught us a lot.)
I'd like to know how Eternity DDS _works_. Then we can start mounting attacks on it: spoofing attacks, denial of service attacks, and attacks assuming various levels of observability into the network linking the nodes.
That's the primary reason for having both a design document and a demo. People can read about how it should work, and attack it at that level, as well as look at it in operation.
Until then, I think it's a waste of time and money to be coding a detailed implementation of a protocol.
True. I'm not coding a detailed implementation of a protocol, I'm doing a bunch of minor experiments to see what technical means are feasible, as well as trying to create something which lets people see how it works.
(And it may _still_ be a waste of money, even after the protocol is beat upon thoroughly. There is no clear market for such a service, and not even for remailers. And maybe not even for PGP, in terms of paying customers sufficient to pay the bills. Not to criticize PGP, just noting the obvious, the same obvious situation that seems to be the case with digital cash. Great idea, but where are the customers?)
That's why I'm trying to design the service with security *and* commercial usability in mind. I believe there are plenty of commercial uses for something with the right combination. If something like Eternity DDS exists which is indistinguishable to the user from a web server, and from those adding files from a system superior to a web server (such as a database), yet provides the level of security which I hope to provide, I think there will be a commercial market. So, I guess in order of priority: 1) list of goals and assumptions for a commercially-viable eternity service, with cypherpunks-level security, made available for discussion 2) technical design document to meet these goals circulated among some subset of the community for initial sanity checking 3) functional demo prepared which can demonstrate the feasibility of the system 4) release of 2) and 3) to cypherpunks, eternity, etc. for commentary 5) repeat 2, 3, 4 as necessary 6) production implementation I've been working on 1, 2, and 3 in parallel but with roughly correct distribution of effort.
Thanks,
The Feds have shown their hand: they want a ban on domestic cryptography ---------:---------:---------:---------:---------:---------:---------:---- Timothy C. May | Crypto Anarchy: encryption, digital money, ComSec 3DES: 408-728-0152 | anonymous networks, digital pseudonyms, zero W.A.S.T.E.: Corralitos, CA | knowledge, reputations, information markets, Higher Power: 2^2,976,221 | black markets, collapse of governments. "National borders aren't even speed bumps on the information superhighway."
- -- Ryan Lackey rdl@mit.edu http://mit.edu/rdl/ -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQEVAwUBNLmuyqwefxtEUY69AQE/iwf6As+DXq0Q+XfaIfvfYX0VKJFhvvBigLWB 6ShAOEIzA2jOSGmzmdVWYfHw2Lan5wRcj0VyCMCJo+YYGfxf62z3clPut2Qm2ABv j7xzD6oGVwpf0ESzo7ZlsBL57dyhQiX8EjJQD5RQJBPS5/+wvjw0GsmKb3Tw6042 3/T4aVol2x339XtIG+rck7XV6H6kFZeKE8dbfopH9C/7b26d9fbI8JDxFaaqi+Q/ ccPXL+dB3QRHls8rR4BqPwPQ+Z//Ui4j4V2dhHgWyfIHxcnYReh0vPlN8os3rIHw 2dFra1YLXZ50NVEV6GGPnOzwBqn+zqPVQaXBnyrWAClCCRz0JMITBw== =TE1C -----END PGP SIGNATURE-----