2
$\begingroup$

At

an easy to understand way was presented how such contact tracing apps work from a cryptographical point of view as it lets users simulate the process.

The "Background" tab at the 2nd webpage describes the differences in the two protocols DP-3T (European approach) and Exposure Notification (Google/Apple) in more details.

Q1: As I understand, the difference is marginal from a cryptographical point of view. Is this really true?

Q2: The 2nd webpage is the first page I saw containing a detailed comparison of the two protocols. Are there other sources for a detailed comparison too (again I am asking only for the cryptographical aspects of the protocols)?

$\endgroup$

2 Answers 2

1
$\begingroup$

I'm not aware of websites providing a detailed comparison. Note, in particular, that DP-3T is not one, but three different proposals, and the Google-Apple system is an API specifying structural requirements for a contact tracing app, rather than a full-fledged application.

However, the DP-3T white paper is fairly detailed and explains in a very readable way how each of the three proposals work. It can be found here :https://github.com/DP-3T/documents/blob/master/DP3T%20White%20Paper.pdf.

As for the main differences between DP-3T and Apple-Google: DP-3T already provides an in-depth comparison between their three proposals in the white paper. Out of the three, the hybrid design is very close in spirit to the Apple Google proposal. To my knowledge, there are essentially two main differences between the Apple-Google proposal and DP-3T's hybrid design:

  • Both require to upload and publicly reveal session keys, from which several ephemeral IDs are derived, corresponding to some fixed time-period. However, the hybrid design allows a variable duration for the session key, and recommends 2 to 4 hours, while the Apple-Google recommends a 24 hours window. To explain why this matters: 1) the smaller the window, the larger the amount of material each user must download on a daily basis (numbers are given on the white paper and depend on the number of daily new cases). 2) however, a user is traceable for the time of the window, in the following sense: if two users have been in contact with the same user with the same time period, they both know the same session key from which the ephemeral IDs broadcasted during this period have been generated, hence they both know that they have been in contact with the same infected user. Of course, the smaller the time window, the less of a real concern this is. Hence, the choice of the time window is a tradeoff between efficiency and traceability.
  • DP-3T allows to redact your upload. This means that it gives you the opportunity, when you are infected, to not upload some of your session keys. This is useful for example if you've been on a one-to-one job interview for two hours: you might want to not upload the session key corresponding to those two hours, since the interviewer might have turned on his phone during this period alone and therefore learn whether you are infected, breaking anonymity. The Apple-Google app does not allow for this.

Otherwise, the exact choice of cryptographic primitives might differ very slightly for generating the ephemeral ideas (and hashing, for the variants that involve hashing), but honestly it does not matter, all use standard and well-established cryptographic primitives in a correct way.

$\endgroup$
1
  • $\begingroup$ thanks a lot for the clear and helpful answer. $\endgroup$
    – Yves
    Commented Jun 12, 2020 at 9:38
0
$\begingroup$

A recent survey on eprint does a decent job of comparing various contact-tracing protocols. According to them, the main difference between DP-3T and the Google/Apple scheme are on an implementation level:

While DP-3T derives the daily key by hashing the key from the day before, Google/Apple combine the initial tracing key with the number of the day in a key derivation function.

and

Another difference is how ephemeral IDs are created. DP-3T derive some value for a whole day by the feeding daily tracing key first into a pseudo-random function like HMAC-SHA256 and then using the result as the input for a stream cipher like AES. Then the output is split into chunks of 16 bytes and shuffled before usage. Google/Apple derive ephemeral BLE IDs independently by feeding the daily tracing key and the number of the current time interval into a pseudo-random function.

$\endgroup$
1
  • $\begingroup$ Thanks for the link to the survey. $\endgroup$
    – Yves
    Commented Jun 15, 2020 at 12:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.