3 ms·
I think it has a flaw: if you find out you are infected mid-day, then if you reveal your key for the day others can impersonate you for the rest of the day, and
by devit 6y ago
I think it has a flaw: if you find out you are infected mid-day, then if you reveal your key for the day others can impersonate you for the rest of the day, and if you don't those who you had contact with in the first part of the day won't be notified.
So my suggestion for a minimal fix would be to also reveal all advertised rolling IDs for the current day in addition to the keys for the past days.
A better fix would be to generate ID in a hierarchical fashion from the daily keys with power-of-two-length time slots, so that you only need to share O(d + log(n)) values where d is the number of days and n is the number of subdivisions in a day.
Another potential fix is to use public-key cryptography and only reveal the daily public keys; however, this requires twice as large IDs and matching requires to try to decrypt/signature-check all received IDs instead of being able to generate and lookup.
- The_Double 6y agoA simple solution using virus properties would be to just delay the release of the last id. It takes a while before the viral load inside someone becomes high enough to be infectious, so there is no significant harm in the last id being delayed by 24h in the worst case.
- tastroder 6y agoYour suggestions don't seem different from what the spec already describes. Tests are not immediate and the incubation period of the disease dictates that you have to share multiple diagnosis keys (days) of infected persons anyway. You don't have to share timeslots within a day, they can be derived from the daily key. Impersonation risk is unlikely, whatever health authority applies can just invalidate all newly identified keys from generating new contacts, preventing replay attacks derived from known infected with simple and coarse timestamps.