[Cryptography] Secret Handshake problem.

[Jerry Leichter]

> The problem involves sex workers identifying dangerous customers in a manner
> in which it won't end up as another Ashley Madison.  Currently this is done
> via printed blacklists that can be consulted in centralised locations (many of
> the street workers don't have phones, this part is a bit out-of-scope for a
> technical solution).  The blacklists are printed off from a database that,
> depending on who's set it up, probably isn't secure against a concerted
> attack, so having a catalogue of clients in electronically lootable form is
> another problem to be solved.
> 
> Clients are identified by phone numbers and/or car plates, so the question is
> "is it safe to get in this car" or "should I take a call from this number"?....
If you flip the problem around and loosen the "identified by phone numbers and/or care plates" just a bit, there's a straightforward solution - which is a variation of what all "secret but public" organizations have done since time immemorial.

The blacklisting is presumably done by the wronged sex worker.  So instead have the worker whitelist a "good" customer by giving them a token.  The token is a one-time introduction to the next sex worker.  The tokens have unique id's that can be put in the database; they are paired with phone numbers or car plates.  The database stores that externally identifying information encrypted with the id, and the id hashed, so if you don't have the token id, there's no way to probe for the phone number/plate even if you steal the database.

Once used, the id is deleted from the database.  A worker under duress can give out an id, then cancel it later.

All the smarts for such a system can be in the server - the phone doesn't have to generate the tokens.  You can imagine a number of ways to get the token to the client - e.g., text it, or display a QR code on the worker's screen.

There remains the "enrollment" problem:  How do you get people in the first time?  The traditional technique is to allow someone who has an id to serve as introducer.  This gets you into all kinds of transitivity-of-trust issues in traditional systems - once you've let someone in, they're in.  But since here the introduction only gets you *one* token - and after that you are vetted at each interaction - it's not nearly as severe in this case.

For the real-world problem where there may not be an introducer, you can always have the first interaction take place in a well-controlled environment.

                                                        -- Jerry