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).
The move to 3rd party hosting for super-sensitive internal stuff like this baffles me.
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.
Actual content of the messages could be encrypted separately. Client would send separately the selected terms for indexing and the content for each message.
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.
or don't provide a search service, have client have its own local 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.