5 ms·
Would allowing organizations to manage their own key(s) suffice? If all of the stored data was encrypted by the users (even if it was a single key for a client
by okreallywtf 9y ago
Would allowing organizations to manage their own key(s) suffice? If all of the stored data was encrypted by the users (even if it was a single key for a client organization), that would do a lot. You would have to compromise the private key(s) for the organization as well as Slacks (now useless) data.
- meritt 9y agoHow does Slack provide a search service if the data is encrypted by keys they do not control?
- deleted 9y ago[deleted]
- okreallywtf 9y agoI see your point. Is it possible to achieve that type of functionality with a reasonable expectation of security?
- cortesoft 9y agoWell, if you want slack to be able to search chats history, it needs to be able to access it in some way. So if your 'resonable expectation of security' involves slack not being able to read your chat history, you are going to have to give up search. Otherwise, the reasonable expectation of security will have to rely on trusting slack to properly secure their side of things.
- nerfhammer 9y agorun the tokenizer on the client side, client submits encrypted tokens to the search index. or don't provide a search service, have client have its own local index.
- meritt 9y ago> run the tokenizer on the client side, client submits encrypted tokens to the search index. That would be an incredibly insecure method of encryption. > or don't provide a search service, have client have its own local index. Yep, I would prefer an on-prem solution.
- voidmain 9y agoThe client incrementally builds a search index, encrypts it using an appropriate random access encryption primitive, and writes it to the cloud encrypted. At search time it reads as necessary from the encrypted index. (This allows some light traffic analysis; if you can't tolerate that the client can store a copy of the entire index)
- humanfromearth 9y agoWhat search implements this?
- dsacco 9y ago> Would allowing organizations to manage their own key(s) suffice? No. Slack does not implement searching logic on the client. If the key is only known to the client, and the search logic is only known to the server, you can't search anything. End-to-end encryption is fundamentally incompatible with server-side search, because it mandates that the secret key can never leave the client. You can't reconcile these two features without efficient homomorphic encryption (which does not exist yet, and will not exist for the foreseeable future in any practical sense).
- majormajor 9y agoIt could be compatible with hosted server-side search, no? (Requiring a certain amount of trust that it doesn't phone home, but that's true for a search-less encrypted client as well.) The move to 3rd party hosting for super-sensitive internal stuff like this baffles me.
- dsacco 9y agoYes, that would be fine and is fully realizable. In the client-server model of end-to-end encryption, a server self-hosted by the user is isomorphic with a user's client. They're effectively the same thing. The tricky part here is defining who the user is. If you're implementing end-to-end encryption for data on a per-employee basis, you're back to square one with a self-hosted server. But if you're implementing end-to-end encryption for data on a per-organization basis, and the organization has a self-hosted instance it controls, then yes, end-to-end encryption is compatible with organization-wide message search.
- jpalomaki 9y agoCould work for limited search. For example each term in search index encrypted by the company key. Client passes is also encrypted search term. Actual content of the messages could be encrypted separately. Client would send separately the selected terms for indexing and the content for each message.