Public, permissionless, open-source blockchains are great (especially Ravencoin). But public, permissionless blockchains can be read by ANYONE. That’s not great for private information.
So, what’s the solution? Encryption!
There are two major categories of encryption.
- Symmetric encryption.
- Asymmetric encryption.
Symmetric encryption uses the same password to encrypt, and decrypt. Asymmetric encryption uses public/private key encryption which has some really interesting properties like being able to encrypt something without knowing or needing to transmit the decryption key.
I’ll explain how to use both with Ravencoin, and you can choose the one that works best for you.
First a quick refresher on the data storage and immutability of IPFS data that Ravencoin uses for data storage. When issuing, re-issuing, or transferring a token, you can include IPFS data. First, add your file to IPFS, then embed the returned IPFS hash into your Ravencoin transaction.
You are responsible for pinning the file you added. Pinning the file will make you a root source of the file. If you don’t want to do it yourself, use a service like MyPin. Right now the information you include will be pinned by a swarm of Raspberry Pi nodes, but that will not last forever as the amount of information stored will eventually exceed the capacity of this swarm.
The upside of adding IPFS data to a Ravencoin transaction is that you know the data is immutable (tamper-proof and unchanging). The downside is that it is public for everyone who wants to look.
Before you ask…. Yes, there is a way to keep the upside benefit and solve the downside problem. Encryption will keep the immutable file readable only to those that have the key to decrypt the file.
This is pass-phrase (or password) encryption. The pass-phrase is what encrypts and decrypts the file. Encrypting with a pass-phrase makes it so the file is only readable to anyone who has the pass-phrase.
This method is best for instances where many people may need to read the file. The pass-phrase will be sent to those people and they should protect the pass-phrase like they would protect the file because anyone with the pass-phrase can decrypt and read the file.
To use symmetric encryption:
- Use an open-source tool like AESCrypt.
- Use the command-line or drag-and-drop to encrypt the file and supply a pass-phrase.
- Add the file to IPFS to get back IPFS Hash.
- Include the IPFS hash in any issuance meta-data, memo, or message transaction.
- Share the pass-phrase with anyone you’d like to be able to read the file. The recipient will download the file, and decrypt the file using open-source and freely available AESCrypt.
Asymmetric encryption will encrypt the file with a public key, and only the holder of the matching private key will be able to decrypt it. This is best for one-to-one encryption.
So how do you get the public key of the person for which you want to encrypt the file?
That’s where RIP11 comes in. RIP stands for Ravencoin Improvement Proposal, and #11 was created by Mango Farm Assets to enable encrypting a file and provides a spec for how to communicate the public key for encryption.
RIP11 specifies how a public key can be stored as the meta-data for a unique asset with a fingerprint embedded into the Unique Asset name.
Here is an example:
After memos activated on the Ravencoin network in February 2020, the flexibility to communicate and immutably store private information opened up significantly. Because you can include a memo (encrypted or non-encrypted) with every transaction, this opens up all kinds of opportunities.
Unfortunately, asymmetric encryption is not ideal for one-to-many messaging, as each person holds their own private keys, so the message would require many individually encrypted messages. RIP 14 addresses multi-file encryption.
Perhaps another RIP could specify a file format in which many encrypted messages could be contained and an easy way (indexed by public key or PGP fingerprint) to identify the section that “you” can decrypt with your private key.
Ravencoin doesn’t have built-in encryption, but by following the RIP11 spec lets you interoperate with other 2nd layer tools that want encrypted meta-data, memos, and messaging.