Skip to content
This repository was archived by the owner on Apr 29, 2020. It is now read-only.

Commit 4c67ac4

Browse files
committed
Update PRESERVE_USER_PRIVACY.md
1 parent 02e4bd6 commit 4c67ac4

File tree

1 file changed

+14
-4
lines changed

1 file changed

+14
-4
lines changed

OPEN_PROBLEMS/PRESERVE_USER_PRIVACY.md

Lines changed: 14 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -107,7 +107,11 @@ Past research has indicated several approaches to anonymisation and privacy, but
107107
- [2012 Octopus: A Secure and Anonymous DHT Lookup](https://ieeexplore.ieee.org/document/6258005)
108108
- [2019 Encrypted Distributed Hash Tables](https://eprint.iacr.org/2019/1126)
109109
- **Traffic Analysis resistant**
110+
- [2009 ShadowWalker: peer-to-peer anonymous communication using redundant structured topologies](https://dl.acm.org/citation.cfm?id=1653683)
110111
- [2015 Vuvuzela: Scalable Private Messaging Resistant to Traffic Analysis](https://davidlazar.org/papers/vuvuzela.pdf)
112+
- **Private Information Retrieval**
113+
- [XPIR : Private Information Retrieval for Everyone](https://eprint.iacr.org/2014/1025.pdf)
114+
- [PIR with compressed queries and amortized query processing](https://eprint.iacr.org/2017/1142.pdf)
111115
- **Other**
112116
- [2018 Cwtch: Privacy Preserving Infrastructure for Asynchronous,Decentralized, Multi-Party and Metadata Resistant Applications](https://cwtch.im/cwtch.pdf)
113117

@@ -117,6 +121,7 @@ Past research has indicated several approaches to anonymisation and privacy, but
117121
Some of the known shortcommings of existing solutions are:
118122

119123
- They don't offer protection against network analysis (it is possible to infer what the user is doing by analysing network traffic)
124+
- Some of the solutions (e.g. OctopusDHT) rely on centralised certificate authorities for reputation management
120125
- Solutions that are more resistant (not fully resistent) typically trade off bandwidth + memory for creating that protection (e.g. creating noise in the network to make it hard to distinguish valid from dummy traffic)
121126
- Lack of data encryption at rest
122127
- Lack of complete authorization + revocation
@@ -137,13 +142,18 @@ Such solutions will bring P2P, decentralised storage and delivery networks to a
137142
138143
Valid solutions should improve the current state of the art or offer definitive solutions for:
139144

140-
- [ ] Two users can transfer a piece of information without any other user knowing or being able to predict: what it is, why it is being transferred, when and between whom.
141-
- [ ] No single central authority are required to mediate the communication
142-
- [ ] A provider has a way to grant and revoke access to information.
145+
- Two users can transfer a piece of information without any other user knowing or being able to predict: what it is, why it is being transferred, when and between whom.
146+
- No single central authority are required to mediate the communication
147+
- A provider has a way to grant and revoke access to information.
148+
- A user can discover public information without leaking information about their interest. An adversary should not be able to link two or more discovery requests either.
143149

144150
As additional constraints
145151

146-
- [ ] Mechanism to prevent data exfiltration (e.g. when a user goes rogue)
152+
- Mechanism to prevent data exfiltration (e.g. when a user goes rogue)
153+
154+
Also, contributions towards solving this Open Problem can be in the form of answers to the following questions:
155+
156+
- How to measure privacy?
147157

148158
## Other
149159

0 commit comments

Comments
 (0)