This repository has been archived by the owner on May 31, 2021. It is now read-only.
Encrypt content before sending transactions #32
Labels
kind/new-feature
New feature or request
status/on-hold
This issue has been put on hold, and it might be resumed in the future
Projects
Feature description
Currently all content in the transactions are not encrypted and public. Although the system is censorship resistance, it still enable trace of content delivery which link back to a certain user. As
Mooncake
holds the private key of the user, the content can be first encrypted and then put inside the tx message before broadcasting. The user sign the encrypted message rather than the original content. The content in the tx can be decrypted byMooncake
using the corresponding users's public key when the users load the data. The content being encrypted should be a salted string instead of the plain content so that other users can't decrypt it using users public key as they don't know the secret salt.One scenario this feature can benefit is as below.
Mooncake
or on chain.Implementation proposal
Mooncake
holds a secret salt. This can be the original value of the hashedsubspace
or another piece of random string. It acts like theapp_id
andsecret
of a Facebook app.secret
and encrypted. Then the post message holds thisencryptedSaltedContent
and broadcast.djuno
should still store theencryptedSaltedContent
to keep itself as the chain parser.Mooncake
displays the content, it decrypts with poster's pubkey and remove thesecret
The secret should only be available in the binary build of the
Mooncake
, it should not be stored onGitHub
. This should be purely done during build time.The text was updated successfully, but these errors were encountered: