The goal of COVID-19 exposure notification is to notify people that they were exposed to someone who later tested positive for the virus. Protecting privacy in this process requires some cryptography, and avoiding excessively granular detail on user locations. But providing data useful for disease prevention requires adequate detail in measuring the length of exposures.

There is a new API for such exposure notification from Apple and Google, but it has a tension between 5- and 10-minute numbers that I don't see how to resolve.

The cryptography specification, v1.2.1, specifies 10-minute intervals as inputs to the hash: "in this protocol, the time is discretized in 10 minute intervals that are enumerated starting from Unix Epoch Time. ENIntervalNumber allows conversion of the current time to a number representing the interval it’s in."

Meanwhile the FAQ, v1.1, specifies 5-minute increments in the output: "Public health authorities will set a minimum threshold for time spent together, such that a user needs to be within Bluetooth range for at least 5 minutes to register a match. If the contact is longer than 5 minutes, the system will report time in increments of 5 minutes up to a maximum of 30 minutes to ensure privacy."

How will the system report times in 5-minute increments when the interval numbers are only updated for the hash once every 10 minutes?

  • 1
    I think what Danny is trying to say is that the crypto folks want to think of things at a very low level of the crypto primitives, where the security community wants to think at a higher implementation level. There's obviously crossover between the two, and you'll sometimes get finger-pointing exercises of each community pointing to the other. But I'd hazard a guess that this belongs here more than anywhere else. May 27, 2020 at 17:09

1 Answer 1


While the actual SDK code is not available, we can make an educated guess that the ENIntervalNumber is NOT used to calculate the duration of contact.

Let's step back a minute from the crypto to describe what's actually happening on a person's phone. This is documented here, but to give a quick summary:

  1. Alice who has enabled the app is scanning for bluetooth broadcasts sampling every 5 mins.

    The scanning strategy that works best is opportunistic (leveraging existing wakes and scan windows) and with minimum periodic sampling every 5 minutes.

  2. Bob who has also enabled the app is broadcasting over bluetooth with data containing their Rolling Proximity Identifier (RPI).

  3. Alice's phone detects Bob's broadcast and saves the RPI and metadata. This data is timestamped.

    Scan results shall be timestamped and RSSI-captured per broadcast.

  4. Later when Bob is diagnosed a set of his Temporary Key and ENInterval numbers are send to the diagnosis server that pushes this information to all clients.

  5. Alice's phone receives this information and calculates the RPIs and matches against those stored on her phone. Locally the distance and duration of contact are calculated.

Given that we've got the timestamp and the RPI from step3 it's likely that the calculation of duration is done by simply comparing the timestamps. This will also ensure that the distance and duration data is not revealed to the server or other clients.

  • Thanks for this — this is not what I thought after reading the FAQ’s comments about the role of the public health authorities. So I’ll have to read and digest more this weekend, including that Bluetooth specification, to figure out how much to believe from the official FAQ and from your educated guess.
    – Matt F.
    May 28, 2020 at 8:50
  • @MattF If it helps I don't think this contradicts the FAQ. It just means that the phone will calculate the duration and the app designers (the health authorities in different countries) will decide what action their app presents to the users based on that.
    – AlphaD
    May 28, 2020 at 9:01

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .