Additional version options for encrypt and decrypt possible? #259
Description
MetaMask had reached out to GridPlus a few months ago about support for eth_getEncryptionPublicKey and eth_decrypt. We had done some preliminary work but it was deprioritized.
I just looked into this again and we (GridPlus) are unfortunately missing the hardware accelerated crypto that would be needed. Specifically, we only have access to xchacha20, whereas NaCl uses xsalsa20 in the default box API, which is what gets used in this code base. Theoretically we could add libsodium to our build but I can’t say if, in the end, it will be worth the extra code size (I haven’t tried so idk what the code size would be). Being on a small secure microcontroller, we are always battling against code size limits and we have to be strategic about features, especially if they bring in new libs.
It appears that libsodium (and therefore tweetnacl, which is used here) is the only crypto lib that uses salsa algos and most others use chacha. Of course it also supports chacha, but that is not the default algo for box (for legacy reasons). Here is a post asking libsodium nicely if they would switch box to use chacha by default, but since it would be a breaking change it got a hard no.
I was wondering if there has been any thought to adding more version options for the encrypt/decrypt functions in eth-sig-util. And if so, is MetaMask able to drive decisions around eth_decrypt or would any additional crypto options need to be approved by EIP (or whatever the analog is here — I’m not sure what process formed the standard)?