gnunet-developers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: gnunet and digital contact tracing apps for COVID-19


From: xrs
Subject: Re: gnunet and digital contact tracing apps for COVID-19
Date: Tue, 14 Apr 2020 12:00:25 +0200

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 <address@hidden> 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 address@hidden 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 <address@hidden> 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 <address@hidden>, 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 <address@hidden> and Mathias Payer
> > <address@hidden> 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 <address@hidden> 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  
> 

Attachment: pgppbMivvUWTj.pgp
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]