NOTE: This is a proposal under review and is not implemented yet

TODO: review the names used. The names "proxy" and "seed" might not be ideal.

Motivation

The purpose of the locker contract is to add a layer of public key cryptography on top of existing contracts.

The protection against the replay attacks is usually done using a nonce. In Rholang, because of the parallelism, managing nonces is not simple, as it requires some form of synchronisation. For this reason we will use Rholang's unforgeable channels instead of "classic" nonces.

Locker Protocol

The locker protects the seed from the unauthorised users. Once the locker is created with a given public key and a given seed, only the owner of the corresponding private key can access the seed.

In the diagrams below the red processes are Rholang "unforgeable names" that need to be kept private.

Creating the locker

The locker factory is a contract that creates the lockers and is registered in the RChain registry.

Using the locker

The usage happens as described below:

1. the session is initiated as the owner opens the locker and obtains a proxy
2. the owner sends messages to the proxy, which forwards them to the seed
3. the session ends when the proxy goes out of scope and thus the seed is no longer available

The body of the message "getAccess" contains a private receive channel and a signature over this channel. The signature over the receive channel guarantees that it is owned by the one who also owns the private key. The channel name must be known only by the owner of the locker. An attacker who knows this name will be able to receive the proxy and get access to the locker content.

The session ends when the owner lets the proxy go out of scope. Beyond this point there is no way to access the locker content unless, of course, a new session is initiated.