News for hackers. Stuff that matters.
Re:DP-3T/Documents: Decentralized Privacy-Preserving Proximi... by TheSeth on Monday April 13, 2020 @04:11AM (#22854011)
There's also this architecture proposal by the maintainer of iPXE: https://github.com/ipxe/cx
Re:DP-3T/Documents: Decentralized Privacy-Preserving Proximi... by john_payette on Monday April 13, 2020 @04:47AM (#22854161)
Here's a comparison of the Apple-Google solution vs. the PEPP-PT project using this DP-3T approach: https://medium.com/@legfranck/the-good-and-the-bad-of-apple-...
Re:DP-3T/Documents: Decentralized Privacy-Preserving Proximi... by xorfish on Monday April 13, 2020 @05:19AM (#22854278)
I really hope Google and Apple will implement the proposed protocol from DP-3T and give audited and open source apps more control over how the contact tracing is done.
Re:DP-3T/Documents: Decentralized Privacy-Preserving Proximi... by john_payette on Monday April 13, 2020 @05:29AM (#22854320)
I agree. Ideally, the code will be embedded in the Android source code, which is open source. But more likely it will be an update of the Google Play Services, closed-source... But the Cloud code should definitely be open-source. We can count on Google for that.
Re:DP-3T/Documents: Decentralized Privacy-Preserving Proximi... by olliej on Monday April 13, 2020 @02:54AM (#22853718)
Where does this differ from the Apple/google approach? I was reading their doc and it felt like I was re-reading a simplified version of the Apple documentation, with the addition of a traceable-to-the-person healthcare provider authorization code.
Re:DP-3T/Documents: Decentralized Privacy-Preserving Proximi... by the_mitsuhiko on Monday April 13, 2020 @03:25AM (#22853823)
This document predates the Apple and google one.
Re:DP-3T/Documents: Decentralized Privacy-Preserving Proximi... by olliej on Monday April 13, 2020 @04:07AM (#22853992)
Ah, fair enough then :D
Re:DP-3T/Documents: Decentralized Privacy-Preserving Proximi... by u8mybrownies on Sunday April 12, 2020 @09:37PM (#22852341)
a critical review of this approach: https://eprint.iacr.org/2020/399.pdf
Re:DP-3T/Documents: Decentralized Privacy-Preserving Proximi... by xorfish on Monday April 13, 2020 @05:13AM (#22854255)
Some of the attacks seem to be high cost, low payoff.

Have you read the newer version?

There is a new proposal that would protect against most of these attacks.

Re:DP-3T/Documents: Decentralized Privacy-Preserving Proximi... by john_payette on Monday April 13, 2020 @11:09AM (#22856482)
DP-3T admits now that the best solution is the Apple-Google one. They greatly contributed to the design of the A-G solution so kudos to them. After reviewing this critical review of DP-3T, the only attack I see that applies to the Google-Apple solution is the replay attack. It can be fixed easily by the solution proposed by Prof. Serge Vaudenay of EPFL in Section 4.4 of https://eprint.iacr.org/2020/399.pdf. In a nutshell, send a tag along the ephemeral ID. This tag would be a message authentication code (MAC) computed with the ephemeral ID and a coarse timestamp of when it was sent using the sender's key, SKt. When Apple-Google sends out the SKt keys of the infected people to everybody, recipients will go through the ephemeral IDs they saw to look for matches. When there's a match, the tag will also be checked, i.e. does the tag I compute based on the timestamp when I received the ephemeral ID match the tag I received. If yes, then it was sent by this infected person. Otherwise, it's a replay attack and should be discarded.