Re: for-pay remailers and FV (Was Re: Remailer Abuse)

Excerpts from fv: 6-Jan-95 for-pay remailers and FV (W..
jrochkin@cs.oberlin.edu (4416*)

> Hmm. Maybe I don't completely understand how this is going to work, but
> won't _every_ remailer in the chain need to know your FV billing account?
> How would the rest of them charge via FV without knowing your billing
> account?  What Russell was suggesting (I think), was that only the first
> would bill via FV directly, so only the first would need to know your
> billing account, and then he'd settle up with the others at the end of the
> month. (A particular variation of that scheme is what you mentioned later
> in your message, and I'll get to that).

The latter is what I was proposing.  Only the first one would charge via
FV, but the other ones would form a "closed system" that you could only
get into by going through one that charged.

> But assuming that every remailer along the chain _was_ charging via FV, I
> fail to see how only the last one would need your billing account; seems to
> me they all would, and thus any one could collude with FV to violate your
> anonimity.

That's not my assumption.  I think you may have misread my mail -- I
*agree* with you on this point.  Sorry if I was unclear!

> The
> remailer operators still have to have an organization and remain in close
> contact, which I am uncomfortable with because it seems to make collusion
> more likely. 

As I said, it all depends on your level of paranoia....  I tend to think
that in such an organization, where the primary "product" is privacy,
each member would tend to watch all the other members like hawks, eager
to publicize any instance of the other guy not being sufficiently
zealous in protecting privacy.  (Of course, I'm assuming that people
like *you* will be running these services, i.e. people even more
paranoid about privacy than me.)

> And it's still dificult to intermix for-pay and free remailers
> within your chain, or even just for-pay remailers from several different
> consortiums. 

I think this is wrong.  In my model, each consortium model has two, a
for-pay and a for-free.  Anyone can send to a for-pay, but only a
consortium remailer can send to a for-free.  Not that complicated,
really.

>  [The
> consortium, as far as I can tell, would also find it rather dificult to
> charge more for a longer chain, I can't think of any way for them to charge
> anything excpet a uniform amount regardless of length of chain, unless you
> give the first remailer a way to tell the length of your chain, which is
> undesirable. I'm not sure if this is a problem.]

To my mind, that's not a bug, it's a feature.  The consortium is
charging you a set fee for privacy, and you get to decide how many hops
are required to have a level of privacy you trust.

> And this level of paranoia would be perfectly well surved by a Julf/penet
> style remailer, which _would_ work well with an FV-payment system, as I
> agreed before.  The cypherpunks chained remailernet system as a whole is
> overkill for your paranoia needs, but appearantly not for the needs of
> those who use it over Julf's.  It appears to me, that an FV-style payment
> scheme can't be added to the cypherpunks chained remailer system without
> dropping it's security to the level of Julf's.  Which might be good enough
> for you, but not good enough for me, or presumably for anyone else that
> uses cypherpunks remailers.

This is true of the scheme that I said I would be satisfied with (one
remailer + FV), but not true, I think, of the "overkill" scheme, which
was the consortium.

> [Do you understand how cypherpunks remailers work, and the difference
> between them and a julf/penet style remailer?   Do you understand how
> encryption is used in a cypherpunks-style remailer chain to make it so each
> individual remailer only knows the next remailer along the chain, and not
> the entire rest of the chain?]

Well, I *think* I do, though I may be suffering from a bit of
dilletantism here -- I'm certainly no expert in cryptography, but I
think I understand the concepts involved.  We haven't even gotten into
the effect of encryption yet -- so far, we've just been talking, I
thought, about untraceability.  But as far as I can see, there's no
reason that the consortium pay-only-at-entry scheme couldn't work with
encrypted remailers.  Am I confused?  Couldn't you use the same
cryptographic chain as is currently used, where all the inner entries in
the chain are free crypto-remailers open only to other consortium
remailers, but in which the outer encrypted message had the FV payment
attached, which gained it entry to the remailer pool?

> Try to bring up objections to a digicash-style system that are applicable
> to remailers.   I agree that they are different technologies that fill
> different requirements, but it seems to me that the particular requirements
> of a remailer system are only met by a digicash/magic money style
> technology.

Again, I think you mis-read me.  I haven't (nor do I care to) spent a
lot of time thinking about how to do remailers at all, let alone with
digicash.  What I was referring to was the basic objections that come
from using a digital cash scheme in the first place.

>  I think  an electronic cash system that will work with remailers, must
> satisfy these things:
> 1) You need to be able to enclose the "signifyer" of the transaction inside
> encryption.  Whether the "signifyer" is the cash itself, or an agreement to
> make a transaction together with a billing number, or whatever, you need to
> be able to enclose it in a PGP (or other arbitrary PKE protocol) encrypted
> block.
> 2) The "signifyer" of the transaction (which again might theoretically be
> the cash itself, or some kind of billing number) alone shouldn't be enough
> to reveal the identity of the anonymous user.

I agree that FV doesn't meet the above requirements, but I don't see why
they're necessary for remailers.  In the consortium scheme I'd proposed,
the only thing that could ever be proven about you would be that you had
used a remailer.  Now, if the message was not encrypted, your anonymity
could be broken by collusion of FV and the "entry" remailer.  But if the
cypherpunks style cryptographic chain was used, i.e. if the contents
(including an inner envelope that said who you really sent it to) were
encrypted, nothing more would ever be derivable without the collusion of
everyone in the chain, and even then it would only be derivable if
certain records were kept.  

All I'm claiming is that it's do-able using the FV payment system.  I'm
not going to do it myself because I don't personally feel that this
level of untraceability is EVER legitimately necessary.....  -- Nathaniel

This whole fracas between blind-sig money and FV money is a symptom of
the confusion between clearing and settlement.

Roughly speaking, clearing is when authorization moves (i.e. a
liability is created), and settlement is when money moves (i.e. when
that liability is discharged).  Clearing should always happen at or
before settlement.  In order to do on-line digital postage, you need
clearing to happen at the point of remailing.  Settlement can happen
at some later time.

Settlement need not be in real money.  The liability of other
settlement facilities can be used.  This is in fact how central
banking works.  Only the central bank moves "actual" funds; everyone
else moves liabilities around.

To wit, a remailer consortium would do best to issue a local banknote
usable only by themselves and have customers settle with the
consortium issuer, rather than any member of the consortium itself.
If the consortium issuer were to use blind sigs, the consortium
members wouldn't be able to ascertain who paid.

The mechanism for settlement could be credit cards directly, mailed in
checks, even FV.  The preferences of the consortium members for issues
of timeliness of settlement, reversibility, loss sharing, etc. would
decide the actual choice of settlement mechanism.

Eric

On Fri, 6 Jan 1995, Eric Hughes wrote:
> This whole fracas between blind-sig money and FV money is a symptom of
> the confusion between clearing and settlement.

It is nothing to do with that confusion.

> To wit, a remailer consortium would do best to issue a local banknote
> usable only by themselves and have customers settle with the
> consortium issuer, rather than any member of the consortium itself.
> If the consortium issuer were to use blind sigs, the consortium
> members wouldn't be able to ascertain who paid.

If they could use blind sigs they would not need a consortium.

The customer would just put the postage inside the envelope, and
each for-pay remailer would just peel of an envelope layer,
and use the postage that the user provided for it.

Chaumian money solves the problems we are discussing.

The problem that we are discussing is how to solve them 
without using Chaumian money.


 ---------------------------------------------------------------------
We have the right to defend ourselves and our
property, because of the kind of animals that we        James A. Donald
are.  True law derives from this right, not from
the arbitrary power of the omnipotent state.            jamesd@netcom.com

From: "James A. Donald" <jamesd@netcom.com>

   On Fri, 6 Jan 1995, Eric Hughes wrote:
   > This whole fracas between blind-sig money and FV money is a symptom of
   > the confusion between clearing and settlement.

   It is nothing to do with that confusion.

Keep your day job.

   > To wit, a remailer consortium would do best to issue a local banknote
   > usable only by themselves and have customers settle with the
   > consortium issuer, rather than any member of the consortium itself.
   > If the consortium issuer were to use blind sigs, the consortium
   > members wouldn't be able to ascertain who paid.

Get it?  The first sentence refers to a "local banknote".  The second
sentence refers to a particular way of issuing that banknote.  Passage
from the general to the specific.

   The problem that we are discussing is how to solve them 
   without using Chaumian money.

Think about how a local clearing organization allows this.

Eric

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                          SANDY SANDFORT
 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

C'punks,

> . . . a remailer consortium would do best to issue a local banknote
> usable only by themselves and have customers settle with the
> consortium issuer, rather than any member of the consortium itself.
> If the consortium issuer were to use blind sigs, the consortium
> members wouldn't be able to ascertain who paid.
> 
> The mechanism for settlement could be credit cards directly, mailed in
> checks, even FV.  The preferences of the consortium members for issues
> of timeliness of settlement, reversibility, loss sharing, etc. would
> decide the actual choice of settlement mechanism.
> . . .

Gee, this sounds awfully familiar.  Maybe Eric will have more
luck in getting you remailer folks to listen.  I hardly got so
much as a peep when I suggested that a remailers' guild create
or authorize one or more digital stamp issuers.

Damn, I hate being so far ahead of my time.


 S a n d y

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Sandy --

I for one read your proposal and thought, "yep, that's how it
should work" and considered the problem solved. Not being a
remailer operator (yet) I didn't want to get involved until I
was or I had a more concrete proposal (e.g., "I am now accepting
$$ for E-stamps, of the form ...")

Also, there is no reason on earth to take FV for payment under
such a scheme, if one wishes to preserve anonymity, and not have
to deal with the fraud/reversal factors. (The stamp issuer 
would not know which blind-signed stamps were issued to the
turkey who reversed all his credit card transactions two months 
after buying them -- see various threads on this vis-a-vis
using FV to buy blinded digital cash and why it won't work too
well.)

However, for maximum anonymity, said consortium or other stamp 
issuer could easily accept money orders through the mail, with 
a disk with enclosed blind-signed tokens and the public key to 
be used in encrypting the stamps, which would be posted to, say, 
alt.anonymous.messages or whatever.

A little overboard for most, but effective at preserving
anonymity -- the stamp issuer could be the NSA, and it would
make little difference as long as they continued exchanging
$$ for stamps and redeeming stamps for $$. The stamp issuer
could also take checks, or, if the fraud and reversability 
of credit cards were factored in, accept credit cards directly
(possibly e-mailed using PGP.)  

I don't see any reason to get FV involved, unless one were so lame 
as to be unable to get signed up directly with the credit card 
companies as a merchant -- a process of appropriate complexity
to indicate the posession of at least one (1) clue, which is prob.
desirable in someone who's going to be handling remailer finances
 

Sandy writes:
> Gee, this sounds awfully familiar.  Maybe Eric will have more
> luck in getting you remailer folks to listen.  I hardly got so
> much as a peep when I suggested that a remailers' guild create
> or authorize one or more digital stamp issuers.
> 
> Damn, I hate being so far ahead of my time.
>

Doug Barnes said:
> 
> Sandy --
> 
> I for one read your proposal and thought, "yep, that's how it
> should work" and considered the problem solved. Not being a
> remailer operator (yet) I didn't want to get involved until I
> was or I had a more concrete proposal (e.g., "I am now accepting
> $$ for E-stamps, of the form ...")

Same here, but from the other tack: "Remailer Guild??? Give me a
break :-)" My problem with the idea of "Guild" (or any quasi
general agreement) of remailer operators is that:

On the one side:
- The whole idea of a using a remailer chain comes from distrust of
the operators. The operators should be the ones to distrust each other
the most.

And on the other side:
- Most of the arguments I see in favor of some higher organisation
comes from difficulties for the users in using the current payment
systems without trace, and come from getting more weight in establishing
policies. Simply put, we'll get to untraceable cash (usable as stamps
on every envelope level), and we'll get to systematically encrypted
messages (policy only relevant at last stage remailers) soon enough.

A guild trying to distribute funds would need a system of accounting
that the operators themselves couldn't mess up. Good luck.

On the other hand, once you have:

- anonymous, untraceable e-money (small amounts are fine, no large bank
backing is fine, a simple anonymized Netcash would be fine. Remailers
won't be making big money from any single cheating entity anytime
soon.)

- reputation systems, in the line of the current remailer pinging. They
could include price surveys too. I also see them handling more flow
control missions in particular for "everyone a remailer" remailers.

- mailing tools that juggle for you all the different types of remailers,
cash, and rep systems.


Then and only then, you get for-pay remailers. There is still a need
for political and legal support for last stage remailers but that's
pretty likely to be country specific, and that's certainly independant
from a payment system (which would be netwide).

Finally, I do not believe that introducing payment in the remailer
system would curb abuse in any significant way. Significant abuse is
that which causes significant problems for the operators: posting
secret religious technology, forging prime minister mail, harrassing a
member of any number of opposite persuasions, etc... Do you think for a
minute that a 5 cents postage is going to stop these messages now? And
how about when remailers do attain good reliability and untraceability,
for 3 cents?

Give up already: remailers are going to transport lots of material that
will be offensive to somebody, illegal somewhere, in bad taste here, or
at least that somebody (with guns) will want to trace. That's the whole
point of remailers. Remailers that want to limit the heat can, for now,
restrict to encrypted traffic, there is certainly no dishonor to that.

Pierre.
pierre@shell.portal.com