refactor: remove unused asymmetric encode/decode functions

[davidyuk]

• it was added in feat(Crypto): Implement asymmetric encoding/decoding using tweennacl and Ed25519 keypair #466 without any reasoning
• it isn't used by sdk itself
• it is unclear who and for what reason can use it
• nacl.box/nacl.box.open can be used directly instead

[codecov]

Codecov Report

Merging #1183 (51def34) into develop (55334b2) will increase coverage by 0.25%.
The diff coverage is n/a.

@@             Coverage Diff             @@
##           develop    #1183      +/-   ##
===========================================
+ Coverage    65.84%   66.09%   +0.25%     
===========================================
  Files           55       55              
  Lines         2755     2743      -12     
  Branches        36       36              
===========================================
- Hits          1814     1813       -1     
+ Misses         933      922      -11     
  Partials         8        8              

Impacted Files	Coverage Δ
src/utils/crypto.js	71.83% <ø> (+9.18%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 55334b2...51def34. Read the comment docs.

[mradkov]

I think this is helpful to have in the SDK. Not sure if anyone is and how much they are using it but it gives a useful wrapper for asymmetric encryption.

example case: https://github.com/mradkov/secure-data-exchange

[mradkov]

I propose to keep it here. Its obvious that anyone can use it with the underlying nacl library directly, but people relying on the sdk to make aeternity related asymmetric crypto operations will expect it to be here.

[davidyuk]

Were these functions requested to implement by you? Do you know according to what it is implemented?

tweetnacl have a reference to https://github.com/whs/tweetnacl-sealed-box that does the same, but a bit more size-efficient, why don't use this instead of our implementation?

I'm not sure what our implementation is audited/well-written, at least the package ed2curve (we are using it) says "there's currently no proof that this is safe to do".

I don't like to have this also because other parts of SDK are not compatible with it. It can't be used in aepp, because aepp-wallet connection support only signing.

https://github.com/mradkov/secure-data-exchange

In your case would be more secure to use exactly nacl.box because both Alice and Bob have keypairs (no need to generate ephemeral key pair, sender would be verified despite blockchain).

I'm not sure why are you using Crypto.decryptData (based on nacl.box) with Crypto.decryptPrivateKey (AES). Is it for performance reasons? As I understand nacl.box is already using a symmetric cipher underhood (xsalsa20-poly1305) that is accessible separately in nacl.secretbox.

Simple wrappers won't help to implement crypto-stuff with confidence, better to use crypto libraries directly. The best that we can propose now is a function converting address to byte array.

[mradkov]

@davidyuk can you rebase this PR so we can merge it?