[Cryptography] ZK meeting scheduling protocol?

[Ben Laurie]

This is almost the same as a problem I'd like to solve, which is this:
I travel a fair amount. I would quite like to be able to meet up with
friends/acquaintances/interesting strangers, who may also travel
frequently, when they happen to be in the same place as me, but I
don't want to publish a detailed itinerary, and nor do they.

Your phrasing makes me realise that this is a well known problem:
private set intersection, There's plenty of protocols in the
literature.

In your case, participants each make a set of available time slots,
and that's what they intersect. In my case, I guess I want a list of
time slots and approximate locations.

Since the protocols (AFAIK) rely on exact matching, these sets are
going to be a bit painful to make, but it seems possible (e.g. if I am
looking for a 1 hour meeting and I have a 2 hour slot available, then
I might list every hour long slot in that window with 1 minute
granularity).

Most of the protocols I've seen are two party (and sometimes one way)
which may be a problem. But I haven't checked carefully yet.

On 15 January 2017 at 19:58, Jerry Leichter <leichter at lrw.com> wrote:
>> At the end of the protocol, either no such common date is available -- ever -- or a common date is secured.  Everyone then knows the date.  However, no one ever learns (at least from the protocol itself) which non-selected dates matched on any subset of the peoples' calendars.  Thus, for example, no one can figure out who is the busiest (or least busy) person by studying all the messages from the protocol.
> Ray Dillinger already pointed out some of the ambiguities in the problem definition.  But let's consider a simpler one:  A useful scheduling algorithm can be iterated, and applied to arbitrary sets of users.  But then to determine whether you are free at time X, I need merely fill my schedule from now to X, then propose a meeting with you and see what the system comes back with!
>
> Yes, this might expose what I'm doing.  But there are "inverse" methods like trying to set up an appointment with you and n-1 others, then with just the n-1; if the resulting appointment changes, you were the one who had a problem with it.
>
> This feels like the problem of trackers in databases - which turned out not to have any simple solutions, only statistical ones (and even those are tricky).
>
> Pinning down the exact definition of a "secure anonymous meeting protocol" in such a way that it actually *has* any interesting solutions seems quite difficult....
>                                                         -- Jerry
>
> _______________________________________________
> The cryptography mailing list
> cryptography at metzdowd.com
> http://www.metzdowd.com/mailman/listinfo/cryptography