FYI: https://www.fiff.de/presse/dsfa-corona There are real flaws in the most discussed EU designs, and these are by far not only technical ones. English version comming soon.
On Mon, 6 Apr 2020 17:04:08 +0200 Jeff Burdges <[email protected]> wrote: > 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 >
pgp_HjFMw1h9B.pgp
Description: OpenPGP digital signature
