chat, email: confidential communication?  

  RSS

dckc
 dckc
(@dckc)
Member Moderator
Joined:7 months  ago
Posts: 22
12/04/2018 1:03 am  

In the community update today, Greg talked about making sure we have public infrastructure for basics such as chat and email. Those typically require confidentiality. But in November, I heard Mike Stay say "nothing is private on the blockchain".

Somebody help me reconcile these?

Unforgeable (rather than unguessable) names seem to meet the requirements of the mint / purse contract but I don't see how that could work for chat / email.


ReplyQuote
MichaelBirch
(@michaelbirch)
Member Moderator
Joined:8 months  ago
Posts: 41
12/04/2018 1:25 pm  

Nothing is private on the blockchain in the sense that anyone can obtain the state of a block an examine it. However, if some parts of the content of that state are encrypted then information could be exchanged privately. So the short answer to your question is just use encryption in the chat/email dapp.


ReplyQuote
dckc
 dckc
(@dckc)
Member Moderator
Joined:7 months  ago
Posts: 22
12/04/2018 2:05 pm  

Thanks.

Obvious in retrospect. My brain just got stuck in second gear, I guess.


ReplyQuote
dckc
 dckc
(@dckc)
Member Moderator
Joined:7 months  ago
Posts: 22
12/04/2018 9:07 pm  

It's obvious in some sense, but I get a feeling of "reduction to previously unsolved problem."

I should have said in my original post that I was thinking about how to port Secure EChat to Rholang / RChain. I'm used using ocap patterns for all my security needs, but now I'm back to the public key management problem.

Where do I store my keyring / buddy list? I could store it encrypted, but if my rholang code decrypts it, everybody gets to see the plain text.

 


ReplyQuote
Mike Stay
(@stay)
Member Moderator
Joined:7 months  ago
Posts: 19
19/04/2018 10:37 pm  

Secrets always have to be kept off-chain. Client software would maintain the secrets; all the state and communications would presumably happen on-chain.  Sent messages would be deployed via the standard code deployment interface.  Received messages would be visible via the API exposing the node's current view of the state.

As to whether the client software is written in Rholang or not, I'd say that if you want to build it now, you should use something else.  If you're willing to wait until support for middleware is complete, the design we're adopting for the Rholang system contracts injects the top-level ones with all the authority over the system, but these will be able to load others and attenuate and delegate the authority.  So if you're running a node, you could run your rholang chat app that could keep the secrets but also communicate with on-chain stuff all while preserving the security of your node.

My current idea for how this would work is that regions would agree to run specific sets of middleware apps (webservers, chat clients, whatever) via some contract running on the blockchain.  Nodes serving the region would get paid for running the middleware but wouldn't be doing it via phlogiston; instead it's a trust-based model (necessarily, since off-chain stuff can't be validated).


ReplyQuote
  
Working

Please Login or Register