Hello Giovanni, We want a private contact tracing tool faster than GNUNet can reasonably deploy one, but..
There is a separate concern that health worries might dissuade cash usage, but users have zero privacy in existing electronic payment infrastructure. In reality, I’d expect that avoiding cash would just weaken everyone’s immunity, but.. Among the privacy preserving payment options, GNU Taler looks closer to deployment than most designs with reasonable scalability. Any discussion about that should happen on the [email protected] mailing list. I raised this issue at https://github.com/DP-3T/documents/issues/51 since the DP-3T repo has deteriorated into a general discussion forum. Just fyi, there are private blockchain based payment schemes like ZCash, and some ideas for making them scalable, but actually doing this looks more than one year away. Among the “layer two” blockchain scaling solutions, those with working code lack any privacy. As for private contact tracing, there are currently 2-3 design categories being discussed: Ratchet designs like https://github.com/Co-Epi/CEN https://github.com/DP-3T/documents and https://github.com/ito-org/STRICT At present, these leak infected user movements, which causes issues, but we've two plausible improvements: First, one should replace the hash iteration ratchet with a tree-like “ratchet”, so that users can segment their revels however they like, or even exclude time periods, and need not commit to their reveal time periods in advance. I proposed this inthe CEN issue https://github.com/Co-Epi/CEN/issues/40 If the phone recorded GPS data then you can automate segmenting or exclusion somewhat. If we can only broadcast one 16-26 byte bluetooth id every minute then we’ve only 1440 per day, so the binary tree has depth 11 if we rotate once per day. We should worry about the information leaked by using varying depths of course. Infected people proving their tree reveals to be correct gets tricky, unless you go for SNARKs and SNARK friendly hash functions, but not sure if that’s really a concern. Second, one should consider using cuckoo filters instead of revealing ratchet chains. We need more data if we reveal a cuckoo filter, but like maybe 2-4 bytes per minute per infected person, although not sure exactly how one communicates this optimally. We’d incur more false positives too of course, but I have not yet worked out the trade off, but cuckoo filter are more efficient than bloom filters for reasonable false positive rates. Source routed mixnet designs like https://github.com/TracingWithPrivacy/paper We seemingly cannot broadcast enough data over bluetooth to just broadcast SURBs, which sucks because that design gives basically the best of all worlds: https://github.com/TracingWithPrivacy/paper/issues/10 We’d want 114 bytes SURBs erasure coded into 16-26 bytes bluetooth broadcasts, but we cannot wait 8+ minutes for bluetooth to communicate that. If anyone can figure out how to broadcast 114 bytes over bluetooth then you’re my hero. :) We should work out parameters for clients to fetch SURBs over the mixnet, which avoids the 20k open mailboxes per user problem of the existing mixnet designs. We can discuss this more at https://github.com/TracingWithPrivacy/paper/issues/11 but incurs substantial mixnet traffic. I think this might work GPS only too, no bluetooh, which may prove important if iOS proves uncooperative, but GPS only probably kills the mixnet. We should dig into some non-source routed mixnet designs too, not because this looks like voting, but because we’ve highly bespoke authentication requirements. Ain’t my field of expertise. I’ll copy one message from Bryan Ford aobut this topic below. Best, Jeff > On 3 Apr 2020, at 10:58, Ford Bryan <[email protected]> wrote: > > Hi Jeff et al, > > Good to hear from you, and nice to hear you’re thinking about this important > hot topic as well. :) > > My group members David, Henry, Simone, and Lefteris (cc’d) have also been > thinking about this a bit internally; they might like to respond. Also, I > had a nice chat just yesterday about this with Aileen Nielsen > <[email protected]>, a Fellow at the Center for Law & Economics at > ETHZ, about the complex and interesting legal and policy aspects of this. > > A couple technical precedent works that seem related are the SDDR/Encounters > work from MPI-SWS a few years ago > (https://www.usenix.org/conference/usenixsecurity14/technical-sessions/presentation/lentz), > and Aaron Johnson’s “Privacy-Preserving Lawful Contact Chaining” design at > Yale, which I co-advised with Joan Feigenbaum > (https://dedis.cs.yale.edu/dissent/papers/wpes16-chaining-abs/). Neither of > these were motivated by virus pandemics, of course, but some of the > background techniques might be useful. > > Finally, a "Pan-European Privacy-Preserving Proximity Tracing” was just > announced, which I know involves my colleagues Carmela Troncoso > <[email protected]> and Mathias Payer <[email protected]> and a > number of others, but I don’t yet have more details or internal information, > and the website is still pretty sparse: https://www.pepp-pt.org > > For my part, while I’m interested in the topic, I kinda suspect there are > “way too many cooks in the kitchen” already, so I’m happy to follow and > perhaps help as I can with any interesting developments, I don’t plan on > jumping into this in a big way at the moment. :) > > Cheers > Bryan > On 6 Apr 2020, at 14:52, Giovanni Biscuolo <[email protected]> wrote: > > Dear developers, > > as you already know for sure, in this crisis threre is a pile of > projects [1] aimed at developing privacy and anonimity tools to help > clinical contact tracing [2] to contrast the spread of the epidemy. > > One I'm looking at more deeply is PEPP-PT: Pan-European Privacy > Preserving Proximity Tracing [3] and I think the issues [4] and this > interesting analysys by Enrico Nardelli [5] tells a lot about the > current situation for all this class of projects. > > I think this sort of things are at risk to become digital solutionism, > but I also think that gnunet and secushare.org *could* be a strong > background to consider to _not_ repeat the same technical errors *and* > discussions again, and again... and again :-( > > > Please is there any of the developers in this list that is in some way > involved in the analisys and/or development of this kind of applications > possibly reusing the vast bibliography and the feew tools already > available? > > Have some of the developers been contacted for consultancy in one of > this projects? > > Thanks! Giovanni. > > > > [1] one list: https://github.com/shankari/covid-19-tracing-projects > > [2] https://en.wikipedia.org/wiki/Contact_tracing > > [3] https://www.pepp-pt.org/ > > [4] https://github.com/DP-3T/documents/issues > > [5] > https://link-and-think.blogspot.com/2020/04/how-pepp-pt-solution-aiming-at-fighting.html > > -- > Giovanni Biscuolo > > Xelera IT Infrastructures
signature.asc
Description: Message signed with OpenPGP
