[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: gnunet and digital contact tracing apps for COVID-19
From: |
Jeff Burdges |
Subject: |
Re: gnunet and digital contact tracing apps for COVID-19 |
Date: |
Mon, 6 Apr 2020 17:04:08 +0200 |
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