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.)
Would resource constrained devices be able to perform ZKProof?
Hi @lchang, I’m no expert on the topic but how constrained are such devices? Smartphones? If so, I guess they would be able to handle it. I’m not sure about embedded devices (e.g. IoT stuff). Just for the sake of comparison, blockchain smart contracts are executed on a “constrained” sandboxed environment that doesn’t allow heavy computation (cost would be prohibitive), unless the ZK cryptographic primitives are internal to the blockchain VM. So, it seems that an investigation on the current research around ZK proof algorithms has to be done. Anyway, I still believe that ZK proofs are one alternative.
Hi @feamcor, I would love to see zkp or similar to really function reliably and efficiently across devices as I do believe that privacy is a critical component, especially for some apps in healthcare space that I’ve been thinking about. I’m also no expert in zkp and have just been following the zk podcast to see how the technology in this space evolves. I’m with you that zkp would be an option and a really good one when/if it’s robust/mature.
@lchang, it seems that there is some research going on… http://www.osna-solutions.com/wp-content/uploads/ZKP-in-M2M-Communication-Paper.pdf
Wouldn’t it also be useful to only validate if you got the keys? So:
cannot decrypt it:
return true
can decrypt it:
run validation
This would be useful in for example said chat application, where all recipients verify the message, but those who cannot read it only act as server… (saw this thread after I posted this)
@th1j5 everyone should get the same results for validation otherwise it largely defeats the purpose
if someone can decrypt it and discovers the validation fails, how does anyone else decide to agree or disagree?
can you do what you need with a separate DHT for the ‘servers’?
That’s a good point, didn’t think about that.
If however most devices are trusted (for example in a group chat with friends), wouldn’t it be possible for the ‘server’ to decide on a majority vote (with respect to received warrants)?
But if it would start like this, it might indeed become an anti-pattern and probably not even feasible in Holochain right now.
If you’re referring to my post, I mainly was thinking theoretically how for example group chat would be solved, but I think it’s more important how Kizuna would solve it (if they solve it).
I didn’t think solution 2 through, but the first thing that comes to mind is that when the last people go offline (so the redundancy is not met anymore), they should know whether everyone received the message/entry, otherwise everything would be posted to this separate DHT anyway.
With respect to validation, it’s indeed trivial: DHT1 validates, DHT2 just accepts everything
there’s no global data or events because of the agent centric premise
validation needs to be consistent across time, if you join a DHT in 5 years you should still get the same validation results
trusting a majority vote from network participants who were online 5 years prior but are not currently available may not make sense
agents decide for themselves who to trust based on behaviour
all honest nodes will agree if validation is deterministic and will consistently block a bad actor as emergent behaviour without the need for a co-ordinated ‘vote’ event
the problem is not specific to encryption, it’s just determinism
if there is validation that does not rely in the inputs alone, i.e. it is not pure, then agents will honestly disagree which introduces problems that don’t exist if any disagreement always implies at least one dishonest actor
decryption is not pure if it requires looking up a decryption key within the function and encryption is not secure if the decryption key is publicly available in order to be passed in to make the function pure