3 ms·

> 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 previousl

> 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%20Paper.pdf https://github.com/DP-3T/documents/blob/master/DP3T%20White%...

FabHK 7y ago
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.
- sratner 7y ago
  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).
  - FabHK 7y ago
    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.
sratner 7y ago
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.
- Confiks 7y ago
  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.
skaul 7y ago
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.

FabHK 7y ago

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.

sratner 7y ago
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).
- FabHK 7y ago
  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.

sratner 7y ago

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.

Confiks 7y ago
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.

skaul 7y ago

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.