Proxy re-encryption

When beginning to stream a track, a fan’s client will make a request to one of a artist’s elected content nodes, including a payment or other proof if required, for a proxy re-encryption key specific to the segment of the track being consumed.

To service this request, the content node derives a proxy re-encryption key using the fan’s public wallet key and the private key used to encrypt the requested track and returns it to the fan. Because the re-encryption key is specific to the artist, fan, and segment, it can be transmitted insecurely or published without revealing the track contents to the greater network

The cryptosystem used to encrypt tracks will allow the issuance of fan-specific proxy re-encryption keys derived from the track encryption key and the fan’s public key. The artist’s content node(s) will handle key requests and issue new keys when the specified conditions are met, issuing a new key by mixing the track encryption key with the fan’s wallet’s public key.

After fetching encrypted content and a re-encryption key, the fan client would locally decrypt the content using their wallet private key as follows:

proxied = reencrypt(encrypted_content, reencryption_key)

plaintext = decrypt(proxied, wallet_privkey)

This decrypts a given piece of content by locally reencrypting it using the aforementioned key and subsequently decrypting it with the user’s own private key. There is no 3rd-party proxy, but proxy re-encryption applied in this way allows everyone to share the same encrypted content while users can only decrypt the content on a case-by-case basis.