Make keystorev3 wallets curve-agnostic

[jimthematrix]

Make the implementation in the pkg/keystorev3 package agnostic of public key curves, and only manages the private key bytes with encryption and decryption in persistence.

Ideally the pkg/fswallet is also made curve agnostic, but that's the main API used by downstream client code and the Ethereum's 20-byte address is already entrenched. For a different system like Babyjubjub, in particular the implementation in https://github.com/iden3/go-iden3-crypto, the public key compression format is 32 bytes. So the right approach for now is build a parallel implementation of the fswallet somewhere else

[peterbroadhurst]

In #68 I already put code to make the keystore agnostic - you can just store/retrieve arbitrary bytes.

The one weirdness is that there is an "address" JSON entry in the keystorev3 - it's not really needed or used for anything as far as I can tell, just a convenience to store something in the file that uniquely identifies the key material.... and it happens to use SECP256K1 (because it was the Eth community that designed keystorev3).

So I suspect it is the "wrongess" of the address string for BabyJubJub that you're really pushing at with this PR, is that right?

[peterbroadhurst]

... if that is the case, I think the best thing would be to make the interface more generic for someone to explicitly set the address field on the WalletFile if they don't want to use the 20-byte compression syntax of Ethereum.

That could be callback function?

Then something like https://github.com/iden3/go-iden3-crypto library dependence could be pushed out of this base utility, into the calling code.

[peterbroadhurst]

I think maybe it's easiest if I provide some code to state what I mean @jimthematrix - so I'll pop that into a code proposal.

[jimthematrix]

Then something like https://github.com/iden3/go-iden3-crypto library dependence could be pushed out of this base utility, into the calling code.

that's already the case as you can see the BJJ specific logic is only in the test code. not inside keystorev3 at all. as is the case with the secp256k1 specific logic.

[peterbroadhurst]

I do also note that the Ethereum standard actually removed address after Version 1 - so we're not actually spec compliant having it, but all implementations seem to have kept it:

https://github.com/ethereum/wiki/wiki/Web3-Secret-Storage-Definition#alterations-from-version-1

Address unnecessary and compromises privacy.

[jimthematrix]

Closing this per the comments above