Hi Doug, Forwarded message:
From: "Douglas R. Floyd"
Subject: Some ideas Date: Sun, 28 Dec 1997 16:18:14 -0600 (CST)
I have been pondering this: To save on bandwidth, I wonder about having two types of OSS sites
OSS?
-- a "control" site which switchboards incoming/outgoing stuff to "data" sites.
Which needs to have access to at least *all* incoming requests for data as well as a channel to other switchboard sites so they can catalog those requests and won't have to look them up more than once, after that they simply use the request as a key to a index of sources.
This would help with distributing bandwidth load, and since "data" sites just store encrypted items, the "control" site can be made more secure.
I suspect all the traffic would need to be encrypted to get this to work well. The channels between the switchboards and the databanks also need to be encrypted in such a manner that it is transparent even to the operators what the keys are at any given time. Also, assuming the user provides a request to a switchboard, who then determines the correct server through some mechanism, contacts that databank server and requests a transmission, and finaly the databank server sends the data to the user. How do we track the various keys and verify that the user making the request is the user getting the data? Is the switchboard and databank servers simply tracking the key provided by the original request sufficient?
Another random thing is a way to build a CD-ROM jukebox that would automatically burn a CD when data meets the requirements of "valuable", and "offline". Then, when the data is needed again, its fished out and loaded.
What you need is a pick-and-place system. It would consist of a handling mechanism, a burning mechanism, a jukebox mechanism, and a CD storage mechanism. Personaly I wouldn't want them all in one in case any one broke down the rest of the system could still keep working. Valuable to who? For how long? Who pays for the stack of CD's up front? What kind of amortization schedule are we looking at for paybacks? Since we are looking at a automated system, what does 'offline' mean when the pick-and-place goes over to the rack and pulls the CD to place in the jukebox and it is now online? How do we charge the user?
Some type of IP encapsulation using public key encryption, so machine A that is talking to machine D would encapsulate the whole packet with machine D's key, C's key, and B's key. Then the packet is sent to box B, which decodes it, looks where to send it, then kicks it to C. C then looks at it, sends it to machine D. Basically a "remailer", where each packet is a message.
Is this feasable at all?
Yeah, mixmaster does something similar to this. The problem I have with
mixmaster is that the sender has to set up the chaining and keys and such.
There simply isn't a clear mechanism (as I understand mixmaster) to do this
transparently. One look at the chaining file that is required is enough to
explain why granny doesn't use chained mixmaster remailers.
Now if we want to do it in the protocol stack then we have a problem because
it isn't supported in the standard.
What I would do is a little different. An example...
Let's assume we have 4 remailers, A to D. The sender sends a packet to A
that's header is in the clear. Once A gets it, addressed to an appropriate
user to invoke the decryption process, it decrypts the body of the packet.
What it assumes is there is another valid packet with unencrypted header
which it passes on to B. B gets it and de-crypts it and passes it on. This
happens in C and D as well. At no point does any of the processes need to do
anything other than use its own key to decrypt. If that fails the packet is
trashed. Since no information about its previous source was passed to D from
C this failure won't propogate back up the chain, providing a measure of
source security. D takes the packet, whose body is still encrypted and
remails it to the next address in the header, in this example the actual
destination.
The issue for me is how do the remailers handle the pass-off. Here are a
few of the choices:
- the existing mechanism which is completely dependant on the user and
their technical skill. I don't like this one, too people intensive.
- the sender does it by reference to a key-server and automated chaining
software. The software would ask for a sequence of available remailers
from the user, go off to the key-server and get the appropriate keys,
and create the nested encrypted packets. Then it only has to send them
on their way. Still a tad too technical for granny I suspect.
- the sender provides a source destination and a number of remailers. The
software goes to the key-server, looks up the available remailers
(hopefuly there are more than the number requested by the sender) and
selects the appropriate number through some mechanism (PRNG is my
choice). It then creates the chained packet and sends it on its way.
I suspect granny could deal with this one, she knows how to count and
has sonnie's email address in her mailer software.
What I like about this is the key server represents a mechanism for income.
It would cost say $1/month to store your key on the server and then anyone
who made the request would get it. The key would automaticaly age and expire
if the user didn't keep paying the fee. Further, there would be no
distinction between remailers, users, or other processes as to the actual
key. It would consist of a list similar to: