CatNap: Leveraging Generic MPC for Actively Secure

Privacy-enhancing Proximity Testing with a Napping Party

Ivan Oleynikov

, Elena Pagnin

and Andrei Sabelfeld

Chalmers University, Gothenburg, Sweden

Lund University, Lund, Sweden

Keywords:

Privacy, Proximity-Testing, Multi-Party Computation, Active Security.

Abstract:

Proximity testing is at the core of several Location-Based Services (LBS). Despite a series of reported and

conﬁrmed abuses, modern LBSs still demand their clients to disclose their locations in plain in order to preform

location proximity testing.

This works aims at enhancing proximity testing with privacy. We design CatNap a novel protocol that (1)

implements precise Euclidean distance matching; (2) allows matching even if the clients are not online at

the same time (the “napping party” feature); (3) is secure against active adversaries (malicious actors that

corrupt up to one party); (4) makes black-box use of generic Multi-Party Computation techniques (any future

improvement of the underlying building blocks will also boost CatNap); and (5) is efﬁcient: servers run with

about 0.03 seconds of CPU time and 5.6MB of communication, while clients perform only a small number of

Boolean operations and need just 51 bytes of communication.

1 INTRODUCTION

Location-Based Services (LBS) have gained a steadily

increasing role in our lives by providing personal-

ized services based on users’ locations, e.g., display-

ing nearby points of interest, selecting optimal ser-

vices (e.g., taxi rides), or even triggering speciﬁc

location-based behaviors (e.g., smart home devices).

At the core of most LBS is a proximity testing (PT)

protocol that allows the system to decide whether

some parties lie within a certain proximity of one an-

other. This paper focuses on PT by means of privacy-

enhancing protocols and input coordinates (e.g., users

know their own locations), which is the main use

case for LBS. We acknowledge the existence of other

approaches that implement PT via direct commu-

nication and measuring signal strength using, e.g.,

Bluetooth (Troncoso et al., 2020) (adopted in some

COVID-19 contact tracing apps). While these so-

lutions might provide an accurate distance calcula-

tion, they occupy a different niche: in some LBS it

might not be possible for users to pick each other sig-

nals (e.g., planning for a shared ride between towns;

matching with a proximity radius larger than the sig-

nal range; or matching with ofﬂine users).

Modern taxi services match drivers and passen-

gers according to the proximity of their routes, or the

start and endpoints of their journeys. Messaging apps

use PT to match users who are in the same area, and

online mapping services use it to help users discover

close-by places.

In current practice, LBS are full-trust centralized

services: to deliver their functionality, they require

users to submit their location data to the LBS. This

way, the LBS provider knows the location of any ac-

tive client in their system; and clients cannot check

if their data has been used the way they expect, and

not misused by the LBS provider or stolen by an at-

tacker who breached the security of LBS. For exam-

ple, Snapchat employees reportedly abused their priv-

ileges to spy on users’ location data (Cox, 2019), and

similar cases were reported about Uber (Hern, 2016),

Yahoo (Cole, 2019), and Facebook (Cox and Hoppen-

stedt, 2018). This raises privacy concerns over the ex-

isting practices and motivates the search for solutions

that would ensure the privacy of user data.

This paper designs a cryptographic protocol that

performs proximity testing in a privacy-enhancing

way. Such protocol is required to be correct (pro-

vide the right answer) and secure (preserve input pri-

vacy) by revealing only the outcome of the PT, and

no further information about users’ locations. In the

remainder of the paper, whenever we refer to PT, we

will mean privacy-enhancing proximity testing.

Oleynikov, I., Pagnin, E. and Sabelfeld, A.

CatNap: Leveraging Generic MPC for Actively Secure Privacy-enhancing Proximity Testing with a Napping Party.

DOI: 10.5220/0011279500003283

In Proceedings of the 19th International Conference on Security and Cryptography (SECRYPT 2022), pages 237-248

ISBN: 978-989-758-590-6; ISSN: 2184-7711

237

Formalizing PT. There exist multiple approaches to

formalizing “location” and “proximity” in PT. The

grid-based approach (Zhong et al., 2007; Siksnys

et al., 2009; Siksnys et al., 2010; Freni et al., 2010;

Mascetti et al., 2011; Narayanan et al., 2011; Nielsen

et al., 2012; Kotzanikolaou et al., 2016) divides the

whole plane into a grid of cells, the clients determine

the cell they are in and then simply perform equal-

ity test on their cell identiﬁers. Although it might be

tempting to do PT at a cost of a simple equality test,

this approach suffers from inherent imprecision. An-

other alternative is polygon-based matching (J

arvinen

et al., 2019), which becomes less efﬁcient if one wants

to approximate a circle with a polygon (but may suit

applications like geofencing). We follow the line of

work on Euclidean distance-based matching (Hall-

gren et al., 2015; Oleynikov et al., 2020; J

arvinen

et al., 2019; Pagnin et al., 2019), because it is pre-

cise and it is natural to some important applications,

e.g., messengers, social networks, and taxi. Euclidean

distance may serve as an approximation of other mea-

sures like Manhattan distance.

In this work, we consider users’ locations to be

points on a (discretized) Euclidean plane (which can

approximate a small enough region of Earth’s sur-

face). Our functionality matches two users (outputs

1 instead of 0) if the distance between their input lo-

cations does not exceed a threshold radius value R,

on which they agree beforehand. The threshold ra-

dius R here serves as a parameter of the protocol, and

can be chosen to be any positive integer when instan-

tiating the protocol; it is ﬁxed and public, i.e. known

to all the parties prior to the protocol start. We fo-

cus on the case of 2-dimensional client locations (i.e.

belonging to a Euclidean plane) for a fair comparison

with prior work, but it is not essential for our protocol:

CatNap easily generalizes to n-dimensional Euclidean

distance-based matching.

Distinguishing Features of CatNap. There are three

crucial features that we achieve with CatNap but that

were out of reach for previous work (Hallgren et al.,

2015; J

arvinen et al., 2019; Oleynikov et al., 2020) on

Euclidean distance-based PT:

Offline. We adopt the setting of “napping party”

(Oleynikov et al., 2020): in addition to the two clients

who want to use the PT, we introduce two servers that

will aid the clients in it. One of the clients can con-

nect to the servers at any moment, submit its location

(in a privacy-preserving manner) to them and go of-

ﬂine. The other client will connect to them later, sub-

mit its location, wait for the servers to perform match-

ing, and retrieve the result. The clients connect to the

servers at possibly disjoint moments of time. In real-

life applications, the two servers can be run by inde-

pendent, mutually distrusting organizations which are

providing a single LBS together. Introducing servers

is necessary to perform privacy-preserving PT while a

client is ofﬂine. The use of two not-colluding servers

allows us to remove the requirement for clients to

share keys or any other secret information before the

protocol starts. As a consequence, the data submitted

by a client is not tied to a speciﬁc other client and it is

up to the servers to decide whom to match the client

with.

RadiusInd. In (Hallgren et al., 2015; Oleynikov

et al., 2020) the protocol performance depends on R,

the proximity radius. This is a signiﬁcant limitation

that makes such protocols practical only for small

enough values of R. In contrast, our CatNap’s per-

formance (computation, communication, and round

complexity) does not depend on the chosen value of

ActiveSec. From the security viewpoint, for a

protocol to be truly practical it needs to be secure

against active adversaries (actively secure for short).

This means that the protocol preserves its security

even if some of the parties get corrupted by the adver-

sary, who maliciously makes them deviate from the

protocol speciﬁcation. As discussed by Oleynikov et

al. (Oleynikov et al., 2020), if the adversary corrupts

both servers, it can recover all locations submitted by

clients. In this setting, it is impossible to guarantee

location privacy and clients’ input privacy is lost. We

require CatNap to have the best possible active secu-

rity in the given circumstances: to be secure as long

as at least one of the two servers is honest.

The ofﬂine feature is particularly distinguishing

since most existing PT protocols (Zhong et al., 2007;

Hallgren et al., 2015; Oleynikov et al., 2020; Hallgren

et al., 2016; Sakib and Huang, 2016; J

arvinen et al.,

2019) require the clients (who want to perform the PT

of their locations) to communicate directly with one

another. This presents a signiﬁcant limitation to the

protocols’ applications: in some scenarios, users ex-

pect to be matched with their friends or places on the

map (e.g. cafes, stores) even when the other clients

are not online. Therefore it may be desirable to have

an intermediate entity that the clients could interact

through. While the use of servers is necessary to per-

form ofﬂine PT, relying on two servers comes with an

extra beneﬁt: now the clients can reduce their work-

load by ofﬂoading computations to the servers. Al-

though the servers do not learn the matching outcome,

they know which clients requested PT to be run (also

how many times and when the users did so); this is a

necessary compromise since perfectly hiding the user

identities to the servers would introduce an unrealistic

performance overhead and negate all the beneﬁts of

SECRYPT 2022 - 19th International Conference on Security and Cryptography

238

Offline feature. Concrete server policies for choos-

ing clients to match are very application-speciﬁc and

are out of the scope of this work. It must be noted that

such a policy can be correctly enforced as long as at

least one of the two servers honestly follows it; which

is realistic in our model, where the protocol security

already requires one of the servers to be honest.

Table 1 summarizes the features achieved by our

protocol, CatNap, compared to the most relevant re-

cent works. The InnerCircle protocol by Hallgren

et al. (Hallgren et al., 2015) involves two clients

who communicate with one another directly, its main

drawbacks are passive security and performance pro-

portional to R

. The protocols ABY

and ABY

by J

arvinen et al. (J

arvinen et al., 2019) have per-

formance that is independent of the radius value R,

but use passively secure two-party computation tech-

niques which implicitly demand clients be online at

the same time and interact. The OLIC protocol by

Oleynikov et al. (Oleynikov et al., 2020) is essentially

an adaptation of InnerCircle to the two-server setting,

and thus it is the ﬁrst protocol to provide the Offline

feature. It inherits some of the drawbacks of Inner-

Circle (Hallgren et al., 2015): passive security and

-dependent performance. These works are further

discussed in section 5. This paper presents CatNap,

the ﬁrst protocol for privacy-enhancing location PT

to achieve all the above three properties.

Table 1: Comparison of CatNap features to the related pro-

tocols.

Protocol

Offline

RadiusInd

ActiveSec

InnerCircle

(Hallgren et al., 2015)

− − −

ABY

and ABY

arvinen

et al., 2019)

− + −

OLIC (Oleynikov et al., 2020) + − −

CatNap + + +

Our Contribution. This paper presents CatNap,

a novel, actively secure protocol for server-aided

privacy-enhancing PT. CatNap is the ﬁrst actively se-

cure PT protocol to achieve practical performance.

We provide a formal description of the CatNap pro-

tocol and its building blocks. We formally prove its

security in Canetti’s hybrid model (Canetti, 1998), as

long as one of the two servers is honest. In addition,

we develop a proof of concept implementation of Cat-

Nap and compare its performance against InnerCircle

(Hallgren et al., 2015), OLIC (Oleynikov et al., 2020),

ABY

and ABY

arvinen et al., 2019). Although

the InnerCircle, ABY

, and ABY

protocols (Hall-

gren et al., 2015; J

arvinen et al., 2019) do not work in

the same setting as CatNap (their clients talk directly

to one another and are required to be online at the

same time), we still include them to see how CatNap

compares with server-less PT.

Our evaluations show that CatNap’s demands on

the servers in terms of amortized computation and

communication are quite moderate. For example,

performing 2000 matchings requires 0.03 seconds of

CPU time (ignoring the network latency) and 6 MB of

communication in total per matching. We stress that

taking into account only the amortized complexity is

practical since in real-life scenarios LBS providers

will be matching large numbers of users and will be

able to run a longer precomputation phase. It is worth

noting that the improved amortized performance of

our protocol comes solely from the MPC techniques

edaBits (Escudero et al., 2020), SPDZ2k (Cramer

et al., 2018), Tinier (Frederiksen et al., 2015) which

tend to perform better when run multiple times, not

the construction we present here. The computation

and communication cost for clients is negligible, we

ignore it in our benchmarks.

Overview of Our Technique. We build CatNap us-

ing generic Multi-Party Computation (MPC) tech-

niques provided out of the box by the MP-SPDZ

framework (Keller, 2020). In our protocol, the

clients “outsource” the functionality computation to

the servers using the technique of Jakobsen et. al.

(Jakobsen et al., 2014): each of the two clients secret-

shares its location between the servers; the servers

input the shares into an MPC protocol, reconstruct

them there and evaluate the PT functionality; after

that, the servers use a simple masking technique to

deliver the result to one of the clients without learn-

ing it themselves. Since the PT involves both arith-

metic (computing distance between the clients) and

non-arithmetic (comparing the distance to the thresh-

old radius R) operations, we combine two MPC proto-

cols: SPDZ2k (Cramer et al., 2018) and Tinier (Fred-

eriksen et al., 2015), using the former for computation

in the arithmetic domain, and the latter for the binary

domain. To convert values from arithmetic to binary

and vice versa we use the daBits (Rotaru and Wood,

2019) and edaBits (Escudero et al., 2020) techniques.

Assumptions. CatNap is not a fully-featured protocol

that can be used for a real-life LBS implementation

out of the box, it is best seen as a fundamental build-

ing block that can be used by an LBS. CatNap works

in the standard setting of MPC protocols (Lindell,

2016), the same setting was used for a number of pre-

vious PT protocols (Hallgren et al., 2015; Oleynikov

et al., 2020; J

arvinen et al., 2019) albeit the (passive)

CatNap: Leveraging Generic MPC for Actively Secure Privacy-enhancing Proximity Testing with a Napping Party

239

adversary was more limited in those protocols. The

assumptions of this model are: parties communicate

through secure point-to-point channels (which can be

implemented in real life by means of Public Key In-

frastructure), at the beginning of the protocol the (ac-

tive) adversary can corrupt some of the parties and

arbitrarily change their behavior attempting to learn

something about the other parties’ inputs and cause

the other parties’ outputs to be incorrect. CatNap en-

sures that the adversary can not do this as long as both

servers are not corrupted at the same time.

Scope. The setting of CatNap does not address the

data leakage that is allowed by the functionality it-

self, e.g., knowing whether some user is close to you

or not inevitably reveals something about that user’s

location, or when two users perform the matching

the servers will learn the fact that matching happened

(since they know what users they communicated with

and when) but not the result of that matching. CatNap

does not deﬁne how clients specify whom they want

to be matched with; such a selection process highly

depends on the application, and, as a consequence,

should not be implemented by a sub-routine such as

CatNap. Also, CatNap does not protect against at-

tacks by a user who might probe the protocol with

different maliciously crafted locations trying to learn

something about the other users. To mitigate this in

a real-life instantiation, it may be necessary to ap-

ply some policy similar to MaxPace (Hallgren et al.,

2016) limiting the queries that a client is allowed to

make. Also, CatNap trivially supports replacing two

servers with more while still allowing all of them ex-

cept one to be corrupted. This setting relaxes the secu-

rity assumption at the cost of extra performance over-

head; a similar model with multiple servers is offered

by the Sharemind (Sharemind, 2022) framework.

2 PRELIMINARIES

Ideal Functionality. To model the mixed arithmetic-

binary MPC, we make black-box usage of the func-

tionality F

AB-MPC

shown on Figure 1. This function-

ality is implemented by the edaBits (Escudero et al.,

2020) technique. Most of the commands in F

AB-MPC

repeat the functionality on which the edaBits is built,

except for the commands ConvertA2B and Compare

which are implemented using the edaBits technique

itself. The Compare is obtained by combining the

other commands of F

AB-MPC

, but there are multiple

ways to do that (e.g., using a Boolean comparison cir-

cuit or with probabilistic truncation (Escudero et al.,

2020)). For the sake of generality, we deﬁne Compare

as a standalone command and leave its speciﬁcation

Input: On input (Input, P

, type, id, x) from P

and

(Input, P

, type, id) from all other parties, with id

a fresh identiﬁer, type ∈ {binary, arithmetic}

and x ∈ Z

or x ∈ Z

(depending on type), store

(type, id, x).

Linear Combination: On input

(LinComb, type, id, (id

)

i=1

, (c

)

j=0

), where

each id

is stored in memory and c

∈ Z

type = binary or c

∈ Z

if type = arithmetic,

retrieve ((type, id

, x

), . . . (type, id

, x

)), compute

y = c

∑

i=1

· c

modulo 2 if type = binary

and modulo 2

if type = arithmetic, and store

(type, id, y).

Multiply: On input (Mult, type, id, id

, id

) from all

parties (where id

, id

are present in memory), re-

trieve (type, id

, x), (type, id

, y), compute z = x ·y

modulo 2 if type = binary and modulo 2

if type =

arithmetic, and store (id, z).

From Binary to Arithmetic: On input

(ConvertB2A, id, id

′

) from all parties, retrieve

(binary, id

′

, x) and store (arithmetic, id, x).

From Arithmetic to Binary: On input

(ConvertA2B, id

. . . id

l−1

, id

′

) from all

parties, retrieve (arithmetic, id

′

, x), bit-

decompose it into (x

, . . . x

k−1

) and store

((binary, id

, x

), . . . (binary, id

l−1

, x

l−1

)).

Compare: On input (Compare, id, id

′

, y) from all par-

ties, where y ∈ Z

, retrieve (arithmetic, id, x),

store (binary, id

′

, 1) if x ≤y or (binary, id

′

, 0) oth-

erwise.

Output: On input (Output, type, id) from all honest

parties (where id is present in memory), retrieve

(type, id, y) and output it to the adversary. Wait for

an input from the adversary; if this is Deliver then

output y to all parties, otherwise output Abort.

Figure 1: Ideal functionality F

AB-MPC

of MPC arithmetic

blackbox modulo 2 and modulo 2

(Escudero et al., 2020).

up to speciﬁc implementations. The edaBits (Escud-

ero et al., 2020) is implemented in MP-SPDZ (Keller,

2020) framework (which we use for our benchmarks).

Notation. We will use the notation JxK

for

value x ∈ Z

being input into the F

AB-MPC

with type = arithmetic, and JxK

for value x ∈

{0, 1} with type = binary (the variable names x

are assumed to be unique over both arithmetic

and binary domains). When describing proto-

cols that use F

AB-MPC

in pseudocode, we will

use the listed message types as procedure names,

e.g., JxK

← ConvertB2A(JyK

) means sending

(ConvertB2A, “x”, “y”) to the F

AB-MPC

. We will also

use values J·K

in arithmetic expressions and J·K

Boolean expressions (i.e., arithmetics over F

), im-

plying evaluation of the corresponding expressions

using Mult and LinComb. For a vector of bits v =

SECRYPT 2022 - 19th International Conference on Security and Cryptography

240

, . . . v

k−1

) we will write J

−→

v K

to denote a vector of

bits (Jv

, . . . Jv

k−1

), all of which are in the binary

domain of F

AB-MPC

3 THE CatNap PROTOCOL

The CatNap protocol is built by combining the pre-

vious works in a blackbox way, i.e., relying only on

their most standard properties. Figure 2 gives an

overview of the order in which the existing techniques

are applied to one another. Here, Tinier provides

MPC computations in the binary domain, SPDZ2k

provides computations in the arithmetic domain, ed-

aBits combines the two to implement a single MPC

capable of doing both and converting between them,

and, ﬁnally, the outsourcing technique allows the

clients to securely transfer their data into the edaBits

MPC and then get back the result even if one of the

servers is untrusted. The rest of this section shows

the operations done by CatNap in greater detail; it es-

sentially unfolds the last step from Figure 2 to show

how the inputs and outputs are transferred to and from

edaBits MPC, and it also shows how the squared dis-

tance between parties is computed and compared to

the radius. The edaBits is still treated as a blackbox

in this section, since unfolding that one as well would

yield too much detail and harm the high-level exposi-

tion.

Tinier

SPDZ2k

edaBits

Outsourcing Technique from

(Jakobsen et al., 2014)

AB-MPC

CatNap

Figure 2: The diagram of blackbox applications of previous

works that yields CatNap protocol and the F

AB-MPC

func-

tionality that we use to build CatNap.

CatNap involves four parties: two servers

Server-1 and Server-2; and two clients Alice and

Bob. Alice and Bob know their respective locations

, y

) and (x

, y

), and will input these at the start

of the protocol. At the end of its execution, CatNap

returns to Alice a bit ρ; ρ = 1 if her distance to Bob

is less than or equal to a given public value R, other-

wise ρ = 0. Following the ofﬂine feature introduced

by OLIC, in CatNap clients never exchange messages

with one another directly: all of Bob’s interaction hap-

pens before any interaction from Alice (i.e., Bob acts

as a “napping party” during the actual proximity test).

Parameters: a positive number R, the radius of proximity

testing; k, the bit width of clients’ coordinates.

Setup: Four parties, Alice, Bob, Server-1, Server-2.

Alice and Bob hold inputs (x

, y

) ∈ Z

and (x

, y

) ∈

respectively

1. Receive (x

, y

) from Alice, and (x

, y

) from Bob.

Ensure that each value x

, y

, x

, y

consists of ex-

actly k bits; if not, abort.

2. Receive Deliver from both servers. If one of them

sends something else, abort.

3. Send ρ = 1 to Alice if (x

−x

)

+ (y

−y

)

≤ R

and ρ = 0 otherwise.

4. Send Received to both servers.

Figure 3: The F

ideal functionality.

Figure 3 shows the formal deﬁnition of the ideal func-

tionality F

that CatNap implements, while Figure 5

shows how CatNap implements F

in the real world.

CatNap achieves the F

functionality in three

major steps. First, the client inputs are transferred into

the F

AB-MPC

functionality. Remember that clients

cannot communicate with the F

AB-MPC

directly, only

servers do that. To transfer its input, each client

authenticates it using AMD (Algebraic Manipula-

tion Detection code) and secret-shares z, its authen-

tication key, and tag between the servers (Jakobsen

et al., 2014). The servers input the shares together

with the authentication tags into F

AB-MPC

, verify that

the shares are correct, and reconstruct them inside

the functionality. Second, the servers compute the

squared Euclidean distance between the clients’ input

locations:

D = (x

−x

)

−(y

−y

)

. (1)

Subsequently, the servers compare D to R

, ob-

taining a single bit ρ ∈ {0, 1}, where ρ = 1 if D ≤ R

and ρ = 0 otherwise. We remark that all computations

performed by the servers so far are implemented triv-

ially using the arithmetic and comparison operations

supported by F

AB-MPC

. This means that the servers

never see D or the client inputs in plain, yet by inter-

acting with the F

AB-MPC

functionality they can oper-

ate on these values without seeing them. Third, the

servers transfer the result ρ to one of the clients in a

safe way. This is achieved via the technique of Jakob-

sen et al. suggest in (Jakobsen et al., 2014). None of

the three steps reveals anything about the clients’ in-

puts or ρ to the servers; all of the values the servers

work with are either blinded with random masks or

are inside F

AB-MPC

The transferring of client inputs into the F

AB-MPC

functionality mentioned above is done in bit-

decomposed form: each coordinate is represented as a

CatNap: Leveraging Generic MPC for Actively Secure Privacy-enhancing Proximity Testing with a Napping Party

241

bit-vector, the vectors of all coordinates are concate-

nated and the result is transferred (using Transfer

shown below) into F

AB-MPC

. This has a useful side-

effect: we can naturally bound inputs of each client

by limiting the number of bits in their representation

(Transfer accepts only ﬁxed number of bits). This

way, a malicious client cannot input values that are

too large and cause an overﬂow modulo 2

in the

computation of D (Equation (1)). We limit each client

coordinate to k bits, where k is any positive integer

such that 2k + 3 ≤ m (this ensures that there is no

overﬂow in the expression for D from Equation (1)).

I.e. for all meaningful values of R, it must hold that

0 ≤ R ≤ 2

√

The Transfer Sub-protocol. Figure 4 shows the

sub-protocol that transfers the clients’ inputs into

AB-MPC

. This happens between a client (who can

be either Alice or Bob) and the two servers. The

purpose of this sub-protocol is to transfer a vector

z ∈ F

from the client into the binary domain of

the F

AB-MPC

functionality (without revealing it to the

servers). Formally, this protocol can work for values z

of any length. In practice, each client will execute this

sub-protocol exactly once with z being the concatena-

tion of the bit-decomposition of their input locations

(Alice will additionally concatenate a random bit ρ to

her z, which will be used in the last step of the whole

CatNap protocol. More on this on Figure 5).

The Transfer routine starts with a client, say,

Alice authenticating her input z using AMD with a

freshly generated key (step 2), then she secret-shares

the value z, the picked key and the authentication tag

between the two servers using XOR (steps 1 and 3).

The servers input the shares and tags into F

AB-MPC

(step 4). At this point, the servers can simply re-

veal the keys to each other (steps 5), since they can-

not modify the shares nor the tags they input into the

functionality. After that, the servers recompute the

authentication tag J

−→

u K

(step 6) and compare it to the

one that the servers have input (step 7).

Computing AMD is essentially free since it uses

only linear operations (see the extended paper ver-

sion (Oleynikov et al., 2022) for more details). On

the other hand, the equality check is the heaviest

step computations-wise, because this comparison re-

quires non-linear Boolean operation

. The servers

reveal the result JcK

of the equality check and abort

if JcK

= 0 (step 8). This completes the authentication

check, now each server is convinced that the other one

has not cheated while inputting the client data into

AB-MPC

. Now, they can reconstruct the secret-shared

value J

−→

z K

(without revealing it yet), which is the re-

sult of running this sub-protocol.

Setup: One client (Alice or Bob) and the two servers

(Server-1 and Server-2). The servers have access to

the F

AB-MPC

functionality (of Figure 1).

Initial condition: The client knows its input z ∈ F

which is a sequence of l bits. σ is a statistical security

parameter.

Final condition: The bits of z are input into F

AB-MPC

functionality as J

−→

z K

1. The client authenticates its input z using AMD with

freshly chosen key:

(a) κ ←

(b) t = AMD

(z)

2. The client secret-shares its input z, the authentication

key and tag input z using AMD with freshly chosen

key:

(a) r

(1)

←

, κ

(1)

←

(b) r

(2)

= z ⊕r

(1)

(2)

= κ ⊕κ

(1)

(d) t

(1)

←

(e) t

(2)

= t ⊕t

(1)

3. The client sends (r

(1)

, κ

(1)

, t

(1)

) to Server-1, and

(2)

, κ

(2)

, t

(2)

) to Server-2.

4. The servers input shares r

(·)

and the tags t

(·)

into the

AB-MPC

(a) Jr

(1)

← Input

Server-1

(1)

) for i ∈{0 . . . l −1}

(b) Jr

(2)

← Input

Server-2

(2)

) for i ∈{0 . . . l −1}

(1)

← Input

Server-1

(1)

) for i ∈{0 . . . σ −1}

(d) Jt

(2)

←Input

Server-2

(2)

) for i ∈ {0. . . σ −1}.

5. The servers send κ

(1)

and κ

(2)

to one another and

recover κ = κ

(1)

⊕κ

(2)

6. The servers recompute the tag for the z inside the

AB-MPC

(a) J

−→

u K

= AMD

−→

(1)

⊕J

−→

(2)

)

7. The servers check that the computed tags match the

expected values:

JcK

← EQ(J

−→

u K

, J

−→

(1)

⊕J

−→

(2)

where EQ((a

. . . a

l−1

), (b

. . . b

l−1

)) = ¬

l−1

i=0

⊕

is the logical formula that compares two sequences

of bits for equality.

8. The servers reveal the bit c ← Output(JcK

) and

abort if c = 0.

9. The servers reconstruct the value J

−→

z K

= J

−→

(1)

⊕

−→

(2)

, which is the result of this sub-protocol.

Figure 4: The Transfer sub-protocol.

The CatNap Protocol. Figure 5 provides a detailed

overview of our CatNap protocol. We recall that Cat-

SECRYPT 2022 - 19th International Conference on Security and Cryptography

242

Nap implements the F

functionality from Figure 3.

The protocol starts with both clients transferring their

inputs into F

AB-MPC

using Transfer (step 1). They

do so by running the Transfer protocol on the con-

catenation of the bit-decomposition of their inputs.

Alice additionally transfers a random bit µ that will

be used in the ﬁnal stage of CatNap to privately trans-

fer the matching outcome ρ from F

AB-MPC

back to

her. The servers convert the clients’ inputs from the

binary domain into the arithmetic domain, as required

in the F

AB-MPC

functionality (step 1c). Alice’s mask

µ remains in the binary domain.

Parameters: a positive number R, the radius of proximity

testing; k, the bit width of client coordinates.

Setup: Alice, Bob and the two servers. The servers have

access to the F

AB-MPC

functionality (depicted in Fig-

ure 1). It must hold that 2k + 3 ≤ m, where Z

is the

arithmetic domain of F

AB-MPC

. Alice and Bob receive

, y

) and (x

, y

) as inputs.

1. Inputs outsourcing phase.

(a) Bob bit-decomposes his input coordinates x

and

, represents them as a single 2k bit string, and

runs the Transfer protocol (Figure 4) on it.

(b) Alice samples a random bit µ, bit decomposes

her inputs x

and y

, and represents all of them

as a single string of 2k + 1 bits. Then she runs the

Transfer protocol on it.

metic domain

← ConvertB2A(J

−→

)

← ConvertB2A(J

−→

)

← ConvertB2A(J

−→

)

← ConvertB2A(J

−→

The value JµK

stays in the binary domain.

2. The Servers compute the squared distance between

Alice and Bob and compare it to R

(a) JDK

← (Jx

−Jx

)

+ (Jy

−Jy

)

(b) JρK

← Compare(JDK

, R

3. The servers mask the bit ρ with µ and reveal the re-

sult:

(a) Jρ

′

← JρK

⊕JµK

(b) ρ

′

← Output(Jρ

′

4. Both servers forward the obtained ρ

′

to Alice.

5. Alice ensures that both servers have sent the same

value of ρ

′

, unmasks it to get the ﬁnal result ρ =

′

⊕µ, which she outputs.

Figure 5: The CatNap protocol.

Once the clients’ inputs are in F

AB-MPC

and ready

to be used, the servers can compute the squared dis-

tance and compare it to R

(step 2). All this is triv-

ially done using commands supported by F

AB-MPC

The outcome of this comparison, ρ, which is also the

result of matching, is stored in JρK

inside F

AB-MPC

At this point, the only thing that needs to be done is

revealing the result JρK

to Alice (without leaking

anything to anyone else). To achieve this, we mask it

with Alice’s random bit µ and open the masked value

′

(step 3) to both servers. Since the value is masked,

the servers cannot learn anything about it. Moreover,

since both servers hold a copy of the masked result,

none of them can modify it without getting caught.

Both servers forward ρ

′

to Alice (step 4), who makes

sure that both servers sent the same value, and un-

masks it to obtain the matching result ρ (step 5).

Security Proof. The security proof of CatNap is

obtained by combining the proofs of the underlying

techniques which we employ (Figure 2). We discuss

it in more detail in the extended version of this paper

(Oleynikov et al., 2022).

4 EVALUATION

To evaluate the performance of CatNap, we im-

plemented it in the MP-SPDZ (Keller, 2020) cryp-

tographic framework and made it available online

(Oleynikov et al., 2022). We compare its performance

to InnerCircle, ABY

and ABY

, OLIC. Because

of the inherent similarity between InnerCircle and

OLIC, we run only OLIC in our benchmarks and ar-

gue that most of the conclusions we make here about

OLIC hold for InnerCircle as well. For the perfor-

mance comparison, we focus total execution time (on

a single CPU core) and on total data exchanged by

parties.

To achieve a fairer comparison, we ran all the pro-

tocols on the same Linux machine having Intel(R)

Core(TM) i7-8700 CPU and 32 GB of RAM. For each

of the protocols we run here we use the implementa-

tion provided by their original papers: the C++ imple-

mentation using ABY (Demmler et al., 2015) frame-

work for ABY

and ABY

, the Python implemen-

tation using the GMP library for OLIC. Although the

protocols are implemented using different tools, the

bulk of their computations is done by low-level C li-

braries (and the communication cost is independent

of the tools), such comparison is useful nevertheless.

We do not introduce any intentional network latency,

all the parties are executed on the same machine (one

CPU core per party) and communicate through loop-

back network device. The following list shows the pa-

rameters with which we instantiated each of the pro-

tocols.

CatNap: Leveraging Generic MPC for Actively Secure Privacy-enhancing Proximity Testing with a Napping Party

243

OLIC. We use the most efﬁcient one of the two

instantiations presented in the original paper

(Oleynikov et al., 2020), namely, the (EC) which

is based on Curve25519 and M383 elliptic curves.

ABY

and ABY

. We use ABY (Demmler et al.,

2015) parameters of the original paper (J

arvinen

et al., 2019): bits = 64, secparam = 128. In

other words, the values domain is 2

and the sym-

metric security key length is 128 bits.

CatNap. We instantiate DPDZ2k and Tinier with the

security parameter of 64 bits, and plaintext values

of SPDZ2k consist of 64 bits. The statistical se-

curity parameter for edaBits is 40.

We do not include the performance of clients in

our benchmarks of CatNap since it is negligible; as

can be seen on Figures 5 and 4, the total communica-

tion cost for each client does not exceed 2(3σ+4k +

1) bits (which is 51 bytes for k = 20 and σ = 40),

0 2,000 4,000

Number of repetitions

Total communication [MB]

Communication for B = 4

Communication for B = 5

(a) Total communication

0 2,000 4,000

0.05

0.1

Number of repetitions

Wall-clock running time [s]

Running time for B = 4

Running time for B = 5

(b) Running time

Figure 6: Amortized performance of CatNap by the number

of repetitions.

and the computation cost constitutes a small number

of Boolean operations.

Figure 6 shows the amortized performance of

server in CatNap depending on the number of times

the protocol is executed. These measurements include

both setup time and the actual protocol execution. As

the number of repetitions approaches 4000, the amor-

tized execution time reaches 0.03 seconds, and the to-

tal communication cost reaches 5.6 MB. We use these

two numbers as constants in the next plots, where we

compare CatNap to other protocols. The B parameter

present on the plots is internal to the edaBits; smaller

values of B are expected to provide better asymptotic

performance.

The performance of OLIC depends on the speciﬁc

value used for the radius R, this is reﬂected in the mea-

surements presented on Figure 7. The protocols that

200 400

Radius R

Total communication [KB]

CatNap

OLIC

ABY

0 20 40

80 100

−2

−1

Radius R

Wall-clock running time [s]

OLIC servers

OLIC clients

CatNap servers

ABY

clients

ABY

clients

Figure 7: Comparison of CatNap with OLIC, ABY

and

ABY

SECRYPT 2022 - 19th International Conference on Security and Cryptography

244

have performance independent of R are shown there

as straight horizontal lines. Notably, CatNap is less

efﬁcient than ABY

and ABY

(we consider it a

minor price to pay since CatNap achieves active secu-

rity), but it still becomes more efﬁcient than OLIC for

large enough values of R.

5 RELATED WORK

Zhong et al. (Zhong et al., 2007) propose the Louis,

Lester and Pierre protocols for location proximity.

The Louis protocol computes the distance between

Alice and Bob using additively homomorphic encryp-

tion. It relies on a third party to perform the PT, and

Bob must be present online to perform the PT. The

Lester protocol does not use a third party but rather

than performing PT computes the actual distance be-

tween Alice and Bob. The Pierre protocol divides the

space into a grid of cells and reveals the cell distance

between Alice and Bob. All three protocols are only

passively secure.

Narayanan et al. (Narayanan et al., 2011) present

protocols for PT. They cast the PT problem as equality

testing on a grid system of hexagons. One of the pro-

posed protocols utilizes an oblivious server. Parties in

this protocol use symmetric encryption, which leads

to better performance. However, this requires having

preshared keys among parties, which is less amenable

to one-to-many PT. Saldamli et al. (Saldamli et al.,

2013) build on the protocol with the oblivious server

and suggest optimizations based on properties from

geometry and linear algebra. Nielsen et al. (Nielsen

et al., 2012) and Kotzanikolaou et al. (Kotzanikolaou

et al., 2016) also propose grid-based solutions.

Hide&Crypt by Freni et al. (Freni et al., 2010)

splits proximity into two steps. First, it performs ﬁl-

tering between a third party and the initiating princi-

pal. Second, the two principals execute computation

to achieve ﬁner granularity. In both steps, the gran-

ule in which a principal is located is sent to the other

party. C-Hide&Hash by Mascetti et al. (Mascetti

et al., 2011) is a centralized protocol, where the prin-

cipals do not need to communicate pairwise but oth-

erwise share many aspects with Hide&Crypt. Friend-

Locator by

Sik

snys et al. (Siksnys et al., 2009) is a

centralized protocol where clients map their positions

to different granularities, similarly to Hide&Crypt,

but instead of reﬁning via the second principal, each

iteration is done via the third party. VicinityLocator

also by

Sik

snys et al. (Siksnys et al., 2010) is an ex-

tension of FriendLocator, which allows the proximity

of a principal to be represented not only in terms of

any shape.

Sed

enka and Gasti (Sedenka and Gasti, 2014) ho-

momorphically compute distances using the UTM

projection, ECEF (Earth-Centered Earth-Fixed) coor-

dinates, and the Haversine formula that makes it pos-

sible to consider the curvature of the Earth. Hallgren

et al. (Hallgren et al., 2015) introduce InnerCircle for

parallelizable decentralized PT, using additively ho-

momorphic encryption between two parties that must

be online. The MaxPace (Hallgren et al., 2016) proto-

col builds on the speed constraints of an InnerCircle-

style protocol as to limit the effects of trilateration

attacks. Polakis (Polakis et al., 2015) study differ-

ent distance and proximity disclosure strategies em-

ployed in the wild and experiment with practical ef-

fects of trilateration.

Sakib and Huang (Sakib and Huang, 2016) ex-

plore PT using elliptic curves. They require Alice

and Bob to be online to be able to run the proto-

col. J

arvinen et al. (J

arvinen et al., 2019) design ef-

ﬁcient schemes for Euclidean distance-based privacy-

preserving location proximity, as well as schemes for

polygon-based matching. They demonstrate perfor-

mance improvements over InnerCircle. Yet the re-

quirement of the two parties being online applies to

their setting as well. Hallgren et al. (Hallgren et al.,

2017) show how to leverage PT for endpoint-based

ridesharing, building on the InnerCircle protocol, and

compare this method with a method of matching tra-

jectories. Oleynikov et al. (Oleynikov et al., 2020)

build OLIC, a natural extension of InnerCircle to

the two-server setting to perform Euclidean distance-

based matching. They also propose the “napping

party” model with two servers that formalizes the pos-

sibility for parties to submit their locations at indepen-

dent moments of time. The “napping party” setting

requires that the clients communicate with servers at

disjoint intervals of time and that they do not share

any secret data (e.g. cryptographic keys) before the

protocol starts. It is necessary to have at least two

servers to achieve this property. As shown by Hal-

levi et al. (Halevi et al., 2011), using one server for

this purpose will leak the clients’ data to it. Further

works on generic MPC in client-server settings (Jar-

rous and Pinkas, 2013; Gordon et al., 2013; Halevi

et al., 2017; Beimel et al., 2014; Benhamouda et al.,

2017) also consider one-server scenarios. Some of

these protocols are mentioned in Table 1.

The main challenge of Euclidean distance-based

PT is efﬁciently combining the arithmetic operations

(like computing the squared distance) with the com-

parison operation; many existing tools for multiparty

computation tend to be efﬁcient only for one of the

two kinds of operations, and performing the other

one introduces great overhead. To overcome this, we

CatNap: Leveraging Generic MPC for Actively Secure Privacy-enhancing Proximity Testing with a Napping Party

245

use state-of-the-art MPC techniques: SPDZ2k proto-

col for arithmetic computation (Cramer et al., 2018),

Tinier (Frederiksen et al., 2015) for Boolean compu-

tation and edaBits (Escudero et al., 2020) for convert-

ing values between Boolean and arithmetic domains.

In the wake of the COVID-19 pandemic, privacy-

preserving PT witness a boom of protocols that rely

on Bluetooth communication (Troncoso et al., 2020).

These solutions realize PT without relying on know-

ing the exact location of clients. Such solutions are

effective only for shorter radius (Bluetooth range) and

the distance between users cannot be accurately com-

puted (e.g., signal strength varies in the presence of

physical barriers and with weather conditions). In

contrast, this work does not rely on a speciﬁc tech-

nology (e.g., Bluetooth communication) and aims at

providing precise matching using the Euclidean dis-

tance. Protocol-based solutions which are the focus

on this work aim to privately implement the partial

functionality of global services like social networks,

messengers and taxi services.

To summarize, most (Zhong et al., 2007; Siksnys

et al., 2009; Siksnys et al., 2010; Freni et al., 2010;

Narayanan et al., 2011; Saldamli et al., 2013; Sedenka

and Gasti, 2014; Hallgren et al., 2015; Oleynikov

et al., 2020; Hallgren et al., 2016; Sakib and Huang,

2016; J

arvinen et al., 2019) of the existing approaches

to proximity testings require both parties to be on-

line or requires clients to share common keys before

the protocol starts, thus not being suitable for one-

to-many matching, and also provide only passive se-

curity, limiting the practical applicability of the pro-

tocol. A notable exception to the work above is the

C-Hide&Hash protocol by Mascetti et al. (Mascetti

et al., 2011), which allows one-to-many testing, yet

at the price of not computing the precise proximity

result but its grid-based approximation. Generally, a

large number of approaches (Zhong et al., 2007; Sik-

snys et al., 2009; Siksnys et al., 2010; Freni et al.,

2010; Mascetti et al., 2011; Narayanan et al., 2011;

Nielsen et al., 2012; Kotzanikolaou et al., 2016) resort

to grid-based approximations, thus losing precision of

proximity tests.

6 CONCLUSION

We presented CatNap, a secure and privacy-

enhancing protocol for PT, which performs exact

Euclidean distance-based matching. CatNap solves

some of the major issues previous similar works suf-

fered from: its performance does not depend on the

proximity radius; it is secure against active adver-

saries; and it does not require clients to be simultane-

ously online for the PT to run. Our evaluation results

conﬁrm that the amortized performance of CatNap is

practical: the running time per repetition is close to

negligible, and the communication cost is around a

few megabytes.

Our approach is trivially augmentable to support

time-based matching (Pagnin et al., 2019), i.e. to al-

low clients to submit the time interval during which

they plan to be in the speciﬁed location and make the

protocol match them only if the locations are close

and the time intervals intersect. This can be use-

ful for friend-ﬁnding services as well as taxi appli-

cations (e.g. BlaBlaCar (Bla, 2022)), where drivers

need to pick up the passengers at the right time (and

get the actual passenger location if the matching suc-

ceeded). We also allow one-to-many matching via the

“napping party” feature, since the servers can reuse

Alice and Bob’s locations multiple times. For exam-

ple, Bob can submit his location to the servers and

let them match him with any of his friends, yielding

a single bit of the result or a list of all of his friends

who are nearby. In the case of one-to-many matching,

the overhead of our approach will grow linearly in the

number of clients for the servers and stay constant for

the clients. Also, since the protocol already relies on

one of the servers being honest, this fact can be used

to implement a ﬁne-grained policy to control whom

a certain client can be matched with, track the exact

time when the client has submitted their location to

the servers (to show the other clients how fresh it is),

or let the client see who requested matching with them

while they were ofﬂine; these features are orthogonal

to our work and are dependent on a speciﬁc applica-

tion scenario.

CatNap can be easily generalized to use more than

two servers, so that it stays secure as long as at least

one of the servers is honest. This signiﬁcantly weak-

ens the security assumption it depends on, making the

protocol more reliable at a cost of some performance

overhead. Since the real-life purpose of having two

servers was to allow distributing trust between two

independent organizations that are providing the LBS

together, distributing it over a larger number of orga-

nizations makes breaking it harder.

We leave a more extensive evaluation of CatNap’s

performance in the presence of realistic network la-

tency for the future work, as well as the evaluation of

time-based matching.

ACKNOWLEDGMENTS

This work was partially supported by the Wallen-

berg AI, Autonomous Systems and Software Program

SECRYPT 2022 - 19th International Conference on Security and Cryptography

246

(WASP) funded by the Knut and Alice Wallenberg

Foundation, the Swedish Foundation for Strategic Re-

search (SSF), the Swedish Research Council (VR),

and the Excellence Center at Link

oping – Lund in In-

formation Technology (ELLIIT).

REFERENCES

Beimel, A., Gabizon, A., Ishai, Y., Kushilevitz, E.,

Meldgaard, S., and Paskin-Cherniavsky, A. (2014).

Non-interactive secure multiparty computation. In

CRYPTO, LNCS.

Benhamouda, F., Krawczyk, H., and Rabin, T. (2017). Ro-

bust non-interactive multiparty computation against

constant-size collusion. In CRYPTO, LNCS.

Bla (2022). BlaBlaCar - Trusted carpooling. https://www.

blablacar.com/.

Canetti, R. (1998). Security and composition of multi-party

cryptographic protocols. ePrint. https://eprint.iacr.org/

1998/018.

Cole, S. (2019). Yahoo engineer used insider

access to get private photos of women.

https://www.vice.com/en/article/59nwyk/yahoo-

engineer-used-insider-access-to-get-private-photos-

of-women. [Online; accessed 22-Mar-2022].

Cox, J. (2019). Snapchat employees abused data ac-

cess to spy on users. https://www.vice.com/en/

article/xwnva7/snapchat-employees-abused-data-

access-spy-on-users-snaplion. [Online; accessed

22-Mar-2022].

Cox, J. and Hoppenstedt, M. (2018). Sources: Face-

book has ﬁred multiple employees for snooping

on users. https://www.vice.com/en/article/bjp9zv/

facebook-employees-look-at-user-data. [Online; ac-

cessed 22-Mar-2022].

Cramer, R., Damg

ard, I., Escudero, D., Scholl, P., and Xing,

C. (2018). Spdz2k: Efﬁcient mpc mod 2

for dishon-

est majority. In CRYPTO.

Demmler, D., Schneider, T., and Zohner, M. (2015). ABY -

A framework for efﬁcient mixed-protocol secure two-

party computation. In NDSS.

Escudero, D., Ghosh, S., Keller, M., Rachuri, R., and

Scholl, P. (2020). Improved primitives for mpc over

mixed arithmetic-binary circuits. In CRYPTO.

Frederiksen, T. K., Keller, M., Orsini, E., and Scholl, P.

(2015). A uniﬁed approach to mpc with preprocessing

using ot. In ASIACRYPT.

Freni, D., Vicente, C. R., Mascetti, S., Bettini, C., and

Jensen, C. S. (2010). Preserving location and absence

privacy in geo-social networks. In CIKM.

Gordon, S. D., Malkin, T., Rosulek, M., and Wee, H.

(2013). Multi-party computation of polynomials and

branching programs without simultaneous interaction.

In EUROCRYPT, LNCS. Springer.

Halevi, S., Ishai, Y., Jain, A., Komargodski, I., Sahai, A.,

and Yogev, E. (2017). Non-interactive multiparty

computation without correlated randomness. In ASI-

ACRYPT, LNCS.

Halevi, S., Lindell, Y., and Pinkas, B. (2011). Secure com-

putation on the web: Computing without simultane-

ous interaction. In CRYPTO.

Hallgren, P., Orlandi, C., and Sabelfeld, A. (2017). Pri-

vatePool: Privacy-Preserving Ridesharing. In CSF.

Hallgren, P. A., Ochoa, M., and Sabelfeld, A. (2015).

InnerCircle: A parallelizable decentralized privacy-

preserving location proximity protocol. In PST.

Hallgren, P. A., Ochoa, M., and Sabelfeld, A. (2016). Max-

Pace: Speed-Constrained Location Queries. In CNS.

Hern, A. (2016). Uber employees ’spied on ex-partners,

politicians and beyonc

e’. https://www.theguardian.

com/technology/2016/dec/13/uber-employees-

spying-ex-partners-politicians-beyonce. [Online;

accessed 22-Mar-2022].

Jakobsen, T. P., Nielsen, J. B., and Orlandi, C. (2014). A

framework for outsourcing of secure computation. In

ACM CCSW.

Jarrous, A. and Pinkas, B. (2013). Canon-mpc, a system for

casual non-interactive secure multi-party computation

using native client. In WPES. ACM.

arvinen, K., Kiss, A., Schneider, T., Tkachenko, O., and

Yang, Z. (2019). Faster privacy-preserving location

proximity schemes for circles and polygons. IET In-

formation Security, 14.

Keller, M. (2020). Mp-spdz: A versatile framework for

multi-party computation. In ACM SIGSAC.

Kotzanikolaou, P., Patsakis, C., Magkos, E., and Korakakis,

M. (2016). Lightweight private proximity testing for

geospatial social networks. Computer Communica-

tions.

Lindell, Y. (2016). How to simulate it - a tutorial on the

simulation proof technique. ePrint. https://eprint.iacr.

org/2016/046.

Mascetti, S., Freni, D., Bettini, C., Wang, X. S., and Jajodia,

S. (2011). Privacy in geo-social networks: proximity

notiﬁcation with untrusted service providers and curi-

ous buddies. VLDB J.

Narayanan, A., Thiagarajan, N., Lakhani, M., Hamburg,

M., and Boneh, D. (2011). Location privacy via pri-

vate proximity testing. In NDSS.

Nielsen, J. D., Pagter, J. I., and Stausholm, M. B. (2012).

Location privacy via actively secure private proximity

testing. In PerCom Workshops. IEEE CS.

Oleynikov, I., Pagnin, E., and Sabelfeld, A. (2020). Where

are you Bob? Privacy-Preserving Proximity Testing

with a Napping Party. In ESORICS.

Oleynikov, I., Pagnin, E., and Sabelfeld, A. (2022). Cat-

nap: Leveraging generic mpc for actively secure

privacy-enhancing proximity testing with a napping

party (extended version). https://www.cse.chalmers.

se/research/group/security/catnap/.

Pagnin, E., Gunnarsson, G., Talebi, P., Orlandi, C., and

Sabelfeld, A. (2019). TOPPool: Time-aware Opti-

mized Privacy-Preserving Ridesharing. PoPETs.

Polakis, I., Argyros, G., Petsios, T., Sivakorn, S., and

Keromytis, A. D. (2015). Where’s wally?: Precise

user discovery attacks in location proximity services.

In CCS.

CatNap: Leveraging Generic MPC for Actively Secure Privacy-enhancing Proximity Testing with a Napping Party

247

Rotaru, D. and Wood, T. (2019). Marbled circuits: Mixing

arithmetic and boolean circuits with active security. In

INDOCRYPT 2019.

Sakib, M. N. and Huang, C. (2016). Privacy preserving

proximity testing using elliptic curves. In ITNAC.

Saldamli, G., Chow, R., Jin, H., and Knijnenburg, B. P.

(2013). Private proximity testing with an untrusted

server. In WISEC. ACM.

Sedenka, J. and Gasti, P. (2014). Privacy-preserving dis-

tance computation and proximity testing on earth,

done right. In AsiaCCS.

Sharemind (2022). Sharemind MPC Platform.

https://sharemind.cyber.ee/sharemind-mpc/multi-

party-computation/.

Siksnys, L., Thomsen, J. R., Saltenis, S., and Yiu, M. L.

(2010). Private and ﬂexible proximity detection in

mobile social networks. In MDM.

Siksnys, L., Thomsen, J. R., Saltenis, S., Yiu, M. L., and

Andersen, O. (2009). A location privacy aware friend

locator. In SSTD.

Troncoso, C., Payer, M., Hubaux, J.-P., Salath

e, M.,

Larus, J., Bugnion, E., Lueks, W., Stadler, T., Pyrge-

lis, A., Antonioli, D., et al. (2020). Decentralized

privacy-preserving proximity tracing. arXiv preprint

arXiv:2005.12273.

Zhong, G., Goldberg, I., and Hengartner, U. (2007). Louis,

lester and pierre: Three protocols for location privacy.

In PET.

SECRYPT 2022 - 19th International Conference on Security and Cryptography

248