Remailers and ecash (fwd)

[Anonymous]

Jim Choate:

>For the sender to chain from remailer to remailer to destination the
>destination has to be in the header info somewhere. Now in the most secure
>system each packet header will only contain the address of the next hop. When
>the next site gets it the packet contents are de-crypted (otherwise reading
>the chaining info is trivial) and the contents are uncovered to reveal another
>packet with the next hop header and another encrypted block. And on and on
>we go.
>
><Question: Are there any remailer sets that impliment the encrypted nested
>           packet system?>

Jim Choate has been amazingly clueless throughout this discussion, but
this takes the cake.  Does he really not know about encrypted nested
chaining?  My God!  Of course remailers work this way, Jim.  They've
worked this way practically from the beginning.  All remailers work this
way.  The mixmaster remailers are built around this idea, making each
packet a constant size and adding dummy packets as new ones are stripped
off, so outgoing messages look just like incoming ones.

How can you be arguing about remailers when you know so little about how
they work?

><speculation: an encrypted chain could be made stronger if the next
>              hop header depended on which key was used to decode it.
>              In other words, remailer A's key will produce one next hop
>              address while remailer B's key will send it elsewhere. This
>              is a subset of the different plaintext - same cyphertext
>              problem - a hard problem as I understand it. Find two
>              distinct texts that encrypt with different keys to the
>              same cyphertext>

That won't help.  There would be no point in doing this.  I'd ask you
to explain, but that would just prolong the agony.