David Molnar writes:
> Note that cash payments can have a property which encrypted messages
> usually do not : you can have the mix break up the payment into
> random-sized chunks, or aggregate several payments into a single
> transaction between servers.
>
> For example, say I send a payment for $123.45 -- the remailer might
> split this into a payment of $100 and a payment of $23.45. That
> $23.45 could then be combined with some other payments to create an
> aggregate payment of $100 which is sent to the next remailer in the chain.
> That remailer unpacks the aggregate, breaks up the $23.45 into $20
> or so and change, and so on.
Good point. In fact if a fixed-order mix chain is used (everyone uses
the same order), then the aggregated amount is just passed as one chunk
from one remailer to the next. However, when it gets to the final
remailer it must then be broken up again into its constituent pieces.
If one person is paying $10.25, another $51.49, another $3.99, etc., then
when the last remailer disburses exactly these amounts to the recipients,
everything will be revealed.
This seems to be a serious problem which must be addressed. Some of the
ideas from mixmaster don't work here, like padding messages to a standard
length. That would be analogous to "padding" all payments up to a
standard value, but that just won't work for most financial transactions.
As far as logs, consider this:
The bank (or whoever is handling the underlying payments) is in a special
position. It is actually modeled very well as the classical attacker
against the cypherpunk remailers: someone who is able to monitor all
message flow into and out of each remailer in the system, but is unable
to break into the remailers themselves, steal keys, and decrypt messages.
This is the model of the almost omniscient but still strictly passive
attacker. It was always unrealistic for the remailers (how hard for
the NSA to steal keys?). But for the payment mix, this is actually a
very good model for what the bank knows. It sees every payment in the
system, it knows exactly who is paying whom. But it knows nothing about
how payments are combined and disbursed within any one node of the system.
Given that there is an attacker with this kind of information, one which
could be easily coerced to cooperate with anyone who has enough guns,
how much is lost by making this information publicly and universally
available? Let every mix publish its money transfers. Give everyone as
much information as the bank has in order to track payments. The true
degree of security provided by the system is not diminished by making
this information public.
With this information, detecting misbehavior on the part of the mixes
would be much easier. If entry-point mixes gave signed receipts for
their input, then anyone whose payment was not passed along properly
could prove misbehavior. Intermediate and end-point mixes could be seen
from the logs to pay out as much as they take in. Cheating would become
virtually impossible.
Furthermore, this would give people a very good idea of how much actual
privacy they would gain from using this system. The current remailers
are an utterly black box, based on nothing more than faith. How many
other messages are mixed with my own? No one knows. With published logs,
customers would know exactly how much privacy they were purchasing.
If this method seems too revealing, though, there is another alternative,
similar to David's second proposal using designated verifier receipts.
What you want to do is to have the mix publish some kind of record of
all the payments it received, in encrypted form such that each person
can check that his payment is in the list, but protecting the privacy
of the payers and the amounts. Then the mix needs to publish the sum
of all the payments, along with a proof that the individual amounts all
add up to the sum.
This is exactly the same problem as electronic voting protocols, except
that those protocols take only a 0 or 1 as the "payment". But many of
them can be generalized to take an arbitrary amount.
Eric Hughes' encrypted open books protocol discussed here recently is
another example of the same idea. The mix reveals the sum of payments
and each person can make sure that his contribution is included in the
sum, but no one can see the actual amounts.
Within a chain of mixes, the mix-to-mix transfer is a single aggregated
amount and can be dealt with just by having each mix report how much it
received from the previous one. Then with the last mix in the chain you'd
probably go back to the zero knowledge sum-of-amounts protocol to show
that the disbursed payments all added up to what they were supposed to.
But keep in mind that all this fancy crypto is only going to protect
privacy against external observers. The bank sees all and knows all.
It is questionable whether it is worthwhile to go to these lengths for
such modest gains.
