Yesterday, one of the students at the online DevCamp asked the following question:
“How does encrypted DHT data gets validated by the agents?”
We didn’t know the answer and found it a rather interesting question. Does someone know how this will work? Thanks a lot for the explanation.
encrypted data cannot be validated natively by holochain
we can encrypt data for storage or transit but it cannot be encrypted at the point it is validated
or, more specifically, validation must be the same for everyone, everywhere at all times (deterministic and based on input data)
this implies that if you encrypt data then the validation logic is probably return true unless everyone has a more meaningful way to interact with it
if you can come up with a cryptographic scheme that respects the above and allows for encrypted data in your domain-specific logic for your app then go nuts 
if you want to control access to data at the DHT level then this conversation is probably relevant Capabilities
Homomorphic encryption may have some promise for this sort of thing, but it’s pretty exotic — the domain of research (I can’t understand even the introductory stuff in Wikipedia) and most definitely not supported natively by Holochain 
I might be wrong, but wouldn’t ZK proofs be an option for this?
Just for better context, what would the use case be for a piece of data needing to be validated that is only able to be unencrypted by a single agent?
Hi @freesig, I am not sure about a use-case. It was a question from one of the DevCamp participants. I will try if I can redirect your question to him.
Some other question I just came up with. Could a capability token give another user the capability to read encrypted data on the DHT? Or is this not one of the use-cases of capability tokens?
@hedayat, this was one of your questions during the DevCamp. Do you have a certain use-case for this?
@AdriaanB one use case for validation on Encrypted data can be this:
In a chat application, I would like to encrypt a message for another party of a Channel by his Public key. Application is supposed to run some validations like: length of the message, running some filters - like bad words - if the parties is under 18 years old and etc.
@AdriaanB it took me quite a while to grok capability tokens and what they can be used for. I eventually figured out that capability-based security is only relevant when one entity has total custody over a resource. At the OS level, that could mean that only the kernel has direct filesystem access, and when processes think they’re writing to a file they’re actually writing to a stream that the OS provides. Within Holochain, that could mean that Alice gives Bob the permission to ‘call’ zome functions in her instance, but actually what’s happening is that Bob asks Alice to call the functions and she does it on his behalf.
Public data on the DHT is different, though, because everything’s out in the open (even encrypted data that’s ‘hidden in plain view’). You can’t control access, because it’s kind of a data storage commons. So what you do instead is have a set of shared rules, enforced by the commons, about what can and can’t be done. Here’s how it applies to Holochain:
The design for this can look a lot like capability tokens — you’re given a ‘token’ of some sort that proves that you have permission to do it — but the guts look different because of how the resource is controlled (or not controlled, in the case of public data). I’ve written about it a bit in the Privilege Certificate pattern.
I’m having a hard time figuring out where your example falls — giving access to public encrypted data by handing out the decryption key. Sorta feels like halfway between capabilities and privilege certificates, eh?
(NB this pattern language section of the forum is very new. I encourage you all to critique the first few articles, comment, make edits, add new patterns, etc.)
