Re: [freehaven-dev] POKs for mix accountability transcript

[David Hopwood <hopwood@zetnet.co.uk>]

-----BEGIN PGP SIGNED MESSAGE-----

Roger Dingledine wrote:
> On Sat, Jan 06, 2001 at 07:05:07AM +0000, David Hopwood wrote:
> > Actually I think I've been looking at this the wrong way. The leakage
> > of information is due to the fact that M and N_{j+1} can be linked with
> > Alice. That can be fixed by allowing Alice to publish the accusation
> > that N_j failed anonymously. Note that (C, M, N_j, N_{j+1}) is already
> 
> My problem with this is the chicken-and-egg problem. We're trying to build
> a fundamental building block of anonymous communication here.  If Alice
> has a channel for anonymously publishing her accusation in a robust way,
> why doesn't she just use that to talk to Bob and be done with it?

Because only some nodes are compromised or unreliable. If Alice just
chooses random routes (possibly weighted according to reliability ratings)
then she will eventually get through, unless the mix-net is so unreliable
as to be completely useless. She still wants to be able to prove that the
*original* route failed, though.

In a properly functioning mix-net, accusations of failure should be rare,
but it is still important to be able to prove failure, as an incentive
to make nodes reliable (or a deterrent to attacks that make nodes
unreliable).

Note that if Alice is not able to publish the accusation anonymously,
she can still publish it directly. If it is published anonymously then
strictly less information will be leaked, though.

> (I guess a possible answer might be "because this one can only talk
> to mixnet nodes",

That's not the reason, no. The difficulty of communicating anonymously
just with mix-net nodes, is about the same as the difficulty of
communicating anonymously with anyone (except that for encrypted
messages, key management might be more difficult in the latter case).

> but that still seems more complicated than it's worth. Hmm.)

Allowing failure accusations to be published via the mix-net is really
quite simple.

> > To implement this, we need to be able to give nodes an instruction
> > to publish a message on the ledger (i.e. all types of message, not
> > just "To N_i: M"). Alice also needs to be able to determine which node
> 
> what other types of messages are there?

For the design in the paper, "I blame N_i, claim: (r_i, N_{i+1},
E_{i+1}(...))". In the receipt-based protocol I suggested, there would
also be "Receipt-request" messages.

- -- 
David Hopwood <hopwood@zetnet.co.uk>

Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5  0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip


-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: noconv

iQEVAwUBOlfNPzkCAxeYt5gVAQESFgf/X2CIwY/f0TzXarym7+K5YVhsVhI6aRrl
L7z5McTj5xhAhLJYl08skqgGI3RLuufQCB3hfepqzhAbEHrhsP3/3Ngv6Gyg3JUb
XVTwWfp7YI1N1kEkdSPQ2VNg1FbCJUFFdoAbUcprErNK3+xefZsDCaOVi5Xrt2gt
UXqibk816ijyUA/ctklLWv2P/l6+Js/k/i0qpmusIF7usRAtjwReDIg8kQhoa6+P
ss8AHKvkYGKsxplslz8IXgzTEbh6AFm/AeO0VJql6pHrT4f2Bqoszqsr2cjXvw1y
mxZm7WWsLmqSSnT7fv9+lajMZLKoLjiNX6xwLZiBNxLW5gJgLdsMTA==
=5sU3
-----END PGP SIGNATURE-----