[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Remailers: The Next Generation
Tim May writes concerning the need for "new and improved" cypherpunk
remailers: ( His comments in " " or after > )
>FEATURES NEEDED IN A SECOND GENERATION REMAILER:
>I. DIGITAL POSTAGE
Requests for remailing would be accompanied with some form of digi-cash
token, with the amount equalling (number of hops requested X price per
'stamp'). The remailers would keep the token that came with the message,
and substitute one equalling # stamps -1 that would be digitally signed
by it. This new token would be passed down the line, with each
remailer keeping the tokens that come in and substituting their own. The
tokens that are kept would be sent to a central remailer clearinghouse
which would settle accounts. (See * at bottom of msg for
further details on the clearinghouse.)
>II. JUNK MAIL SCREENING
I really don't know how best to accomplish this, either.
>III. IDEAL DIGITAL MIX
I'm not sure that we can achieve an 'ideal Chaumian digital mix' of messages
at this time, but I have a few ideas on how we can improve on what
is presently in place. Instead of padding individual messages to
improve diffusion, batch several messages together to reach some
'standard' remailer msg length of n bytes, and then encrypt the batch
with the next remailer's public key. Noone looking at the message as it
leaves the remailer will be able to determine what # of msgs are in the batch,
or which particular msgs are present (assuming they don't possess the
private key of the remailer to which the batch is being forwarded).
The individual msgs in a batch could be seperated with some standard
remailer command, e.g.
:: Cut here ------------
When the batch arrived at the next remailer, it would be decrypted and the
Individual msgs seperated and placed in the remailing queue.
Latency could be set by the customer with a command such as:
:: Hops = x, Final = Remailer Z [ where x =1-9, and Z = either the
remailer address or some alias that could be looked up in a table.
'Final' would be used in place of the nested encryption used now, so that the
msg sender would only have to encrypt the final destination of his msg once.
The # of Hops would be decremented by one as they were processed by
each remailer.
Remailers would send a msg to any other remailer randomly, except when
Hops = 1, and would then forward the msg to Remailer Z.
So I envision a typical msg looking like this:
a. The instructions for # of hops and final remailer hop
b. The instructions for final destination.
c. The msg itself.
c would be encrypted as the sender chooses, and then b + c would
be encrypted using the public key of remailer Z ( Z to be chosen by
the sender of the msg). a would be in the clear, or a+ b+ c could be
encrypted with the public key of the first hop in the remailer chain.
Of course, all of this ( a, b, and c ) could be done in the clear, but
that would place your msg is jeopardy at each and every hop of
being intercepted and read. That might be acceptable to some
users, though its not very robust.
Messages would be batched into groups by taking first m number of msgs
whose lengths add up to the standard length n. Diffusion could be
increased by shuffling the queue as each message entered the remailer.
Latency and diffusion could be increased by inserting "null" msgs into the
mix. A few months ago Eric Hughes mentioned that Hal Finney was
forwarding list msgs encrypted to some unkwon number of persons. If he is
still doing this, these msgs could be inserted into the mix by remailing each
msg to _one_ of the remailers in a random fashion. These msgs could
contain a command such as
:: Hops = {1-9}; Final = Dev.Null
They would be remailed within the remailer loop until Hops = 0, when they
would be sent to the bit bucket, having served their purpose.
> IV. NO LOGGING
The important part of this is that the policies of individual remailers should
be clear on this point, so that individuals can choose the initial and
final remailers if that policy is a concern to them. As Tim says:
" Sites which log but say they _don't_ is of course the real issue in the long
run....I'll save this interesting topic for another article, maybe. Just be
aware that this kind of "collusion" (not exactly, but this is what the
literature calls related behaviors) is not easily solved with existing
remailers.) "
>V. HARDWARE-BASED REMAILERS
No particular expertise here. I'll this to those that do.
>VI. MARKETS
I think it will work better if the routes are chosen randomly by the remailers
( except for final hop, see above ), as this process is more "user friendly".
"Pinging" could be centralised into one clearinghouse (*see below), which
handled settling of postage accounts between remailers.
>VII. STANDARD FORMATS
Needed, but to be decided upon. If noone else volunteers, I am willing to
host a moderated Cypherpunks sub-list whose topic would be limited to
remailers. Moderated, because I don't have the facilities to run an
automated mail reflector and so that the signal to noise ratio is kept high
enough that contributors don't drop out due to Detweiler or other
noise sources.
>VIII. RATINGS AGENCIES
I think that diversified sources of info for "consumers" of remailers is a
"good thing", but there should be a centralised clearinghouse which would
concern itself solely with reconciling postage accounts and with "pinging"
the remailer net at regular intervals and sending out msgs to remailers to
avoid sending packets to sites which are not responding in an appropriate
amount of time. ( "Appropriate" to de determined .)
>IX. DIVERSE SITES
Tim writes: "I also think we also need "virtual sites" which are themselves
only accessible by remailers." I agree.
"Other names for these sites might be "sacrificial sites" or "digital
cutouts" " This can be accomplished now using the commercial site
America On Line (AOL), which permits its customers to have a half-
dozen or so distinct sign-on names per account. So you could run a site
called "Remailer_17" (with apologies to Wm Holden) which received
msgs to be remailed. These msgs could be downloaded, processed, and
then uploaded through a different name entirely, "Fnord_OMF" or
whatever. Unless the <insert favorite bad guy organization here>
monitored _all_ possible alias accounts, they would not be able to do
traffic analysis on the remailer network.
>X. ATTEMPTS TO BREAK REMAILERS
I'll leave discussion of this to those with greater knowledge of hacking
and/or cracking than myself.
* CLEARINGHOUSE
The clearinghouse would not be accessible to users of remailers, but
would be internal to the remailer network and handle accounting and
"pinging" of remailers.
Accounting example:
I send a msg to remailer A, requesting # Hops = 3 and Final =
remailer C. I enclose at the top of the msg digi-cash equalling
the cost of three "stamps". ( One stamp for each hop.) Remailer
A keeps the original digi-cash token, and substitutes one signed
by it equalling two stamps. The msg is remailed to remailer B,
which keeps the token supplied by remailer A and substitutes
one signed by it equalling one stamp; remailer B notices that
the # Hops now = 1, so it remails the msg in a packet to remailer
C. Remailer C keeps B's token, and sustitutes nothing since
this is the final hop for this particular msg. It then decrypts the
msg and follows the remailing instructions encrypted in the
"envelope".
At the end of some accounting period ( day, week, month,
depending on number of msgs passing through the system )
all remailers would forward their accumulated tokens to the
clearinghouse, which would credit their accounts with the
tokens received and debit them for the tokens sent out. The
bookkeeping would get fucked up by lost transmissions, so
that would have to be addressed at some point to ensure that
remailers didn't just bit bucket incoming msgs and keep their
stamps.
The clearinghouse would also "ping" the remailers in the network
at regular intervals and issue "route around" commands to
the remailers if one or more sites didn't respond in a timely
fashion.
Thats all for now.
Jeff
[email protected]