On 20/03/14 16:06, Ximin Luo wrote: > On 20/03/14 07:11, Trevor Perrin wrote: >> >> (Context for this discussion: >> >> https://moderncrypto.org/mail-archive/messaging/2014/000086.html >> https://moderncrypto.org/mail-archive/messaging/2014/000113.html >> ) >> > > (Going on this thread since the other one is a month old.) > > In your previous proposal sketch, you said: > >> If Alice's mailbox server is being used for rendezvous, Alice will do >> the following: >> - Alice will have a bunch of "rendezvous tokens". Alice's mailbox >> server gives these tokens to its users via a blind signature scheme, >> so it can recognize authentic tokens but can't trace them. > > What's the purpose of these tokens, given that Bob is not similarly required > to present them? Anti-spam? > > I'm not familiar with blind signatures, but is it really the case that the > server can't trace them? > > The server could generate tokens *using different keys*, and hand them out to > different clients, thereby distinguishing a user when they post (and > subsequently when the message is retrieved). (The anonymity system should at > least protect the identity of the other person, but the server now has timing > information about a bunch of key exchanges, all linked to one user.) > > So the clients (as a group) need some way of ensuring that the same key is > consistently used. I'm not sure how best to solve this. Presumably the client > needs to be authenticated in order to receive a token (otherwise what's the > point), so to maintain anonymity you would also need a group authentication > scheme, with the same consistency requirement. >
Scratch that, this is out-of-scope. We can assume that the client knows the server's long-term key, so the blind-signature key could be derived from this. (And the group authentication is not required because the signature is blind.) Validating the server is a concern, but it's a concern for all systems, and it would be solved with general techniques. Sorry for the noise. > But, if spam is the only reason for having these tokens, perhaps we can find > simpler ways of dealing with spam. e.g. expiry on posted messages, the usual > anti-DDoS protections, etc. And note that this is only in the introductory > phase, so still better than email. > > X > -- GPG: 4096R/1318EFAC5FBBDBCE git://github.com/infinity0/pubkeys.git
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Messaging mailing list [email protected] https://moderncrypto.org/mailman/listinfo/messaging
