what to do with encrypted wallet contents in rholang?

[dckc]

If the whole contents of the wallet is encrypted, how is rholang relevant?

The only cryptographic tools in rholang are signature checking and hashing.

What is a rholang contract expected to do with an encrypted blob?

possible answers:

• [x] this wallet from a rholang perspective is a cell contract to get / set a big encrypted string.
  • [x] the set method can be refined with an addAsset( REVAddr, encryptedPayload ) implemented in a Scala wallet API; see discussion below
• [ ] only the asset in each (addr, (label, asset)) entry is encrypted

While I welcome comment from the whole community, this issue can only be resolved to my satisfaction by an answer from @leithaus or some other authorized representative of the board; i.e from the folks setting requirements for the 1M REV .

[fabcotech]

From what I understood there is more work outside of rholang than there is inside it. Finally you are right, basically this wallet from a rholang perspective is a get/set a big encrypted string.

And once decrypted, it has something like the following structure:

{
  "ab12bcrchainaddress": ("dr Carter", "signeddocumentbyboth parties"),
  "cc43bcrchainaddress": ("vaccine center", "signeddocumentbyboth parties"),
}

Structure:

{
  [revAddress: string] : ( friendlyName: string, signedDocument: string )
}

Decryption, read and updates are performed outside of rholang, I cannot see another way to go.

[jimscarver]

As I understand it It is decrypted in the users client and then encrypted with the public key of the intended recipient of the attestation.

[dckc]

@jimscarver I don't understand the relevance of your comment to this issue. Are you implying that you agree with @fabcotech that ...

... this wallet from a rholang perspective is a get/set a big encrypted string

[jimscarver]

Yes, @dckc the encrypted wallet is useless for anyone but the owner. It is just a copy stored on the chain for convenience of the user.

Do you think it might have another use if not completely encrypted?

[dckc]

On possibility is that only the asset in each (addr, (label, asset)) entry that is encrypted. In that case, the data structure could actually be manipulated on-chain by rholang.

@9rb writes:

in my mind, it's sufficient to lock the asset only .. but this is really a privacy issue - so metadata may also be important.. I think we can take an approach of asset + as much metadata as possible that still allows processing through

[dckc]

btw... this issue can only be resolved to my satisfaction by an answer from @leithaus or some other authorized representative of the board; i.e from the folks offering 1M REV .

[dckc]

@fabcotech writes:

From what I understood there is more work outside of rholang than there is inside it. ... Structure:

{
  [revAddress: string] : ( friendlyName: string, signedDocument: string )
}

yes, I've got that structure in ts / js: https://github.com/rchain-community/didit/blob/82db38745d529ad886aa990252f5802479b89f49/src/index.js#L105-L109

[dckc]

@leithaus suggested another possibility using a diagram:

DigitalAcreditationWalletAPI.pdf

The decrypt( [ encryptedPayload, encryptedWalletAssets] ) arrow assumes a Diffie-Hellman style shared key; that is: it abbreviates something like crypto_box_open(c,n,pk,sk) from NaCl authenticated encryption:

• c is the cyphertext that combines encryptedPayload and encryptedWalletAssets
• n is a nonce; a reasonably straightforward detail to be worked out
• pk is the public key of the user / deployer
• sk is a private key held by the Scala wallet API
  • p.s. it occurs to me that this secret has to be shared among the validators somehow. oops. Maybe I don't understand this design after all.

In any case, in this design, the rholang contract is again mostly just a cell contract with get / set methods. The addAsset method doesn't do anything in rholang; it just passes data to scala code which eventually does a storeNewAssets i.e. set. @leithaus agreed that the user / client can do the same decrypt, add, store operations as the Scala wallet API.

[dckc]

The rholang code is expected to be essentially a cell contract for an encrypted byte string. It is not expected to deconstruct the wallet contents to manipulate them.

[leithaus]

Note that you can iterate the solution. So, rather that making the entire wallet contents a cell, you can make it a list/data structure of cells. The contents of each cell can be encrypted. You can do this all the way down a nested data structure to the leaves.

[fabcotech]

Yep, having nested encrypted cells instead of a big one is also better, it means the user does not have to re-upload everything each time he updates one file. If you have 20 files of 1MB each, you don't want to re-upload the whole 20MB encrypted value.