New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use decentralized discovery (DHT) #3388

Open
calmh opened this Issue Jul 5, 2016 · 44 comments

Comments

Projects
None yet
@calmh
Member

calmh commented Jul 5, 2016

It's probably time to investigate decentralizing discovery. Doing so would reduce our infrastructure burden and reduce centralized knowledge of the network. In a DHT we want to be able to look up the contact details for a given device ID. We want to publish our own contact details into the DHT. We don't necessarily want to make it simple for a passive observer to map the entire network, so it would be nice if the contact details were encrypted. I suggest that we could use a key-value database laid out like:

Key: SHA256(device ID)

Value: The contact details, in protobuf format, encrypted using the device ID as a shared secret.

Given that I know the device ID I'm looking for, I can then hash it and look it up, and decrypt the answer. For other nodes in the network, the data is mostly gibberish as you need to know the device ID it represents to be able to interpret it and reversing the SHA256(device ID) to an actual device ID is not feasible.

As far as an actual implementation goes I've surveyed the Go ecosystem to try to find a suitable DHT package. So far I've not really succeeded. Here are the ones I've looked at and some notes on them; it would be lovely if someone did find or develop a good package for this.

If anyone wants to pick this up and run with it, please do so, and announce yourself in the comments below :)

@calmh calmh added the enhancement label Jul 5, 2016

@calmh calmh added this to the Unplanned (Contributions Welcome) milestone Jul 5, 2016

@AudriusButkevicius

This comment has been minimized.

Member

AudriusButkevicius commented Jul 5, 2016

Ipfs people are using kademila afaik.

Anyways, you still need infrastructure to bootstrap, and how do we perform authentication against other peers being non-malicious, prevent malicious peers from overwriting keys, or even bootstrap server from being malicious?

@calmh

This comment has been minimized.

Member

calmh commented Jul 5, 2016

https://godoc.org/github.com/ipfs/go-ipfs/routing/dht looks quite good, yes, thanks!

Certainly we'll need a couple of bootstrap nodes. But I don't think they need to be as beefy as our current discovery servers, and more importantly they shouldn't need to scale much in the future.

As for the maliciousness I'm not sure. Decentralizing things makes that difficult. The worst case scenario is then being tricked to connect to the wrong place when looking for a certain device ID, blocking discovery of a given device... Certainly the stored value could be signed by the device certificate, and the certificate attached, but that doesn't stop anyone from just uploading a blob of garbage for a given lookup key.

Gnnh: https://github.com/ipfs/go-ipfs/blob/master/routing/dht/dht.go#L19

@raichu

This comment has been minimized.

@cdhowie

This comment has been minimized.

Contributor

cdhowie commented Jul 7, 2016

The worst case scenario is then being tricked to connect to the wrong place when looking for a certain device ID, blocking discovery of a given device...

I don't think that's a feasible attack, since the value would be encrypted by the device ID. Such an attack would have to be targeted against a specific, known device ID -- and for that to even work, your DHT node needs to be the one responsible for SHA256(device ID). And even if you successfully pull that off, the traffic is end-to-end encrypted. All you'd really be able to see (assuming you proxy the data) are the IPs on both sides and the amount of data being transferred. You can kinda do this already by running a public relay server, right?

The "store garbage" attack is much more worrying to me. To my knowledge, the way other DHT networks (torrents for example) combat this problem is by having the key be a hash of the value -- not something we can realistically do here.

@cdhowie

This comment has been minimized.

Contributor

cdhowie commented Jul 7, 2016

The "store garbage" attack is much more worrying to me.

A realization I just had is that any kind of verification mechanism put in place to avoid a garbage attack would have to incorporate a timestamp, or it would be susceptible to a replay attack, where a previous (valid) value is stored under the same key. For mobile clients that are constantly changing IPs, this could prevent any nodes from connecting to them.

@calmh

This comment has been minimized.

Member

calmh commented Jul 7, 2016

I think this will necessarily be some sort of security trade off. We'll gain some security (no need for a trusted middle man who has all the data, harder to DoS, etc) and lose some (harder to prevent false information). But as long as the feasible attack is mostly to prevent lookup against a specific device ID I think it may be worth it. It's just one discovery method among many after all.

@AudriusButkevicius

This comment has been minimized.

Member

AudriusButkevicius commented Jul 7, 2016

Or just DDoS the bootstrapping node...

@calmh

This comment has been minimized.

Member

calmh commented Jul 7, 2016

That could still be fine though, if you could still reach some other device to bootstrap, say via local discovery, or if you're already connected to the network. But sure, agree we need the three geographically diverse bootstrap nodes and it's certainly not bulletproof. But honestly the bigger threat at the moment is probably me screwing up the discovery servers by fatfingering something. :)

@aviau

This comment has been minimized.

Member

aviau commented Jul 14, 2016

That could still be fine though, if you could still reach some other device to bootstrap, say via local discovery, or if you're already connected to the network

One other method around DDoS-ing the bootstrap node is that clients should save all nodes that they know to the disk. Whenever they restart they can try to bootstrap with all of these nodes if the master bootstrap node is down. The bootstrap node is only critical for the fist time the client is started.

@Ferroin

This comment has been minimized.

Ferroin commented Jul 15, 2016

That becomes problematic when dealing with clients with dynamic addresses, you'd need a system with a static address in the network for such a scheme to work reliably, because there's the possibility that all the other systems change address.

@canton7

This comment has been minimized.

Member

canton7 commented Jul 15, 2016

I think @aviau meant all other DHT nodes which that device had discovered, and not all configured Syncthing devices.

There will probably be enough DHT nodes which either have static IPs, or whose IP hasn't changed (most dynamic IPs rarely change in practice) for a node to find one which is still contactable, and so reconnect itself to the network.

@Ferroin

This comment has been minimized.

Ferroin commented Jul 15, 2016

To retain feature parity though, there would need to be an option to run independently of the default bootstrap servers and DHT network. Otherwise, this is functionally a regression for anyone using a custom global discovery server. This becomes even more important if all nodes are expected to participate, especially considering people like me who have to pay for bandwidth and data transfer for our nodes which do have static addresses. Such a situation of paying for bandwidth is a lot more common than you think, an will be the case for almost anyone using cloud hosting or running over a mobile broadband connection, and in fact is much better served by a centralized discovery mechanism like what Syncthing has now.

@aviau

This comment has been minimized.

Member

aviau commented Jul 15, 2016

There will probably be enough DHT nodes which either have static IPs

Exactly. We use this method for Ring.

@masgo

This comment has been minimized.

masgo commented Aug 3, 2016

Maybe a "traditional" DHT is not a good solution. You would have to extend it to have something like aging (for IDs that went away and which do not come back). This would need

Also, most DHTs do not behave well with high churn rates. With today's mobile devices you will have a lot of churn because of unstable mobile connections, unstable WiFi, power-save features of the devices or non-24/7 dial-up connections.

Why don't you start with the low hanging fruits? Peer Exchange! (not necessarily the PEX implementation used by BitTorrent - it also has some drawbacks). The idea would be: enable all devices as discovery/relay server. After initial discovery (via your servers) the devices would know 1 or multiple other devices. The next time they connect, they would try to reach the same address. If one of the old addresses is still working (e.g., because the device has a fixed IP, or because it did not go offline in the meantime) they would connect to it, and this device would introduce them to the other devices.

Thinking of the UI:
You could introduce a simple switch like "this node uses a metered connection, use only as much bandwidth as necessary". This would disable the node being a relay, it would exclude it from the DHT, and maybe even disable it being a discovery server.

@calmh

This comment has been minimized.

Member

calmh commented Aug 3, 2016

I suspect that PEX might not be as useful for us as it is for BitTorrent. In the BT case you have hundreds or thousands of devices that are all interested in the same resource - a given torrent. They already need to track other peers interested in the same thing (for downloads) so it's no extra load to provide this information to other devices as well.

In our case, most devices are not interested in the devices you want to talk to so they won't have the information available.

@masgo

This comment has been minimized.

masgo commented Aug 3, 2016

I agree, but it would work great for every (individual) group of devices which use the same shared folder. IF there is either (a) at least one device with a fixed IP, or (b) at least one device keeps its IP between sessions of the other devices.

If I look at the statistics about syncthing, 18% use the "static addresses" feature and the "Number of Devices in Cluster" is mostly 3 or more.

So, using any device of the group as discovery server and simply contacting all previously known devices would solve the discovery problem for ~18% of the users (or even more). It would also work great in large LAN scenarios where IPs tend to stay the same, but broadcast (and therefore Local Discovery) might be filtered.

The next scenario which I would expect to be quite common is a home setup where one device runs most of the time. The external IP will change from time to time (once/day). If a mobile device would simply try to connect to last know IP it has a very high probability to succeed.

My argument is: it would be cheap to simply try all previously known IPs before contacting a discovery service. If we also save the previously measured RTT, one could wait (for example) 2xRTT before contacting the global discovery.

My approach will certainly not fully replace global discovery, but it might reduce the load greatly.

@Ferroin

This comment has been minimized.

Ferroin commented Aug 3, 2016

Adding on to @masgo's idea: Given a situation with three nodes A, B, and C, it's likely that all three want to share data directly. If B has a fixed address, then it makes sense for it to act as a discovery server among it's peers (for example, A could use B to get info about how to talk to C). If this gets extended to locally discovered peers (ie, if B is on the same network as A, and is already talking to C, then A could get info from B about how to talk to C), it becomes a context limited version of PEX.

@Ferroin

This comment has been minimized.

Ferroin commented Aug 3, 2016

@calmh Also, your argument against using PEX could be applied to a DHT setup as well: All my devices care about is how to talk to the rest of my devices, why should I use my bandwidth and processing power to help your devices find their peers?

@AudriusButkevicius

This comment has been minimized.

Member

AudriusButkevicius commented Aug 3, 2016

And how does the existing discovery system not solve the current problem?
The only beneift of the whole discussion I see so far, is the ability to connect when discovery servers are down, one of the peers has a static address and you happen not to be in LAN, essentially by storing last N addresses for a peer, amd sharing addresses of peers you are aware the other side is interested in after connect.

@masgo

This comment has been minimized.

masgo commented Aug 3, 2016

And how does the existing discovery system not solve the current problem?

The existing system solves this with the global discovery. This is about

reduce our infrastructure burden

@AudriusButkevicius

This comment has been minimized.

Member

AudriusButkevicius commented Aug 3, 2016

I was referring to DHT needing extra bandwidth comment above, not in general, yet that was used as a counter argument.

@calmh

This comment has been minimized.

Member

calmh commented Aug 3, 2016

My argument is: it would be cheap to simply try all previously known IPs before contacting a discovery service.

Absolutely agree. We should do this. In fact, let me create a ticket for that: #3474.

All my devices care about is how to talk to the rest of my devices, why should I use my bandwidth and processing power to help your devices find their peers?

Because then you get to use the distributed discovery mechanism to find your other devices :) In my vision of the DHT each device only keeps a small part of the whole map, so the burden shouldn't be undue.

@Ferroin

This comment has been minimized.

Ferroin commented Aug 3, 2016

@calmh the problem I personally have with that is that there's a lot of people who pay per unit transferred or time used for their network access. It's also not unusual to have transfer caps. Having it as an option is not a bad thing, but making it mandatory is, people will suddenly see Syncthing eating up more of their network bandwidth than before, and potentially costing them more money to use than before.

If we were to implement retrying previously seen addresses prior to discovery, and then have peers share discovery info about their other peers, then the discovery servers would only be needed for bootstrap of a group or for cases when all addresses changed (and possibly for finding relays).

@calmh

This comment has been minimized.

Member

calmh commented Aug 3, 2016

Ah, I think I see what you're getting at now. Having devices within a given cluster share address information about other devices in the same cluster. We should do that of course. I was thinking you meant some sort of exchange with devices that had nothing to do with me. Sorry for being slow.

@subscribernamegoeshere

This comment has been minimized.

subscribernamegoeshere commented Aug 12, 2016

Hi there I probably know way too little about these exact technical details, but what I have been wondering for quite a number of years now, that when during all these years people came up with new incarnations and implementations of their application and networks and distributed stuff, why not use already existing and well estblished dht out there in kind of a parasitic or freeloader freeriding or better say symbiontic ways. For example the bittorrent guys original mainline dht implementation probably the largest biggest and badassiest dht with tens of millions of participating nodes I guess. Azureus/Vuze, vanilla bittorrent client or utorrent and all those use that network for bootstrapping and finding fellow nodes. If I understand this at all, why not implement or use an implementation that takes part in this dht network and then maybe add to it for detecting which nodes once we use that, are offering the requested services, meaning are for example not actual bt nodes but syncthing nodes and so on. Maybe this is all extensible and quite modular for smybiontic and friendly use?

See: http://engineering.bittorrent.com/2013/12/19/dht-bootstrap-update/ http://engineering.bittorrent.com/2013/12/19/dht-bootstrap-update/

Everybody and their brother seem to come up with the need to maintain a dht of their own every few weeks or months, so why not cooperate and all be in one giant dht that can not be taken down and that will or is not only known for copyright trouble or torrenting but for generic use to find nodes in a giant cloud of nodes and their services to be distinguished further down the road after initial lookup inside dht.

Any insightful commands? Does bittorrent.com guys actually allow for their dht to be used? For non-torrenting needs to join their dht maybe as well? Anyone officially talking to them? I remember some long while ago when these similar questions and problems with for example opensource application/project retroshare came up and they actually used a vanilla style bittorrent dht then but created it disjointly from the bittorrent.com guys instead of using and bootstrapping from the existing one already.

Thanks.

P.s. like ages ago there used to be the OpenDHT (opendht.org) testbed public dht on the PlanetLab infrastructure I used to briefly play around with that, and originally become aware about it via maidsafe-dht back then, today maybe at: https://github.com/maidsafe/MaidSafe-DHT , https://en.wikipedia.org/wiki/PlanetLab

@Ferroin

This comment has been minimized.

Ferroin commented Aug 12, 2016

@subscribernamegoeshere I assume you mean aside from the fact that doing so would be a breach of the TOS of all such services, and therefore functionally illegal in almost all jurisdictions worldwide?

In most cases, BitTorrent clients don't even talk to anything owned by the company that owns the copyrights. Most people who serve torrents run their own trackers (which are the bit that handles bootstrapping the DHT network), so there's not anything going back to bittorrent.com most of the time.

Additionally, DHT, like almost any other distributed system, is application specific. DHT as used in BitTorrent wouldn't work for us because we need a different key<->value mapping.

And then there's the fact that DHT is a high-level design. The concept is used in many things, but not all of them can understand each other. DHT as used by BitTorrent is not the same as DHT as used by ipfs for example, and neither would be the same as how Syncthing would use it (BitTorrent and IPFS use different implementations for content lookup, Syncthing would be using it for device discovery).

@subscribernamegoeshere

This comment has been minimized.

subscribernamegoeshere commented Aug 12, 2016

I mean the lowest levels of dht finding other nodes for bootstrapping. I am not talking about torrenting. Read the engineering blog of theirs and look at retroshare, which actually does use the bittorrent dht "cloud" of nodes out there and asks that dht for node addresses to find other nodes and only then tries to talk the retroshare language or retroshare dialect of stuff to the found nodes. I dont exactly know on a tech level how it differentiates the found nodes via the dht if those nodes would be torrent clients or retroshare clients. Thats what I am talking about. I dont know about legality or TOS or whatever, but it would be the task for the developers here to talk to the bittorrent engineers or founders or responsible people out there if their dht can be used in a generic way just to find fellow dht participants. That is my main idea. There are at least two kind of completely disjunct nodes to be found in the bittorrent dht as of today. The torrenting nodes and the retroshare nodes. This is a fact. Look into the reotroshare souces how they do it and what exactly they do. DHT doesnt mean torrenting or copyright infringement or these things as per se. Also the azureus vuze which is opensource as well in some ways if I am not mistaken, also uses the bittorrent mainline dht, via a plugin or extension. So somehow somebody somewhen must have gotton permission or simply did implement in taking part of that bittorrent-owned dht in some way or another. I think, this is the main question here if this would be possible for syncthing as well officially or inofficially or at least tolerated by the bittorrent company of if this is a legitimate use of their dht service. To simply find nodes in decentral ways. And continue from there.

@subscribernamegoeshere

This comment has been minimized.

subscribernamegoeshere commented Aug 12, 2016

as you say exactly, use the probably largest existing and constantly available dht cloud of nodes out there, the bittorrent.com dht, for simply finding nodes. same way as retroshare does. that is what i mean. not to find content of files or anything else, but to merely find fellow nodes, fellow syncthing participants. retroshare does find other retroshare participants quickly this way, so there must be some built in or easily extensible way to filter out or to find the non-torrenting nodes on the bittorrent dht in some way, to distringuish the various type of nodes offering various types of services (e.g. torrenting, non-torrenting, retroshare, syncthing, $yourservice)

@AudriusButkevicius

This comment has been minimized.

Member

AudriusButkevicius commented Aug 12, 2016

As we said, DHT doesn't really work until we iron out tye details, as there is no authentication. Someone can prevent you from connecting by constantly overwriting the key that stores your location with garbage. Or can overwrite all the syncthing keys in the DHT and cause a DDoS on someone.

About reusing someone elses DHT, I am also against it as it it puts control in someone elses hands.
What if bittorrent people decide that syncthing is causing too much competition to btsync and fuck us over by refusing syncthing like connections on the bootstrap nodes?

@subscribernamegoeshere

This comment has been minimized.

subscribernamegoeshere commented Aug 12, 2016

Uhm how does bittorrent bootstrapping then works if any malicious node could simply pollute their dht. Something must be wrong here with reasoning. I am not an expert but their dht and source code is documented so how come the mpaa or someone else has never took down their dht if it was possible at all? Please explain dht to me then maybe I am not understand it or we all have weird misconceptions of it. You can not just write to any arbitrary key on a dht, I think that was an essential basic write and read option back in the days of opendht on planetlabs, they offered two python or something scripts, the one wrote to the dht and the other simply read from it. You protect the write operation of a key by adding a salt or a password, and only via that you can (re)write that key/value, but anyone can read a key/value. Eventually a key/value timesout or gets deprecated and garbagecollected e.g. long time no see host/node/ip/port combination and so on. Am I completely misunderstanding the dht concept and how you would put up a pretty basic and stupid protection of added values? Anyone?

@AudriusButkevicius

This comment has been minimized.

Member

AudriusButkevicius commented Aug 12, 2016

So I don't claim that I understand it works, I claim that I haven't seen anyone answering my question about key overwrites, hence why I raised the point again before we dvelve into which network to use.

As far as I understood, and I might be wrong, was that keys were append only and that was the only protection, but that's somewhat suboptimal for our case, unless individual entries in the value time out separately, rather than the whole value times out at once.

If each entry within the value has a separate timeout, then we might be ok, otherwise for mobile devices it could be an ever growing list of IPs, and then establishing a connection could start to take ages, as the default connection timeout is 10s per IP.

Furthermore it's questionable if we'd want syncthing users to carry torrent hashes just to participate in it.... But maybe there is an egoistic mode where you use it, but don't participate.

@masgo

This comment has been minimized.

masgo commented Aug 14, 2016

@subscribernamegoeshere

Everybody and their brother seem to come up with the need to maintain a dht of their own every few weeks or months, so why not cooperate and all be in one giant dht

By now, I have done some years of research on Peer-to-Peer and distributed systems. I came across many DHT and other systems with similar properties (like distributed rendevous systems), I have also implemented some DHTs. The short answer to your question is: because systems have different requirements and each DHT has a lot of (tuning) parameters.

Some details where systems differ:

  • How is the key determined (fron IP+Port, random, or by some other means)
  • How much data will be stored along each key: a few KBs (for example routing information) or some MBs or even a lot more (like GBs, TBs or even PBs)
  • How stable/reliable are the participants? Will they be only for long periods of time (usually the case with cloud instances) or will they come and go (like in torrent clients) or will they switch between online and offline often (like mobile clients). This is called "churn". Some well known systems (like Chord) are known to deal badly with high churn rates, while other will work great even if 50% of the participants crash at once (like BubbleStorm, developed by my former colleagues)
  • How fast should the lookup be? Most DHTs provide log(number of participants) lookup performance. But there is a difference between log_2 and log_10. One might also optimize in such a way that each step has a lower RTT (instead of the average RTT between all participants). Should each lookup have (roughly) the same lookup time, or do we optimize for faster lookups of popular items?
  • What kind of lookup operations do we support? Only key-value (like many "traditional" DHTs), range queries on the key, multi-key lookup, keyword search on the data or even arbitrary queries (SQL-like queries or RegExp) on the data?
  • Each system will cause an overhead in bandwidth. How high can this overhead be? Should the bandwidth consumption be the same for all nodes or will nodes with higher bandwidth also make use of it?
  • What replication model/properties do I want? Will it be persistent? Should it be short-term or long-term storage? Should only the original publisher be responsible for it and will it be deleted if he leaves, or will it be independent of the publisher?
  • Who distributes the query? Will the querying node have to contact the second hop or will the first hop contact the second hop?
  • And many more
  • And last but not least: security. This is an orthogonal topic on its own. Security against DoS attacks on the whole system or on single nodes. Security against manipulation of data, etc etc.

Coming back to Syncthing

Let's start by gathering (and agreeing) on the requirements.

  • What do we want to store?
    • As far as I can tell we could store (Device-ID, addresses), and/or (Folder-ID, Device-ID, and maybe addresses), or (Cluster-ID, addresses of all devices) tuples.
  • We probably want time-stamps with each entry
  • What security properties do we want for the data?
    • Which information should be kept secret? And from whom?
    • Which should be protected (changes only possible by original author)?
    • What about protection against data-loss? (This is usually a trade-off between re-insert frequency and replication)
  • What protection do we want to offer to the participants?
    • Limit the amount of stored data?
    • Limit the used bandwidth
  • What level of resilience against node churn do we want?
  • Will we tolerate partitioning of the DHT?
  • Do we tolerate false positives and/or false negatives?
  • What are our key performance metrics?
    • Lookup time?
    • Bandwidth usage?
    • Lookup success rate? false positives, false negatives, ....
@alugarius

This comment has been minimized.

alugarius commented Sep 6, 2016

Working together with ipfs could not only solve our DHT problem, we could enable the most efficient file shareing ever

@aviau

This comment has been minimized.

Member

aviau commented Sep 6, 2016

IPFS uses a DHT, but that dosen't "solve our DHT problem" as there will be coding to do.

Also, I don't think IPFS support sharing private files?

I really don't see how the two could work together.

@alugarius

This comment has been minimized.

alugarius commented Sep 6, 2016

Every dht solution needs coding
ipfs is actually used to share files privately (its kinda build for that o_O)

Sharing ideas and talk to each other is a kind of working together,
We don't have to use ipfs technology but the team could help us to find something. ...

I don't know where the problem is to try it at least.... we are one community at all!

@masgo

This comment has been minimized.

masgo commented Sep 20, 2016

I agree, talking to them can do no harm, especially since the project seems to be under active development.

IPFS itself is (more or less) useless for syncthing since it aims at quite different things. But what might be interesting is the P2P library they use: libp2p

The library combines many known p2p algorithms and there is a GO implementation. So talking to them might be a good idea.

What is still needed is answering the questions regarding our requirements i mentioned above. But with a little luck the requirements can be fulfilled by libp2p.

@alugarius

This comment has been minimized.

alugarius commented Sep 20, 2016

Thanks for agreeing @masgo ^^

@mengzhuo

This comment has been minimized.

mengzhuo commented Sep 21, 2016

These lib looks much better than libp2p
https://github.com/anacrolix/torrent

@masgo

This comment has been minimized.

masgo commented Sep 21, 2016

@mengzhuo you are missing the point. This is not (yet) about which library is best, but about how to add distributed discovery to syncthing.

@seanthewebber

This comment has been minimized.

seanthewebber commented Jan 25, 2018

Sorry for being late to the party, folks. Open Whisper Systems faced this problem with the contact discovery element of their Signal messaging app. They are using Intel Software Guard Extensions (SGX) to process contact sharing on secure enclaves. Perhaps this concept is an alternative way of approaching DHT on Syncthing?

@Ferroin

This comment has been minimized.

Ferroin commented Jan 25, 2018

Probably not, as I'm pretty sure you can't easily do stuff with SGX from Go (and I reasonably sure to an even greater degree that you can't do SME (AMD's equivalent to SGX) stuff from GO). In fact, I can't see how they can require that to begin with in Signal, as SGX is only in the current (and possibly previous, I don't recall for certain) generation of Intel CPU's, and AMD's SME is also only in the last few generations, and more importantly, they have to run on ARM chips which don't have such things.

@masgo

This comment has been minimized.

masgo commented Jan 25, 2018

@seanthewebber @Ferroin Appart from relying strictly on certain hardware features, what Signal solves with SGX is a completley different problem.

They faced the problem: Signal uses a centralized management server (or multiple servers) which is used by the users to find other Signal users. In order to do so, you have to query the server like: "is the user 123456 a signal user?". By doing so, you expose the users phone nr (or username, email, etc) to the server as well as the fact that you know this user. A malicious server could use this to collect user-data and build a social graph. This is a big privacy issue.

This issue is about reducing the load on the central infrastructure. The solution by Signal does not reduce the load on the central server. To the contrary, the load is increased in order to achieve their desired privacy goal.

@calmh calmh removed this from the Unplanned (Contributions Welcome) milestone Feb 11, 2018

@PanderMusubi

This comment has been minimized.

PanderMusubi commented Aug 23, 2018

You can add this line at the top of the issue description, it will update itself

![badge](https://api.bountysource.com/badge/issue?issue_id=35750022)

and it looks like

badge

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment