mozrt2
commented
1 year ago Suggested improvements for v1, @70nyIT let me know what you think:
- Optional splitting of the private key with Shamir's secret sharing so n out of N owners are needed to reconstitute the private key
- Optional addition of an offchain salt further encrypting the private key
The encryption and decryption functions would then look as follows:
Encryption
encryptViewingPrivateKeySa (
viewingPublicKeyArray: string[],
viewingPrivateKeySa: string,
requiredShares?: number,
salt?: string
) {
return viewingPrivateKeySaEncryptedArray
}Decryption
decryptViewingPrivateKeySa (
viewingPrivateKeyArray: string[],
viewingPrivateKeySaEncryptedArray: string,
salt?: string
) {
return viewingPrivateKeySa
}This should give sufficient security options for most use cases. Users could of course also choose not to store the keys onchain at all and/or use a different key management (and generation) solution.
Later on, we could look into Distributed Key Generation schemes. From my research, there doesn't seem to be any ready to use js libraries for this right now, so would keep things simple for now.
70nyIT
In the POC, we created an onchain registry which stores encrypted versions of the shared private view keys used to scan for transfer events to a Stealth Safe by the owners of the master Safe. We use eth-crypto’s encryptWithPublicKey() to encrypt the same private key N times using the public key of each owner. A master Safe of N owners is therefore added to the onchain registry with N encrypted keys, one for each owner.
The drawback with this method is that one compromised private key within all N owners would enable an attacker to get access to the shared view key and find all transactions privately sent to the Safe.
More research needs to be done to find a good alternative. One proposed technique to look into is a Diffie-Hellman key exchange with multiple parties. Implementations using Shamir’s secret sharing and / or the use of another layer of encryption (e.g. password) should also be considered.