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

[Jeff Burdges]

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

signature.asc
Description: Message signed with OpenPGP