Holochain Forum

DevCamp Question: How does encrypted data gets validated?

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.

2 Likes

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 :slight_smile:

if you want to control access to data at the DHT level then this conversation is probably relevant Capabilities

3 Likes

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 :wink:

3 Likes

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?

1 Like

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:

  • What can and can’t be done: The way you ‘do’ things in Holochain is by publishing an entry. That’s how you make actions real. Examples:
    • Publishing a DNA entry at the beginning of my source chain is me saying “I’ve seen the rules and I agree to abide by them”. The action is me committing to the shared rules of the commons.
    • Publishing my agent ID entry as the second source chain is me saying “I claim that I have a right to participate in this space as an agent”.
    • Publishing any ‘app entry’ could constitute any sort of action — proposing or accepting a transaction, sending someone a message, revising a wiki article, etc.
  • The shared rules are the validation functions that allow my peers to check whether my ‘actions’ (the entries I publish) are legitimate. If they’re proven invalid, that gives my peers the authority to take action against me (refuse my data and blacklist me).
  • The commons is the DHT of peer validators.

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.)

2 Likes

A post was split to a new topic: Where are private keys created if you’re using Holo Host?