From: trestrab@GVSU.EDU (BETH TRESTRAIL)
Date: Sun, 23 Jan 94 21:08:29 PST
To: cypherpunks@toad.com
Subject: Remailers: The Next Generation
Message-ID: <9400237593.AA759398302@GVSU.EDU>
MIME-Version: 1.0
Content-Type: text/plain


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
trestrab@gvsu.edu