[messaging] Unlinkable rendezvous via human-sized keys (was: Re: Human sized keys)

[Ximin Luo]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 880 bytes
Desc: OpenPGP digital signature
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20140320/adc9f3f6/attachment.sig>