Re: In God We Antitrust, from the Netly News

> [people disparaging the  AMD/Cyrix Processors, as well as defending them]

I have used a K6-200 overclocked to a K6-300 (83mhz bus speed) for
some time now, mostly accomplishing the cooling issue by leaving it
in my bedroom with the window open all winter.  It's a great
value -- for $200+$100 I got a processor and motherboard capable of
PII-level performance in things like code compiles, etc.  I've even
hand-optimized some code for the K6 -- it's a great chip.

If I find investors/customers/etc. by March-July 98 for Eternity DDS, though, 
I'm planning to buy 8 DEC AlphaPC motherboards with dual 21264 processors.
Some pieces of Eternity DDS are now being implemented in Oracle for
speed of implementation reasons, and other pieces are being prototyped
in Scheme (maybe), so even my K6 is getting hammered.  Plus, I'm now testing
some kernel modifications, and having to reboot the only functional server,
bring Oracle back up, initialize the world, bring up a web server and
an encrypted filesystem, etc. all without disrupting service too much
whenever I make a minor change, then do it every time I need to change
one character in the kernel, is really annoying.  Running the different
services on different machines would be far more realistic and practical.

[*Obcrypto*: I have gotten incredibly backed up with work of various
kinds, and email.  However, I still have time for silly web service
questions.  Here goes:

Does anyone know of a way I can take a web server, say AOLserver, which
does not support useful SSL, and also does not distribute source, and
retrofit a useful 128-bit SSL implementation to it?  It has a C API, but
I haven't looked at the API enough to see if I could do it within the API.
Are there any proxies which could be stuck between the insecure server
and the user (preferably with an ssh link between the servers) which could
provide SSL proxy service?  It seems like this should be trivial to do,
but I haven't tried yet, and I want to have some reedeming value for this
post.]
-- 
Ryan Lackey
rdl@mit.edu
http://mit.edu/rdl/

I haven't been following the latest round of "Eternity" discussions. I
gather that Ryan's efforts are distinct from Adam Back's efforts, which are
themselves distinct from the seminal Ross Anderson researches (for example,
at http://www.cl.cam.ac.uk/users/rja14/eternity/node4.html).

But Ryan's comments leave me with some questions:


At 3:11 AM -0800 1/11/98, Ryan Lackey wrote:

>If I find investors/customers/etc. by March-July 98 for Eternity DDS, though,
>I'm planning to buy 8 DEC AlphaPC motherboards with dual 21264 processors.
>Some pieces of Eternity DDS are now being implemented in Oracle for
>speed of implementation reasons, and other pieces are being prototyped
>in Scheme (maybe), so even my K6 is getting hammered.  Plus, I'm now testing

Will these be located in the U.S.? Will their locations be publicized? Will
any offshore (non-U.S.) locations be publicized?

Any file system which can be identified as to *location in some legal
jurisdiction*, espeically in the U.S. but also probably in any
OECD/Interpol-compliant non-U.S. locations, will be subject to COMPLETE
SEIZURE under many circumstances:

* if any "child porn" is found by zealous prosecutors to be on the system(s)

* if any "national security violations" are found to be on the system(s)

* if the Software Publisher's Association (SPA) decides or determines that
the Eternity systems are being used for "warez" or other copyright
violations.

In addition, the file systems may be "discoverable" in any number of other
legal situations, and of course subject to subpoenas of all sorts. And
subject to court orders to halt operations, to participate in government
stings, and so on.

Basically, anything a remailer in some country may be subjected
to--lawsuits by Scientology, kiddie porn charges, espionage charges,
etc.--will be something an Eternity server is also subject to.

Except that an Eternity file system is more clearly just a file storage
system, like a filing cabinet or a storage locker, and hence is readily
interpreted in courts around the world as something that law enforcement
may seize, paw through, admit in court, etc. (Remailers are slightly better
protected, for both reasons of "transience" and reasons of some protection
under privacy laws, the ECPA, etc. We have not seen any major court orders
directed at remailers, but I expect them soon. In any case, a file system
containing "warez," child porn, corporate trade secrets, national security
violations, defamatory material, etc., would not be ignored for long.)

So, the talk about the hardware of all these Alpha servers raises some
interesting questions.

I would have thought that a much more robust (against the attacks above)
system would involve:

- nodes scattered amongst many countries, a la remailers

- no known publicized nexus (less bait for lawyers,  prosecutors, etc.)

- changeable nodes, again, a la remailers

- smaller and cheaper nodes, rather than expensive workstation-class nodes

- CD-ROMS made of Eternity files and then sold or distributed widely

- purely cyberspatial locations, with no know nexus

(I point to my own "BlackNet" experiment as one approach.)

It may be that the architectures/strategies being considered by Ryan
Lackey, Adam Back, and others are robust against the attacks described
above.

Basically, if the Eternity service(s) can be traced back to Ryan or Adam or
anyone else, they WILL be subject to court orders telling them to produce
certain files, telling them to cease and desist with regard to certain
distributions, and so on. Even raids to carry off the entire file system
for analysis will be likely.

Consider the Steve Jackson Games case, the Thomas/Amateur Action case, the
Riverside/Alcor case, and other raids which have seized computers and file
systems. Though some of these were later overturned, there was no general
protection granted that a file system, which is like a filing cabinet (of
course) is miraculously exempt from court action.

It is also likely in the extreme that a working Eternity service will
quickly be hit with attackers of various sorts who want to test the limits
of the service, or who want such services shut down. Thus, expect all kinds
of extremely controversial material to be posted....granted, this is a
"reason" for such services, but see how long the system lasts when it
contains child porn, Scientology secrets, lists of CIA agents in Europe,
copies of Microsoft Office for download, and on and on.

And even a decentralized, replicated system will of course still expose the
owner/operator in some jurisdiction to his local laws. (As Julf was exposed
to the laws in his country, and that was just the tip of the iceberg.)

Eternity nodes must not be identifiable, and their locations must not be
known. Anything else is just asking for major trouble.

Comments?



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."

Tim May <tcmay@got.net> writes:

[ Ryan Lackey on proposed hardware setup for his Eternity DDS ]

> Will these be located in the U.S.? Will their locations be
> publicized? Will any offshore (non-U.S.) locations be publicized?
> 
> Any file system which can be identified as to *location in some legal
> jurisdiction*, espeically in the U.S. but also probably in any
> OECD/Interpol-compliant non-U.S. locations, will be subject to COMPLETE
> SEIZURE under many circumstances:
> 
> * if any "child porn" is found by zealous prosecutors to be on the system(s)

I think child porn is pretty much the canonical example -- the spooks
/ feds have a history of posting their own child porn if none is
available to seize.  (eg The Amateur Action BBS case which Tim cites
classic case -- the Thomases had not had any dealings with child porn,
but a US postal inspector mailed some to them, and busted them for it
before they had even opened the package.  They are still in jail
now.)

An article which got forwarded to cypherpunks a while back was a URL
for some people who had created a for-pay web service which consisted
soley of hypertext links to child porn articles in usenet.  I never
did investigate (the worry is always that it is a sting in itself, and
I was interested in the techniques not the material), but it is
interesting that these people considered this action safe enough for
the monetary rewards to compensate.  

(Anyone save this post / URL, or know if these people are still in
business, or what technique they used to be able to generally link to
USENET articles... is it possible to link to
news:alt.anonymous.messages/message-id in a way which is independent
of news spool?)


I agree with Tim that actually building distributed file systems where
data can be traced back to the server serving it will cause problems
for the operators.  I think even if there are many operators, and even
if the data is secret split, the operators would likely be held
liable.

Ross's paper describes some techniques for building a distributed
database which makes it difficult for a server to discover what it is
serving.  (Necessary because an attacker will become a server operator
if this helps him).


The threat of seizure is the reason that I focussed on using USENET as
a distributed distribution mechanism.  All sorts of yucky stuff gets
posted to USENET every day, and USENET seems to weather it just fine.

The idea of using new protocols, and new services as Ross's paper
describes is difficult to acheive a) because the protocols are more
complex and need to be realised, and b) because you then face
deployment problems with an unpopular service and supporting protocols
who's only function is to facilitate publishing of unpopular
materials.


So I focussed on USENET, but the weakness of using USENET for building
a distributed database where data is intended to persist for
protracted periods of time is that USENET articles expire, existing in
news spools often for only 3 days or so.  The problem is really that
USENET is essentially a distributed _distribution_ mechanism, and not
a distributed database.

Archiving USENET as a separable enterprise which charges for access
(altavista for example charges via advertisements) seems less
problematic than directly trying to build a database of controversial
materials.  Archiving it all partly reduces your liability I think,
because you are not being selective, you just happen to have a
business which archives USENET.  However there are two problems with
this: a) volume -- USENET daily volume is huge; b) the censors will
ask you to remove articles they object to from the archive.

The solution I am using is to keep reposting articles via remailers.
Have agents which you pay to repost.  This presents the illusion of
persistance, because the eternity server will fetch the most recent
version currently available in the news spool.  This avoids
centralised servers which would become subject to attack, all that is
left is a local proxy version of an eternity server which reads news
from an ordinary news spool.

My current implementation is a CGI binary which is currently running
as a remote eternity server.  You can run it as a local eternity
server if you have a local UNIX box, running say linux.

Better would be a more general local proxy for other platforms.  I am
working on this local proxy version at present.  This is the state of
play for me.


The reposter will be either the publisher of the article, or a
reposting agent.  In either case remailers can be used.

Remailer resistance to attack has improved a lot since some of the
remailers started using disposable hotmail etc accounts as exit nodes
-- the remailer is no longer traceable without a much higher resources
being spent by the attacker.  Using a chain of mixmaster remailers,
and a remailer using hotmail for delivery provides good anonymity.

> I would have thought that a much more robust (against the attacks above)
> system would involve:
> 
> - nodes scattered amongst many countries, a la remailers

Better to have no nodes at all, as with USENET only solution.  The
reposting agent (which may be the publisher, or interested reader if
they are fulfilling the role of reposting agent) is a node of sorts,
however this node can be replicated, can move frequently, and only
ever need communicate via remailers.

> - no known publicized nexus (less bait for lawyers,  prosecutors, etc.)

This one is crucial.

> - changeable nodes, again, a la remailers
>
> - smaller and cheaper nodes, rather than expensive workstation-class nodes
> 
> - CD-ROMS made of Eternity files and then sold or distributed widely

This is an interesting suggestion, but surely would open the
distributor up for liability, especially if copyright software were
amongst the documents.  Were you thinking of 

> - purely cyberspatial locations, with no know nexus
>
> (I point to my own "BlackNet" experiment as one approach.)

This is the best option.  Make it entirely distributed, so there is no
nexus, period.  cyberspacial -> meatspace mappings are often easier to
trace than we would wish, especially where there is continued usage
(for example there are various active attacks which can make progress
even against mixmaster remailers).  This is the weak point of my
reposting agent, be that human, or automated.

However anonymous interchangeable reposting agents is an interesting
concept.  One way to view the reposting function would be to view it
as a new function for remailers; that they would post a message a
specified number of times at specified intervals.

However it is probably better to separate the function into a separate
agent because remailers are known, and few in number.  A reposting
agent need never advertise an address.  Instructions to the agent
would be via USENET (it would read news for instructions and eternity
documents bundled with ecash payment for it's services, and repost
these according to those instructions).  The reposting agents would be
motivated by profit, have reasonable chances at obscuring their
identity through the use of remailers, and so would be willing to take
the risks.  A smart operator could further reduce risks by using
resources intermittently and unpredictably, and by using multiple,
automated entry nodes into the remailer net.

Potentially agents could be left operating in cracked accounts,
siphoning payments off to their owners, at fairly low risk to the
owner.

Agents could be rated for reliability in delivering services paid for,
or payment could be enabled for each repost by a arbitration agent
upon seeing the post.

> It is also likely in the extreme that a working Eternity service will
> quickly be hit with attackers of various sorts who want to test the limits
> of the service, or who want such services shut down. 

I agree with this prediction.  Remailers have seen this pattern, with
`baiting' of operators, and apparently people posting controversial
materials and reporting the materials to the SPA or others themselves,
etc.

As you might guess part of the above are unimplemented.  The local
proxy is my current task.  Reposting agents are unimplemented, as is
integration of payment.


Another comment is that reader anonymity is a separable aim which
should be cleanly separated from the design.  Services like
anonymizer, crowds, pipenets, SSL encrypted news server access
(supported by netscape 4), and local news feed can ensure anonymous
access to eternity document space at varying cost trade-offs.

Adam
-- 
Now officially an EAR violation...
Have *you* exported RSA today? --> http://www.dcs.ex.ac.uk/~aba/rsa/

print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<>
)]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`

-----BEGIN PGP SIGNED MESSAGE-----


Adam Back <aba@dcs.ex.ac.uk> writes:
> 
> Tim May <tcmay@got.net> writes:
> 
> > Any file system which can be identified as to *location in some legal
> > jurisdiction*, espeically in the U.S. but also probably in any
> > OECD/Interpol-compliant non-U.S. locations, will be subject to COMPLETE
> > SEIZURE under many circumstances:
> > 
> > * if any "child porn" is found by zealous prosecutors to be on the system(s)
> 
> I think child porn is pretty much the canonical example -- the spooks
> / feds have a history of posting their own child porn if none is
> available to seize.  (eg The Amateur Action BBS case which Tim cites
> classic case -- the Thomases had not had any dealings with child porn,
> but a US postal inspector mailed some to them, and busted them for it
> before they had even opened the package.  They are still in jail
> now.)
> 
> I agree with Tim that actually building distributed file systems where
> data can be traced back to the server serving it will cause problems
> for the operators.  I think even if there are many operators, and even
> if the data is secret split, the operators would likely be held
> liable.

I agree as well.
> 
> Ross's paper describes some techniques for building a distributed
> database which makes it difficult for a server to discover what it is
> serving.  (Necessary because an attacker will become a server operator
> if this helps him).
>
> The threat of seizure is the reason that I focussed on using USENET as
> a distributed distribution mechanism.  All sorts of yucky stuff gets
> posted to USENET every day, and USENET seems to weather it just fine.
> 
> The idea of using new protocols, and new services as Ross's paper
> describes is difficult to acheive a) because the protocols are more
> complex and need to be realised, and b) because you then face
> deployment problems with an unpopular service and supporting protocols
> who's only function is to facilitate publishing of unpopular
> materials.

Solved, I think  a) someone drops out of MIT and works on Eternity DDS to
the point where people want to dump money into it, assuming it is
a fundamentally good idea, and b) by using market based protocols which give
a financial incentive to people running stuff, there is a rush to set up
eternity servers.

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).  
> 
> The solution I am using is to keep reposting articles via remailers.
> Have agents which you pay to repost.  This presents the illusion of
> persistance, because the eternity server will fetch the most recent
> version currently available in the news spool.  This avoids
> centralised servers which would become subject to attack, all that is
> left is a local proxy version of an eternity server which reads news
> from an ordinary news spool.

That sounds like an interesting idea.  It is certainly far simpler to
implement than my suite of protocols.

> > - purely cyberspatial locations, with no know nexus
> >
> > (I point to my own "BlackNet" experiment as one approach.)

You may have solved the problems of persistence in Eternity, and if users
are intelligent about picking addresses, you may have solved the persistent
and logical URN problem.  Cool!

I'm not sure the problems of scaling to a full production system have been 
addressed,
though.  Would usenet simply ignore the additional, and potentially highly 
illegal,
and non-readable traffic?  alt.binaries.warez got punted pretty quickly.  
Also, your
scheme does not include any provisions for people to post active objects of
any kind, or market-based load balancing, both of which I consider critical
features -- people will overload any Eternity server they can find -- what 
financial
motivation would the overt owners of the server have to upgrade to handle the 
traffic?
USENET is also not quite as resilient as it used to be.

I may have an unreasonable bias against usenet, but I think any protocol which 
depends
upon USENET rather than just using it as one of many potential transport 
mechanisms
is unable to scale.  Certainly the performance of your Eternity implementation 
will
be far from real time.  Coupled with not providing dynamic objects of any 
kind, I think
there are a large number of services which could not function in your system.

It's still has a lot of potential, and is actually highly feasible to 
implement, which is
good.  And you seem to be evolving it, which leads me to think any potential 
problems
will eventually be solved.  It would be interesting if we could share 
components which
were common to both designs, such as a payment arbitrator or whatever.

Having multiple interoperable Eternity implementations would actually be 
really interesting.
They could store data in each other, in something of a recursive auction 
market (the
data taken from a user commands a premium price immediately because it's 
"hot", once
it gets buried a bunch of times it is a bit more shielded), share payment 
protocols, etc.
Letting the market decide where it wants to put its data seems like the best 
plan.
- -- 
Ryan Lackey
rdl@mit.edu
http://mit.edu/rdl/		



-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQEVAwUBNLmWnqwefxtEUY69AQGdzAf+PAbPSbO202uPSBJImJ9JDryHvWRvMA5H
QSdh+nsAq2dvXUkLm+ReJfYs4PDTimhBPYLxiAo/ooMeAsWwzCMNjFHeqS6V5VCV
dM4mJ37SsNTauVtcvWTTBJELlq4kzOjV2Lyn/eDvWwdnhvIv24mWclUZy8EC+0b6
+KEFktcK25SIIO0VH/fezHixawl+AiM1LATxMm8chmc4FTiHUc6swTSulOap0zeT
te21+zPuq0N5stzRPDfTePrjhneR3Zku9hq0sxK0Nbzaz790Jb4jh+q2XsFK0ow+
JiQZ59dj4bGHjq2H1u4TVcHQ/B16LZDxUz1nyvfw2uPBldmIQ0XSYw==
=AfMI
-----END PGP SIGNATURE-----

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.

(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.)

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.

(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.....)

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.)

(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.)

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...

(And we need to discuss in more detail just what the goals can
realistically, and economically, be.)

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?

After all, when a kiddie porn ring has its computers seized, the
Authorities don't necessarily have to prove exactly which disk sector (or
even which disk drive) is storing a file...they can either seize the lot,
and prosecute successfully, that the ensemble was the nexus, or
instrumentality of the crime.

To paraphrase Sun, "the network _is_ the crime."

- 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?

(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.

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.

Until then, I think it's a waste of time and money to be coding a detailed
implementation of a protocol.

(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?)

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."

-----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-----

hAt 12:49 AM 1/12/98 EST, Ryan Lackey wrote:
>[Tim May wrote:]
>> 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.

My guess is that the technical aspects are relatively solvable,
at least if the market comes through with reasonable digicash.
The technical design can be fun, and lots of pieces exist.
The "Don't Quit Your Day Job" (or in this case, school) criteria are 
harder - doing the business plan that makes a reasonable case that
1 - Service Providers using your model can make money
2 - You personally can make money
3 - Potential investors (including you) can make money
	funding the development
Three obvious business models for you and your investors are
2a - Operate the service yourself, hiring people or renting space
	in as many countries as you need for safety/reliability
2b - Sell/license the software to commercial providers
2c - Freeware, perhaps with some way for you to get advertising revenue
	or at least sufficient fame to get consulting business.

Which combinations of these options can achieve wide usage depends
a lot on your models of users of the system; some of those models
are moneymakers, some aren't, some are safe, some are dangerous,
and some just attract a sleazy clientele.  Here are a few models

- public, permanant, non-controversial - the archive business
	for URLs for academic papers, news services,
	and possibly for contracts, wills, court documents, etc., 
	which may have some privacy (e.g. an encrypted document 
	showing the owners and keyids) or may not be indexed.
	This model is easy, and the only reason you need
	to franchise the business rather than running it yourself
	is to increase the confidence of the users that the
	service will be permanent.  The obvious financial model
	is that computers and storage become cheaper every year,
	so the cost of 100 years of storage is probably only
	25-100% higher than 5 years of storage.  The costs of retrieval
	are different from the costs of storage; you may do something
	like advertising banners to handle frequent-retrieval vs.
	occasional-retrieval material, or charge directly per hit, etc.

- public, permanent, controversial - political manifestos,
	samizdata, Singaporean chewing-gum recipes, 
	formerly secret documents of governments and businesses.
	Spreading across multiple jurisdictions is
	critical here, but governments do cooperate enough
	that few places are safe for everything.  For instance,
	a Finnish court might order a server to stop publishing
	copyrighted Scientology documents based on a US court order;
	anything copyrighted needs to be hosted by non-Berne-convention
	locations.  I don't know how cooperative governments are about
	libel suits from other jurisdictions; "libel against governments"
	is clearly a different case from regular personal libel.

- non-indexed semi-public medium-term controversial -
	porn servers, warez, credit reporting services, and the like.
	By "non-indexed semi-public", I mean things that you can
	retrieve if you know the name and maybe have a password,
	but can't retrieve if you don't, and maybe they're encrypted.
	Some of them may be revenue generators for the storage customer
	(e.g. they've got advertising banners, or they require digicash
	to be collected somehow, or maybe there's a password-of-the-month
	needed to decrypt them, which is sold separately from distribution.)
	Here you need to worry about attacks, since pictures that are
	legal in LA or Paris may be illegal in Memphis, Tokyo, or Riyadh,
	and transaction data that's legal in Anguilla may violate
	data privacy laws in Berlin or fair credit reporting in Washington,
	and warez that are gray-market in Beijing may get you jailed in
	Redmond (while the porn that's legal in Redmond may get you 
	jailed in Beijing.)  
	You also have to worry about targeted attacks - the government
	that can't stop you from publishing the Anti-Great-Satan Manifesto
	can go plant child porn and stolen Microsoft warez on your server
	to get you shut down in your home country.

- non-indexed semi-public medium-term non-controversial -
	encrypted corporate backups and the like.  If you've implemented
	things right, a subpoena for all your files worldwide still
	won't let anybody find a useful piece of non-indexed data,
	but can still let anybody with the name and password recover it.
	Indexing becomes the job of the user; the index for a user
	is just another data file.  This may be where you make the 
	legitimate money, if you can convince enough businesses to
	use your services, and where you provide the cover traffic
	for the controversial material.
				Thanks! 
					Bill
Bill Stewart, bill.stewart@pobox.com
PGP Fingerprint D454 E202 CBC8 40BF  3C85 B884 0ABE 4639

Tim May wrote:

> I would have thought that a much more robust (against the attacks above)
> system would involve:
> 
> - nodes scattered amongst many countries, a la remailers
> 
> - no known publicized nexus (less bait for lawyers,  prosecutors, etc.)
> 
> - changeable nodes, again, a la remailers
> 
> - smaller and cheaper nodes, rather than expensive workstation-class nodes
> 
> - CD-ROMS made of Eternity files and then sold or distributed widely
> 
> - purely cyberspatial locations, with no know nexus
> 
> (I point to my own "BlackNet" experiment as one approach.)
> 
> It may be that the architectures/strategies being considered by Ryan
> Lackey, Adam Back, and others are robust against the attacks described
> above.
>
> ...
> 
> Comments?

There is one thing that comes to mind that was just a topic covered on
this
list and that is the use of cellular/wireless/RF/ham for connections to
said machines.

Obviously, this would make seizure more difficult (and perhaps increase
the
likelyhood of prior warning, if for example, cellular service was
suddenly
cut off).

I am currently studying some parallels between the established FCC
tolerance
of ham radio self-regulation vis-a-vis anonymous remailers.  I haven't
yet
drawn up my opinions, as they are still being formed.  I think that this
might be one avenue to look down as there is obviously a type of legal
precident in what is allowed/tolerated under obvious FCC jursidiction,
whereas the jurisdiction over IP is obviously still ambiguous.
 
--David Miller

middle  rival
devil rim lad

Windows '95 -- a dirty, two-bit operating system.

At 3:06 PM -0800 1/11/98, Adam Back wrote:

>Archiving USENET as a separable enterprise which charges for access
>(altavista for example charges via advertisements) seems less
>problematic than directly trying to build a database of controversial
>materials.  Archiving it all partly reduces your liability I think,
>because you are not being selective, you just happen to have a
>business which archives USENET.  However there are two problems with
>this: a) volume -- USENET daily volume is huge; b) the censors will
>ask you to remove articles they object to from the archive.

News spool services are already showing signs of getting into this "Usenet
censorship" business in a bigger way. Some news spool services honor
cancellations (and some don't).  Some don't carry the "sensitive"
newsgroups. And so on. Nothing in their setup really exempts them from
child porn prosecutions--no more so than a bookstore or video store is
exempted, as the various busts of bookstores and whatnot show, including
the "Tin Drum" video rental case in Oklahoma City.


>The solution I am using is to keep reposting articles via remailers.
>Have agents which you pay to repost.  This presents the illusion of

This of course doesn't scale at all well. It is semi-OK for a tiny, sparse
set of reposted items, but fails utterly for larger database sets. (If and
when Adam's reposted volumes begin to get significant, he will be viewed as
a spammer. :-) )

>> - CD-ROMS made of Eternity files and then sold or distributed widely
>
>This is an interesting suggestion, but surely would open the
>distributor up for liability, especially if copyright software were
>amongst the documents.  Were you thinking of
>

The CD-ROM distribution is just a side aspect, to get some set of data
widely dispersed. For example, if the data base is of "abortion" or
"euthanasia" information (a la Hemlock Society), which various parties want
suppressed, then handing out freebie CD-ROMs is one step.

Many examples of this: Samizdats in Russia, crypto/PGP diskettes handed out
at conferences (was Ray Arachelian doing this several years ago?), and
various religious and social tracts. Obviously, this is what broadsheets
and fliers are designed to do. Self-publishing in general.

If the intent is to collect money for the data base accesses, then of
course other considerations come into play.

(Critical to these "Eternity" things is a good model of the customers, the
reasons for the data, etc.)



>> - purely cyberspatial locations, with no know nexus
>>
>> (I point to my own "BlackNet" experiment as one approach.)
>
>This is the best option.  Make it entirely distributed, so there is no
>nexus, period.  cyberspacial -> meatspace mappings are often easier to
>trace than we would wish, especially where there is continued usage
>(for example there are various active attacks which can make progress
>even against mixmaster remailers).  This is the weak point of my
>reposting agent, be that human, or automated.

My model, contained in the actual working software (*), allowed customers
to pick some topic, enclose a public key and payment, use a remailer to
post, then collect the information some time later. Using Usenet, but not
by reposting the actual data. Only pointers.

(* I say "working" in the sense that the concept was very easy to
demonstrate just by using PGP and remailers. Not much more than what I
demonstrated in 1993 would be needed to deploy a real system. Except for
one thing: true digital cash. Not the bullshit one-way-traceable stuff that
Chaum and others are now pushing, but the original, online-cleared or
escrow-cleared form, a la the work of Goldberg et. al. For some of these
applications, below, simple token- or coupon-based schemes might work
adequately.)

How these models will work using existing infrastructure (Usenet,
remailers, Web proxies, etc.) depends on some factors. It might be useful
to consider some benchmark applications, such as:

1. Anonymous purchase of financially important data. (A good example being
the Arbitron ratings for radio markets...subscription to Arbitron is quite
expensive, and posting of results on Usenet is prosecuted by Arbitron. A
good example of a BlackNet market.)

2. Anonymous purchase of long articles, e.g., encycopedia results...

(I'm not sure there's still a market for this....)

3. Anonymous purchase of "term papers." (A thriving market for ghostwritten
articles...already migrating to the Web, but lacking adequate anonymizing
methods.)

This is an example of a very large data base (all term papers on file)
which cannot possibly by distributed feasibly by Usenet.

And so on...lots of various examples.

The whole Eternity thing is interesting, but we haven't made a lot of
progress, it seems to me. (I distributed a proposal a bit similar to what
Ross Anderson was proposing, a proposal more oriented toward making a
_persistent_ Web URL for academics and lawyers to reliably cite, with less
of the "404--File Not Found" sorts of messages, the things which make the
Web largely unusable for academic and scientific citations.)


>> It is also likely in the extreme that a working Eternity service will
>> quickly be hit with attackers of various sorts who want to test the limits
>> of the service, or who want such services shut down.
>
>I agree with this prediction.  Remailers have seen this pattern, with
>`baiting' of operators, and apparently people posting controversial
>materials and reporting the materials to the SPA or others themselves,
>etc.

Yep, it's hard to disagree with this. Any centralized "Eternity service"
will be hit with various kinds of attacks in quick order.

Building a data base, as Ryan comments seem to indicate he is mostly
interested in doing, is the least of the concerns.

--Tim May

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."

Tim May wrote:
> At 3:06 PM -0800 1/11/98, Adam Back wrote:

> News spool services are already showing signs of getting into this "Usenet
> censorship" business in a bigger way. Some news spool services honor
> cancellations (and some don't).  Some don't carry the "sensitive"
> newsgroups. And so on. Nothing in their setup really exempts them from
> child porn prosecutions--no more so than a bookstore or video store is
> exempted, as the various busts of bookstores and whatnot show, including
> the "Tin Drum" video rental case in Oklahoma City.

There is no market-based reason for a general-purpose news server to store a 
file once it is known it is illegal or even offensive and someone puts any 
serious
amount of pressure on them.  You end up needing to steganographically protect
your data in the usenet stream, yet then you have to resort to security through
obscurity, which royally sucks if you have published source :)  You could use
some kind of cryptographically steganographically protected data, such that
you need a secret key to know stegoed data exists, but then knowing which 
files to
extract becomes a pain -- your server needs to try to extract on *everything*. 
 True,
this also solves part of the TA problem (while making the other parts far 
worse) :)

But it really hammers the servers, and makes it unlikely they'll continue to 
let you access
them.  You could then foil this by using a bunch of tentacles to pull in data, 
but this
increases complexity and security vulnerability.  
> 
> 
> >The solution I am using is to keep reposting articles via remailers.
> >Have agents which you pay to repost.  This presents the illusion of
> 
> This of course doesn't scale at all well. It is semi-OK for a tiny, sparse
> set of reposted items, but fails utterly for larger database sets. (If and
> when Adam's reposted volumes begin to get significant, he will be viewed as
> a spammer. :-) )

Yes.  This (and the URN issue) was one of the initial reasons why I doubted the
functionality of his Eternity implementation if it ever became popular.  One 
of MIT's
news admins was actually vehemently opposed to this "abuse of usenet", and 
implied he
would go out of his way to not carry such articles.

E-DDS should scale well because everyone involved is trying to make a profit.
> 
> >> - CD-ROMS made of Eternity files and then sold or distributed widely
> >
> >This is an interesting suggestion, but surely would open the
> >distributor up for liability, especially if copyright software were
> >amongst the documents.  Were you thinking of
> >
> 
> The CD-ROM distribution is just a side aspect, to get some set of data
> widely dispersed. For example, if the data base is of "abortion" or
> "euthanasia" information (a la Hemlock Society), which various parties want
> suppressed, then handing out freebie CD-ROMs is one step.
> 
> Many examples of this: Samizdats in Russia, crypto/PGP diskettes handed out
> at conferences (was Ray Arachelian doing this several years ago?), and
> various religious and social tracts. Obviously, this is what broadsheets
> and fliers are designed to do. Self-publishing in general.
> 
> If the intent is to collect money for the data base accesses, then of
> course other considerations come into play.
> 
> (Critical to these "Eternity" things is a good model of the customers, the
> reasons for the data, etc.)

My implementation allows flexibility -- someone pays for every scarce 
resource, yes, but
it does not have to always be the same person.  There will hopefully evolve to 
be people
willing to speculate in data, storing it for free in exchange for a cut, 
others willing
to pay the cost of putting their own data up and making access free up to a 
certain point,
etc.

I like CD-ROM distribution.  My discman carried munitions, as well as music, 
recently,
on the same disc.
> 
> (* I say "working" in the sense that the concept was very easy to
> demonstrate just by using PGP and remailers. Not much more than what I
> demonstrated in 1993 would be needed to deploy a real system. Except for
> one thing: true digital cash. Not the bullshit one-way-traceable stuff that
> Chaum and others are now pushing, but the original, online-cleared or
> escrow-cleared form, a la the work of Goldberg et. al. For some of these
> applications, below, simple token- or coupon-based schemes might work
> adequately.)

There are currently-under-development systems which will meet the digital cash 
requirement,
from people who I consider highly respectable and competent.

Yes, blacknet is a perfect model of a distributed high-latency system.  
However,
to get a system which will actually be useful to end users requires quite a 
bit more than
just storing data -- services like reporting on the reliability of data, 
allowing
easy access to data by third parties, etc. are all pretty essential.  
Cypherpunks
may find blacknet highly useful, but most end users want something that works
like the web, or like a database, which is the primary advantage of the current
"Eternity" systems.
> 
> How these models will work using existing infrastructure (Usenet,
> remailers, Web proxies, etc.) depends on some factors. It might be useful
> to consider some benchmark applications, such as:
> 
> 1. Anonymous purchase of financially important data. (A good example being
> the Arbitron ratings for radio markets...subscription to Arbitron is quite
> expensive, and posting of results on Usenet is prosecuted by Arbitron. A
> good example of a BlackNet market.)
> 
> 2. Anonymous purchase of long articles, e.g., encycopedia results...
> 
> (I'm not sure there's still a market for this....)
> 
> 3. Anonymous purchase of "term papers." (A thriving market for ghostwritten
> articles...already migrating to the Web, but lacking adequate anonymizing
> methods.)
> 
> This is an example of a very large data base (all term papers on file)
> which cannot possibly by distributed feasibly by Usenet.
> 
> And so on...lots of various examples.
> 
> The whole Eternity thing is interesting, but we haven't made a lot of
> progress, it seems to me. (I distributed a proposal a bit similar to what
> Ross Anderson was proposing, a proposal more oriented toward making a
> _persistent_ Web URL for academics and lawyers to reliably cite, with less
> of the "404--File Not Found" sorts of messages, the things which make the
> Web largely unusable for academic and scientific citations.)

Yes, having a persistent URN is highly useful.  Adam's implementation kind of 
solves
this, and I have not yet come up with a solution to it -- it would be easy to
do a pretty simple persistent URL, but having something which would allow
indexing to be something other than a web-search-engine style kludge is more 
difficult.
I've been reading some papers on the topic.
> 
> 
> >> It is also likely in the extreme that a working Eternity service will
> >> quickly be hit with attackers of various sorts who want to test the limits
> >> of the service, or who want such services shut down.
> >
> >I agree with this prediction.  Remailers have seen this pattern, with
> >`baiting' of operators, and apparently people posting controversial
> >materials and reporting the materials to the SPA or others themselves,
> >etc.
> 
> Yep, it's hard to disagree with this. Any centralized "Eternity service"
> will be hit with various kinds of attacks in quick order.
> 
> Building a data base, as Ryan comments seem to indicate he is mostly
> interested in doing, is the least of the concerns.

I think perhaps this is inaccurate.  I am interested in being able to subsume 
the
functionality of a database for some applications, but I'm trying to build 
something
more like a distributed active agents system.  A database implies a single 
central
design -- this would be more a medium in which people could place databases, 
agents, etc.
> 
> --Tim May
> 
> 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/

On Mon, 12 Jan 1998, Ryan Lackey wrote:
[quoting Tim]
> 
> > (* I say "working" in the sense that the concept was very easy to
> > demonstrate just by using PGP and remailers. Not much more than what I
> > demonstrated in 1993 would be needed to deploy a real system. Except for
> > one thing: true digital cash. Not the bullshit one-way-traceable stuff that
> > Chaum and others are now pushing, but the original, online-cleared or
> > escrow-cleared form, a la the work of Goldberg et. al. For some of these
> > applications, below, simple token- or coupon-based schemes might work
> > adequately.)
> 
> There are currently-under-development systems which will meet the digital cash 
> requirement,
> from people who I consider highly respectable and competent.

And the demand for such ecash systems is real. I personally carried a $10
million offer for a non-exclusive license for the blind signature patent
to David Chaum. He declined the offer. "The patent is not for license". 
DigiCash's CEO since March of last year, Mike Nash, also told me that
DigiCash was not considering licensing the patent. I knew that day that it
was time to quit. Not surprisingly, nobody heard from DigiCash since. 

-- Lucky Green <shamrock@cypherpunks.to> PGP v5 encrypted email preferred.
   "Tonga? Where the hell is Tonga? They have Cypherpunks there?"

Lucky Green <shamrock@cypherpunks.to> wrote:

> And the demand for such ecash systems is real. I personally carried a $10
> million offer for a non-exclusive license for the blind signature patent
> to David Chaum. He declined the offer. "The patent is not for license".
> DigiCash's CEO since March of last year, Mike Nash, also told me that
> DigiCash was not considering licensing the patent. I knew that day that it
> was time to quit. Not surprisingly, nobody heard from DigiCash since.

You could challenge the patent, and probably win, for less than $10
million.  There is quite a bit of prior art that Chaum neglected to
disclose, especially a certain incident where Chaum, as editor of
Crypto '84 proceedings, tried to supress part of ElGamal's paper which
discussed 'signature conversion' (aka blind signatures).

Tim May <tcmay@got.net> writes:
> News spool services are already showing signs of getting into this "Usenet
> censorship" business in a bigger way. Some news spool services honor
> cancellations (and some don't).  Some don't carry the "sensitive"
> newsgroups. And so on. Nothing in their setup really exempts them from
> child porn prosecutions--no more so than a bookstore or video store is
> exempted, as the various busts of bookstores and whatnot show, including
> the "Tin Drum" video rental case in Oklahoma City.

One tactic which could protect a USENET newsgroup operator from child
porn prosecutions is if he had no practical way to recognize such
materials until after it was distributed to down stream sites.

Using steganography, we could for example adopt a strategy such as
this:

1) Cross-post, and / or post to random newsgroups 

2) Threshold secret split your posts so that only N of M are required
   to reconstruct.

3) steganographically encode the eternity traffic.  Pornographic images
   in alt.binaries.* would be suitable because there are lots of those
   already.  

4) Encrypt the original steganographically encoded posting (encrypt
   the eternity document and hide it inside the image file posted)

5) Post the decryption key a day or two later to ensure we get the full
   feed before a censor can recognize the traffic

The attacker is now forced to delay USENET posts until the key is
posted if he wishes to censor eternity articles.

Measures 1) and 2) address the problems with newsgroups not being
carried everywhere.  2) improves reliability as distribution can be
patchy.

Cancellations can be discouraged by liberal abuse of cancellation
forgeries, which a Dimitri Vulis aided greatly by providing easy to
use cancel bot software.

A worrying trend is the use of NoCeMs to filter whole news feeds,
where the NoCeM rating system I considered was designed for third
party ratings applied by individuals.  NoCeMs could become a negative
if used in this way, because news admins may use them as a tool to
censor large parts of the USENET distribution, in too centralised a
way.

> >The solution I am using is to keep reposting articles via remailers.
> >Have agents which you pay to repost.  This presents the illusion of
> 
> This of course doesn't scale at all well. It is semi-OK for a tiny, sparse
> set of reposted items, but fails utterly for larger database sets. (If and
> when Adam's reposted volumes begin to get significant, he will be viewed as
> a spammer. :-) )

The best criticism of my eternity design to date!  I agree.

But this limitation is difficult to avoid while retaining the level of
availability.  Trade offs improving efficiency will tend to move away
from an existing widespread broadcast medium (USENET) towards
specialised protocols, and pull technology (the web hosting model),
leading to actual machines serving materials.

We can probably arrange that these servers do not know what they are
serving, however if the whole protocol is setup specifically for the
purpose of building an eternity service, it will be shut down.

Longer term perhaps something could be achieved in slowly building up
to larger numbers of servers, but this does not seem such a
main-stream service that it would be easy to get this degree of
uptake.

That is to say this problem is more than designing protocols which
would be resilient _if_ they were installed on 10,000 servers around
the world; the problem is as much to do with coming up with a
plausible plan to deploy those servers.

Adam

At 6:46 PM -0800 1/12/98, Adam Back wrote:

>One tactic which could protect a USENET newsgroup operator from child
>porn prosecutions is if he had no practical way to recognize such
>materials until after it was distributed to down stream sites.

Who are these "USENET newsgroup operators," anyway? (A few newsgroups are
moderated, by individuals or committees, but the vast majority are not.)

Newsgroups get removed from university and corporate newsfeeds, or by
nations, and Adam's ruse would not stop them from continuing to do so.


>> >The solution I am using is to keep reposting articles via remailers.
>> >Have agents which you pay to repost.  This presents the illusion of
>>
>> This of course doesn't scale at all well. It is semi-OK for a tiny, sparse
>> set of reposted items, but fails utterly for larger database sets. (If and
>> when Adam's reposted volumes begin to get significant, he will be viewed as
>> a spammer. :-) )
>
>The best criticism of my eternity design to date!  I agree.

I assume you are serious, and do agree, as it is a very solid criticism of
the "Eternity as continuous posting to Usenet" model.

I see several axes to the analysis of the various Eternity schemes.

-- retrieval time for a customer or client to obtain some set of data,
ranging from (I assume) ~minutes or less in an Eternity DDS file system to
~days or less in a Blacknet system to (I am guessing) ~weeks or months in
an Adam Back sort of system.

(Given constraints on Usenet in existence today. Technological and
political constraints in how many gigabytes will be sent. The binaries
groups are already overloading many systems, of course.)

-- bandwidth consumed in the system

-- number of nodes

-- security

(I have my own biases, and will elaborate when I get some time to put my
thoughts together.)


--Tim May

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."

Adam Back <aba@dcs.ex.ac.uk> wrote:

> Unfortunately good quality textual steganography encodings are I think a
> hard problem for reasonable data rates.  One advantage in our favour is the
> massively noisy and incoherent garbage which forms the majority of USENET
> traffic.  Plausibly mimicing an alt.2600 or warez d00d message, or a
> `cascade' seems like an easier target.

yA, d00d, i g0tz yEr stEg0 dAtA eNcOded r1gh+ h3re... ;-)

Tim May <tcmay@got.net>
> At 6:46 PM -0800 1/12/98, Adam Back wrote:
> >One tactic which could protect a USENET newsgroup operator from child
> >porn prosecutions is if he had no practical way to recognize such
> >materials until after it was distributed to down stream sites.
> 
> Who are these "USENET newsgroup operators," anyway? (A few newsgroups are
> moderated, by individuals or committees, but the vast majority are not.)

I meant USENET site operators (so that would be administrators plus
the people who decide policy).  

Even moderation need not be a fatal problem with steganography, if we
post the key to decrypt the stego encoded message after the article
has had a chance to be distributed.  (And presuming that our mimic
function is good enough to fool the moderator.)

For unmoderated groups, we have a much easier task: that of avoiding
undue attention or cancellations until the message has propagated.

> Newsgroups get removed from university and corporate newsfeeds, or by
> nations, and Adam's ruse would not stop them from continuing to do so.

In the extreme we can try to use mimic functions to post textual
information seemingly on charter for whatever groups are remaining at
a given time.  Binary data is obviously much easier to hide data in,
but is in any case a natural target for omitting from feeds due to
volume.

Unfortunately good quality textual steganography encodings are I think a
hard problem for reasonable data rates.  One advantage in our favour is the
massively noisy and incoherent garbage which forms the majority of USENET
traffic.  Plausibly mimicing an alt.2600 or warez d00d message, or a
`cascade' seems like an easier target.

Adam

On Sun, 11 Jan 1998, Tim May wrote:

> The CD-ROM distribution is just a side aspect, to get some set of data
> widely dispersed. For example, if the data base is of "abortion" or
> "euthanasia" information (a la Hemlock Society), which various parties want
> suppressed, then handing out freebie CD-ROMs is one step.
> 
> Many examples of this: Samizdats in Russia, crypto/PGP diskettes handed out
> at conferences (was Ray Arachelian doing this several years ago?), and
> various religious and social tracts. Obviously, this is what broadsheets
> and fliers are designed to do. Self-publishing in general.

Yep.  I gave them out at trade shows such as PC Expo.  What I found best
was to dump a stack of them on a common table area.  These expos usually
do have public machines for users to login and check email (horrible idea 
in  terms of security!), or surf.  CD's would be better suited for this
of course.

Another idea is to include hidden archives or pieces of archives in the
stuff we distribute.  Have you signature be a piece of a big archives and
post different pieces daily.  If you write shareware, etc. include
inactive files with the distribution, perhaps stegoing pieces in any
images (setup screens, logos, etc...)

> If the intent is to collect money for the data base accesses, then of
> course other considerations come into play.

You could always give the media away then charge a fee for unlocking it.
Many companies already do this.  (see www.warehouse.com and go to download
warehouse from there.)  You can download a package which is unlocked only
when you give them a credit card number.  The unlocking key is RSA
based...

There are also spam based free web sites out there where anyone can get a
web page if they agree to have the provider provide a spam bar ad.  You
could easily get dozens of these on various providers and hide bits of the
info there.

> (* I say "working" in the sense that the concept was very easy to
> demonstrate just by using PGP and remailers. Not much more than what I
> demonstrated in 1993 would be needed to deploy a real system. Except for
> one thing: true digital cash. Not the bullshit one-way-traceable stuff that
> Chaum and others are now pushing, but the original, online-cleared or
> escrow-cleared form, a la the work of Goldberg et. al. For some of these
> applications, below, simple token- or coupon-based schemes might work
> adequately.)

For that to happen, alternate banks must exist first, or at least
alternate ecconomies with some way to translate inbetween.  I doubt many
governments will allow this.  Heck, our city government is taking to
ticketing jaywalkers now, if they're getting this vicious on the city
level, think at the Fed level they'll let this happen?

Perhaps something like a swiss bank might be able/willing to do the
exchange.
 
> Yep, it's hard to disagree with this. Any centralized "Eternity service"
> will be hit with various kinds of attacks in quick order.

The biggest problem to this will be the 'let kiddies posting whole CDROMS
of pirated stuff to the sites, this will certainly eat up all the space on
the servers and make them more liable to raids.
 
Heck, if the kiddies don't take to this, the spooks will pretend to be
kiddies and do the same.

The biggest problem though will be replicating the haven throughout the
world so that the whole haven will be at a point where it can't be easily
shut down, even if one or two go down.

How many servers do we have so far?


=====================================Kaos=Keraunos=Kybernetos==============
.+.^.+.|  Ray Arachelian    |Prying open my 3rd eye.  So good to see |./|\.
..\|/..|sunder@sundernet.com|you once again. I thought you were      |/\|/\
<--*-->| ------------------ |hiding, and you thought that I had run  |\/|\/
../|\..| "A toast to Odin,  |away chasing the tail of dogma. I opened|.\|/.
.+.v.+.|God of screwdrivers"|my eye and there we were....            |.....
======================= http://www.sundernet.com ==========================

At 3:35 PM -0800 1/11/98, David Miller wrote:

>There is one thing that comes to mind that was just a topic covered on
>this
>list and that is the use of cellular/wireless/RF/ham for connections to
>said machines.
>
>Obviously, this would make seizure more difficult (and perhaps increase
>the
>likelyhood of prior warning, if for example, cellular service was
>suddenly
>cut off).

In terms of "work factor," such connections are nearly worthless. They
might be a bit harder to trap or trace than typical connections, but they
are only "security through obscurity" compared to the effort to break a
typical cipher.

(Put another way, would you feel safe hosting a child porn site just
because some of the links were over ham radio or the like? I wouldn't. I'd
be waiting for the FCC vans to triangulate....or for the cellphone
companies to "cooperate," as they so often have.)


--Tim May


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."

Tim May wrote:
 
> In terms of "work factor," such connections are nearly worthless. They
> might be a bit harder to trap or trace than typical connections, but they
> are only "security through obscurity" compared to the effort to break a
> typical cipher.

Even if the signals can be distributed on par with the distribution
of the data itself?  Could this be a 'meta' application that has not
been
considered?  Perhaps not, because sigint analysis normally increases an
attacker's intelligence on the subject and doesn't decrease it.

> (Put another way, would you feel safe hosting a child porn site just
> because some of the links were over ham radio or the like? I wouldn't. I'd
> be waiting for the FCC vans to triangulate....or for the cellphone
> companies to "cooperate," as they so often have.)

No, I wouldn't either.  Your point here indicates that whereas
historically
privacy was increased through movement, the reverse may be true now or
at least at some future date.  Namely, that entities are (or will be)
tracked by their movement and not simply location.

--David Miller

middle  rival
devil rim lad

Windows '95 -- a dirty, two-bit operating system.

Tim May wrote:

> At 3:06 PM -0800 1/11/98, Adam Back wrote:
>
> >Archiving USENET as a separable enterprise which charges for access
> >(altavista for example charges via advertisements) seems less
> >problematic than directly trying to build a database of controversial
> >materials.  Archiving it all partly reduces your liability I think,
> >because you are not being selective, you just happen to have a
> >business which archives USENET.  However there are two problems with
> >this: a) volume -- USENET daily volume is huge; b) the censors will
> >ask you to remove articles they object to from the archive.
>
> News spool services are already showing signs of getting into this "Usenet
> censorship" business in a bigger way. Some news spool services honor
> cancellations (and some don't).  Some don't carry the "sensitive"
> newsgroups. And so on. Nothing in their setup really exempts them from
> child porn prosecutions--no more so than a bookstore or video store is
> exempted, as the various busts of bookstores and whatnot show, including
> the "Tin Drum" video rental case in Oklahoma City.
>
> >The solution I am using is to keep reposting articles via remailers.
> >Have agents which you pay to repost.  This presents the illusion of
>
> This of course doesn't scale at all well. It is semi-OK for a tiny, sparse
> set of reposted items, but fails utterly for larger database sets. (If and
> when Adam's reposted volumes begin to get significant, he will be viewed as
> a spammer. :-) )
>
> >> - CD-ROMS made of Eternity files and then sold or distributed widely
> >
> >This is an interesting suggestion, but surely would open the
> >distributor up for liability, especially if copyright software were
> >amongst the documents.  Were you thinking of
> >
>
> The CD-ROM distribution is just a side aspect, to get some set of data
> widely dispersed. For example, if the data base is of "abortion" or
> "euthanasia" information (a la Hemlock Society), which various parties want
> suppressed, then handing out freebie CD-ROMs is one step.
>
> Many examples of this: Samizdats in Russia, crypto/PGP diskettes handed out
> at conferences (was Ray Arachelian doing this several years ago?), and
> various religious and social tracts. Obviously, this is what broadsheets
> and fliers are designed to do. Self-publishing in general.
>
> If the intent is to collect money for the data base accesses, then of
> course other considerations come into play.
>
> (Critical to these "Eternity" things is a good model of the customers, the
> reasons for the data, etc.)
>
> >> - purely cyberspatial locations, with no know nexus
> >>
> >> (I point to my own "BlackNet" experiment as one approach.)
> >
> >This is the best option.  Make it entirely distributed, so there is no
> >nexus, period.  cyberspacial -> meatspace mappings are often easier to
> >trace than we would wish, especially where there is continued usage
> >(for example there are various active attacks which can make progress
> >even against mixmaster remailers).  This is the weak point of my
> >reposting agent, be that human, or automated.
>
> My model, contained in the actual working software (*), allowed customers
> to pick some topic, enclose a public key and payment, use a remailer to
> post, then collect the information some time later. Using Usenet, but not
> by reposting the actual data. Only pointers.
>
> (* I say "working" in the sense that the concept was very easy to
> demonstrate just by using PGP and remailers. Not much more than what I
> demonstrated in 1993 would be needed to deploy a real system. Except for
> one thing: true digital cash. Not the bullshit one-way-traceable stuff that
> Chaum and others are now pushing, but the original, online-cleared or
> escrow-cleared form, a la the work of Goldberg et. al. For some of these
> applications, below, simple token- or coupon-based schemes might work
> adequately.)
>
> How these models will work using existing infrastructure (Usenet,
> remailers, Web proxies, etc.) depends on some factors. It might be useful
> to consider some benchmark applications, such as:
>
> 1. Anonymous purchase of financially important data. (A good example being
> the Arbitron ratings for radio markets...subscription to Arbitron is quite
> expensive, and posting of results on Usenet is prosecuted by Arbitron. A
> good example of a BlackNet market.)
>
> 2. Anonymous purchase of long articles, e.g., encycopedia results...
>
> (I'm not sure there's still a market for this....)
>
> 3. Anonymous purchase of "term papers." (A thriving market for ghostwritten
> articles...already migrating to the Web, but lacking adequate anonymizing
> methods.)
>
> This is an example of a very large data base (all term papers on file)
> which cannot possibly by distributed feasibly by Usenet.
>
> And so on...lots of various examples.
>
> The whole Eternity thing is interesting, but we haven't made a lot of
> progress, it seems to me. (I distributed a proposal a bit similar to what
> Ross Anderson was proposing, a proposal more oriented toward making a
> _persistent_ Web URL for academics and lawyers to reliably cite, with less
> of the "404--File Not Found" sorts of messages, the things which make the
> Web largely unusable for academic and scientific citations.)
>
> >> It is also likely in the extreme that a working Eternity service will
> >> quickly be hit with attackers of various sorts who want to test the limits
> >> of the service, or who want such services shut down.
> >
> >I agree with this prediction.  Remailers have seen this pattern, with
> >`baiting' of operators, and apparently people posting controversial
> >materials and reporting the materials to the SPA or others themselves,
> >etc.
>
> Yep, it's hard to disagree with this. Any centralized "Eternity service"
> will be hit with various kinds of attacks in quick order.
>
> Building a data base, as Ryan comments seem to indicate he is mostly
> interested in doing, is the least of the concerns.
>
> --Tim May
>
> 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."



Please remove me from the mailing list.

Thanks

-----BEGIN PGP SIGNED MESSAGE-----


> 
> I haven't been following the latest round of "Eternity" discussions. I
> gather that Ryan's efforts are distinct from Adam Back's efforts, which are
> themselves distinct from the seminal Ross Anderson researches (for example,
> at http://www.cl.cam.ac.uk/users/rja14/eternity/node4.html).

Yes, all three efforts are distinct at present.  My "secret" plan is to try
to get a technical design document and demo which are so compelling that
in the end it merges into one Eternity project, though :)

> 
> But Ryan's comments leave me with some questions:
> 
> 
> At 3:11 AM -0800 1/11/98, Ryan Lackey wrote:
> 
> >If I find investors/customers/etc. by March-July 98 for Eternity DDS, though,
> >I'm planning to buy 8 DEC AlphaPC motherboards with dual 21264 processors.
> >Some pieces of Eternity DDS are now being implemented in Oracle for
> >speed of implementation reasons, and other pieces are being prototyped
> >in Scheme (maybe), so even my K6 is getting hammered.  Plus, I'm now testing
> 
> Will these be located in the U.S.? Will their locations be publicized? Will
> any offshore (non-U.S.) locations be publicized?

Hopefully I can allay your fears.

I want the alphas for testing and compiling during the not-yet-production
phase.  They'll be located in one place, subject to being shut down legally
or extralegally.  However, there will be no production data on them, so
there will be no reason to shut them down.  To attack them preemptively would
be less efficient than simply killing the maybe 20 people in the world
who are involved with Eternity development.

I want to have a cluster of machines on which to simulate a working eternity 
system.  I'm trying to develop interconnect protocols which scale to a large 
number of users with the minimum possible trust, no particularly vulnerable
points, etc.  Even me personally owning any substantial amount of machines
involved in a production Eternity implementation while living in the US would
be risky -- I want people to be able to continue to use Eternity even if I
turn out to be a secret NSA agent bent on world domination.  

> [vulnerability of any identified servers]

To this I add the threat of illegal action by enemies of users of the system, 
government or otherwise.  As a result, having *any* of the nodes be locatable
on a network or in physical space is a threat.  Knowing the IP addresses of
all the Eternity servers in the world would be enough to let you flood
them out of existence.

Unfortunately, in order for Eternity to be accessible to the world in some
way, some nodes need to have public logical addresses in some way.  This
opens up a bunch of pathways to attack.

Eternity DDS has market-based protocols to try to hinder these attacks.

> So, the talk about the hardware of all these Alpha servers raises some
> interesting questions.
> 
> I would have thought that a much more robust (against the attacks above)
> system would involve:
> 
> - nodes scattered amongst many countries, a la remailers
> 
> - no known publicized nexus (less bait for lawyers,  prosecutors, etc.)
> 
> - changeable nodes, again, a la remailers
> 
> - smaller and cheaper nodes, rather than expensive workstation-class nodes
> 
> - CD-ROMS made of Eternity files and then sold or distributed widely
> 
> - purely cyberspatial locations, with no know nexus
> 
> (I point to my own "BlackNet" experiment as one approach.)

Yes, that's effectively what I'm trying to do.  Eternity DDS is currently
being developed on the "Athena model" as a bunch of interoperating services
with general utility as well.

During testing, I'm using stuff like Oracle to prototype large sections of the
application.  I've run hundreds of clients off my K6 talking to a couple of 
servers
on my K6.  This does not mean that the production system will involve my k6 in
any way, except perhaps as my client.

I think that Eternity is effectively a massive distributed database, in that a 
filesystem
is a kind of database.  I also think selling just storage is kind of silly -- 
one needs
to take into account bandwidth and computation as well, in order to allow 
people to
do truly interesting things.  With a sufficiently trusted JVM, one could 
execute some subset
of java code remotely fairly securely.  I'm planning to have interfaces to the 
Eternityspace
which make it look like a massive web server, a massive traditional database 
server, a filesystem,
ftp, email server, etc.  This helps functionality and security.

The design is a compromise between security and efficiency.  In many cases 
being
distributed is good for both, but in at least two areas, trying to make E-DDS 
distributed is making it less efficient.  I forsee that the initial limited
production system will have a nexus in that the auction market will probably
be run by my organization through a geographically-dispersed network of 
machines
with byzantine fault tolerance.  I also forsee an initial small number of nodes
interfacing Eternity DDS to the world (via the web, database protocols, 
filesystem
protocols, etc.).  While there will be encryption between those servers and 
their
clients, they will be targets for attack -- however, there are a bunch of 
techniques
for making them ephermeal, some of which you have mentioned.
> 
> It may be that the architectures/strategies being considered by Ryan
> Lackey, Adam Back, and others are robust against the attacks described
> above.

I hope so.
> 
> Basically, if the Eternity service(s) can be traced back to Ryan or Adam or
> anyone else, they WILL be subject to court orders telling them to produce
> certain files, telling them to cease and desist with regard to certain
> distributions, and so on. Even raids to carry off the entire file system
> for analysis will be likely.
> 

I hope to leave the country before Eternity DDS goes public.  I think raids
on US sites, or unprotected foreign sites, are highly likely, legal or 
otherwise.
I don't believe any government will provide any real defense for an identified
Eternity server or nexus or involved person, once it starts being used for
corporate espionage, money laundering, political activism, etc.  The only 
defense
is to make sure the collateral damage from taking it out is high enough that 
they
won't, like an inoperable tumor (a 10mm does a good job of removing most 
individual
cancer, but sometimes killing the patient is unacceptable)

Hopefully, the designers of the first production Eternity service can make 
themselves
irrelevant enough to not be worth killing, and/or difficult enough to kill 
that the
collateral damage from killing them would be unacceptable.

> It is also likely in the extreme that a working Eternity service will
> quickly be hit with attackers of various sorts who want to test the limits
> of the service, or who want such services shut down. Thus, expect all kinds
> of extremely controversial material to be posted....granted, this is a
> "reason" for such services, but see how long the system lasts when it
> contains child porn, Scientology secrets, lists of CIA agents in Europe,
> copies of Microsoft Office for download, and on and on.

Yes.  I'm designing for the worst.
> 
> And even a decentralized, replicated system will of course still expose the
> owner/operator in some jurisdiction to his local laws. (As Julf was exposed
> to the laws in his country, and that was just the tip of the iceberg.
 
I'm planning to move to the most laissez-faire location possible.  I also want
to make myself irrelevant once the system enters production (which does not
necessarily mean I won't try to get rich, just that if someone corrupts or
kills me it won't make any difference to the operation of the system).

> Eternity nodes must not be identifiable, and their locations must not be
> known. Anything else is just asking for major trouble.

I agree with you 100%.  There are technical considerations which come into play
defending eternity nodes from TA, other corrupt nodes, etc., but they are in 
the
main solvable.  The borders of the eternity logical network become exposed, 
but it
is possible to push those borders far enough out that it becomes the 
responsibilty of
other unwitting parties to shut them down.

My design goal is truly distributed and truly secure.  In order to take out 
eternity, I
hope to make it necessary for the attackers to take out the Internet, 
something even
overly communist regimes are unwilling to do.

I think Adam Back's Eternity implementation mostly meets the "lightweight nodes
which no one cares about" in theory, and if his assumption that usenet will not
be attacked is valid, it has met the "unacceptably high collateral damage"
criteria.  I'm somewhat unsure of that assumption, though.

Plus, the central difference between Eternity DDS and the other two Eternity
designs is that market forces will be used to give people an incentive to 
break the
law by running Eternity DDS servers secretly in Burma (both internal storage
nodes and throwaway interface nodes).  I think market forces are the only way 
to
get people to implement a large enough Eternity logical network to provide
protection from a concerted attack.

> 
> Comments?

More discussion would be great.  I think everyone agrees on the basic 
requirements
for Eternity implementation -- it's just a question of which compromises one 
must
make to technical expediency, as well as advanced technical methods one can use
to minimize those compromises.  

[Pseudo-ob-non-crypto: I apologize for sof.mit.edu's web server being dead for 
a while.  It
managed to wedge itself quite nicely, and I didn't find out about it until 
someone sent me
mail.  Again, I'm putting as much documentation as I can up on 
http://sof.mit.edu/eternity/]

- -- 
Ryan Lackey
rdl@mit.edu
http://mit.edu/rdl/		



-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQEVAwUBNLmM16wefxtEUY69AQGobAf/c8PleA2nc4a17HikOGbevX6l/hJzZCf1
ZwwSM2X9jT0Jbg3FhGBt4aj2mRSDDYA9C96StMl2tNZlIQf4PKtyIt2mysh4dO1L
OsmAgemdqh9oHSEHalSDasGURSdzWBCuMctgcwT2BA+zWmWNILo4pw8ePgH2Hc2e
tTmJpfrALMU2pOjkeQ3R6OPOVRPc4JRz/XpRLcFbwEy2DahVzc1ICjfdO7II/qhd
3UJtpxF+mKBrSLVfCINrkg6kXR2c9aL4bFBm5ZoINADH/sPSqghzgNRE9RLLpvqD
2bZmmzUUAgoTNhSEqHk0xl4VaRmVBf1JntetTmWBe1h2b7rh/Anr5w==
=0O/n
-----END PGP SIGNATURE-----