Hacker News Reader

Comment by colmmacc | Hacker News Reader

They're not the same and I think Google/Apple's is a bit better. In DP3T the infected person shares a single daily key from which all future daily keys can be derived. In Google/Apple's each daily key is HKDF derived from a master key and they are not linkable. Infected people share the relevant daily keys from their infection period. THat's more data to push around, but it is better for privacy.

It means that contacts with infected persons can't be linked across days, and it means that I can't build an app that alerts me that someone who was previously infected just walked by.

View on HN

> It means that contacts with infected persons can't be linked across days, and it means that I can't build an app that alerts me that someone who was previously infected just walked by.

Edit: This actually turns out to be correct, but your conclusion:

> It means that contacts with infected persons can't be linked across days, and it means that I can't build an app that alerts me that someone who was previously infected just walked by.

Is not possible, because every time secrets are made public, the secret key is reset.

[1] https://github.com/DP-3T/documents/blob/master/DP3T%20White%...

I see: SK_(t) = H(SK_(t-1)), where SK_(t) is the secret key for day t.

This seems to align with the statement that knowing the key for one day (i.e. once it is uploaded following diagnosis) allows one to derive all future keys. Is there another section I am missing?

Edit: clarified that daily keys are shared post-diagnosis, to trace prior contact.

Indeed, sorry. I was under the impression that every daily ratchet-key was independent, and only the inter-day keys were linked. The conclusion of your post still is not possible however. I edited my post.

GP is correct, but it doesn’t matter much. They were referring to daily key, not the EphID (RPI in the Apple/google spec).

DP3T specifies that SK _t = H( SK _{t-1} ). In that design, you share the daily key from when you started to become infectious, and then the subsequent ones can be computed. Then you go into quarantine, stop being infectious, and (see spec) create a new random daily key going forward (or delete the app).

In the A/G proposal, daily keys can’t be correlated, and you share the daily key for each day you were infectious.

The end result seems pretty much the same for me.

The difference is that you can continue tracking a person indefinitely, even after they are no longer infectious. It requires explicit user action to avoid that (opt-out vs opt-in).

If the DP3T app is implemented to spec and creates a new random daily key after the infectious period ends, no.

If the A/G app is not implemented to spec and keeps uploading daily keys even after the infectious period is over, yes.

So, dunno. A/G has a bit more privacy (maybe) for 5x more data volume than DP3T.

With the DP3T derivable day keys, you could identify that you were actually in contact with the same infected person multiple days.

If the server ships 14 * (# of people infected) every day to every user, instead of just (# of people infected) and have the client generate the 14 keys for each infected person, you would only be able to identify that you were in contact with an infected person. With the DP3T proposal, it looks like you can identify that you were around the same infected user multiple days, which might be slightly worse for privacy (in the sense that it would help you identify who you got it from).

But in either case, because the secret key is reset after being made public, it would not help you identify who was previously infected.

Check the second half of the DP3T white paper - the 'high cost' version does not do that, and unlike the Apple/Google version, allows you to redact more specific times of day you do not want to upload, for whatever reason. It is important to also weigh up these issues against daily bandwidth concerns for usability.

Reply on news.ycombinator.com