RIP: 11 Title: Asset Metadata Encryption Protocol Authors: The Mango Farm Team Comments-Summary: No comments yet Comments-URI: https://github.com/RavenProject/rips Status: Draft Type: Process Reference Implementation: https://www.mangofarmassets.com Created: 2019-05-20
This RIP proposes a system for the encryption and decryption of asset metadata on the Ravencoin blockchain. It is a specific application of RIP10 - Address Metadata Tags.
A standardized methodology for encryption and decryption of asset metadata will facilitate the use and exchange of private information between users on a wallet-agnostic basis.
We propose the following methodology, which has been automated in the reference implementation:
Users who want to receive encrypted asset metadata information create an Address Encryption Tag in the following manner:
- Derive a new BIP 44 address using the path m/44'/175'/0'/2/address_index. Constant 2 is used at the change level to facilitate encryption address discovery. Users of wallets that do not provide BIP44 functionality may use any Ravencoin address for basic encryption, although this will limit some of the functionality outlined in this RIP.
- Generate a PGP keypair according to the OpenPGP standard, using the encryption address as the username and a user-generated strong passphrase.
- Create a file with the PGP public key block and add the file to IPFS to obtain a hash. A text file can be used, but the JSON file format specified below is recommended for this purpose.
- Issue a unique asset to the new encryption address, adding the IPFS hash as the asset metadata and using the following naming convention (excluding the brackets):
MAIN_ASSET#PGP_[address_hash]
- “MAIN_ASSET” can be any main asset name no more than 10 characters in length, for a total asset name length of up to 23 characters (the remaining 7 characters are reserved for potential future functionality). Users, wallet providers and other second layer solutions may choose to use a single main asset name for all Address Encryption Tags they or their platforms generate. This reduces the cost of generating each new encryption address to the 5 RVN burn fee.
- “PGP” appears as the first three letters after the unique asset tag # in the unique asset name. This signifies that the unique asset carries a PGP public key for receiving encrypted metadata (discussed below) and facilitates protocol-level searching for encryption addresses.
- “address_hash” is the CRC32 hash of the encryption address. Using this hash in the unique asset name acts as a checksum, allowing any sender to confirm that the encryption receiving asset matches the encryption address that holds it. For this purpose, the hash need not be cryptographically secure. CRC32 was selected due to its simplicity and short length (8 characters).
It is recommended that users generate the IPFS hash in step 3 above from a JSON file that contains: (A) the newly-generated address from step 1; (B) the PGP public key block from step 2; and (C) a Ravencoin signature of the SHA256 hash derived from (A) and (B). This allows any sender to confirm that the PGP public key referenced in the tag was placed there by the owner of the private key for the encryption address. Below is the recommended tag format:
{
"tag": {
"tag_type": "AET",
"ravencoin_address": "<Ravencoin address from step 1>",
"pgp_pubkey": "<recipient's PGP public key block>"
},
"metadata_signature": {
"signature_hash": "<SHA256 hash of the immediately preceding tag JSON object {...}>",
"signature": "<Ravencoin signed signature_hash>"
}
}
Users who want to send encrypted asset metadata can do so in the following manner:
- Create a metadata JSON file.
- Encrypt the desired files referenced in the metadata JSON (e.g., one or more of the ipfs_attachments) using a cryptographically secure symmetric key algorithm. The algorithm chosen is a matter of user preference. The reference implementation for this RIP uses TripleSec, which double-encrypts the data with Salsa 20 and AES.
- PGP encrypt the shared symmetric key used in step 2 above, using the PGP public key of each intended recipient. This public key can be obtained from the Address Encryption Tag associated with each recipient's encryption address.
- Add the encryption infomation for each recipient to the metadata JSON.
This method, which PGP encrypts only the symmetric encryption key, reduces file bloat and eliminates the need to PGP encrypt the entire file multiple times with the PGP public key of each additional recipient.
This RIP can be used with any method to generate the JSON file, as long as the relevant encryption information is included within it. For example, RIP14 contains a specification for generating the metadata JSON that includes encryption data. Alternatively, if the metadata JSON file is created using the Ravencoin Metadata Specification, encryption information for each recipient can be added as a nested object at the end of the metadata JSON to encrypt the contents of contract_url:
{ ...
"encryption": {
"algorithm": "<e.g., AES, TripleSec>",
"recipients": {
"<recipient 1 encryption address>": "<PGP encrypted symmetric key to recipient 1>",
"<recipient 2 encryption address>": "<PGP encrypted symmetric key to recipient 2>",
"<recipient n encryption address>": "<PGP encrypted symmetric key to recipient n>"
}
}
}
This method can also be used with other metadata structures, such as the one being worked on here by adding appropriate version and schema information.
Recipients of assets with encrypted metadata can decrypt the ciphertext in the following manner:
- Retrieve the JSON metadata file associated with the asset sent to the encryption address. This contains the PGP encrypted symmetric key that is necessary to decrypt the file.
- Decrypt the ciphertext associated with the user's encryption address in the JSON metadata file with the user's PGP private key. This will reveal the symmetric key used to encrypt the metadata file.
- Decrypt the encrypted file with the symmetric key using the algorithm specified in the JSON metadata file.
Senders of assets with encrypted metadata may wish to add additional recipients over time using one of two methods:
Using this method, a sender can encrypt the relevant information to multiple additional recipients over time simply by adding to the JSON file created according to Section B above and reissuing the asset.
An alternative means of creating and sending the encryption JSON information to new recipients will be available when RIP5 - Messaging is adopted on the Ravencoin mainnet. When sending an asset with encrypted metadata to a new recipient, an IPFS hash can be added to the transaction that sends the asset. This eliminates the need to reissue the asset to add new recipients. The JSON format below can be used for this purpose:
{ ...
"encryption": {
"algorithm": "<e.g., AES, TripleSec>",
"recipients": {
"<recipient 1 encryption address>": "<PGP encrypted symmetric key to recipient 1>",
"<recipient 2 encryption address>": "<PGP encrypted symmetric key to recipient 2>",
"<recipient n encryption address>": "<PGP encrypted symmetric key to recipient n>"
}
}
}
The methodology outlined in this RIP has been automated on Mango Farm, providing a proof of concept for its use as a standardized process.