Create new funcionality to encrypt and decrypt data with private key.

[mmcs85]

This is a continuation of the issue: GetScatter/ScatterWebExtension#39

There is two distinct use cases that are important.

• Single account encryption using private key.
• Two accounts data encryption exchange (Alice sends private data to Bob).

For the first case you can sign some TEXT with account private key and then use it on symmetrical encryption algorithms like AES-256. Or you can generate a sharedSecret between the account private key / public key.
In both cases a nonce is recommended to be used for generating the resulting symmetrical key to add entropy. Think of it as disposable keys per message.

For the second case the only option so far is to generate a sharedSecret between Alice private key / Bob public key. (indirect asymmetrical encryption). This also requires the nonce entropy.

My solution Proposal

In order to avoid using encryption inside scatter I propose to only calculate the disposable symmetrical key inside scatter and let the dapp developers use the symmetrical algorithms they choose. AES-XXX or any other.

Requirements to implementation
Note that so far the sharedSecret implemented in eosjs is based on secp256k1 curve that happens to be the default one used to create account keys in crypto. It returns 64 bytes from a sha512 hash.

The encryption key for AES-256 is 32 bytes + 16 bytes for a IV(initialization vector).

Is there a need to generate bigger encryption keys? If so a hashing algorithm that returns more bytes is needed.

check here: https://github.com/EOSIO/eosjs-ecc/blob/master/src/key_private.js#L81

In order to eosjs-ecc play nice with this implementation the crypt function would need receive as parameter the encryption key.

check here: https://github.com/EOSIO/eosjs-ecc/blob/master/src/aes.js#L56

Example:

scatter.getEncryptionKey(fromPubKey, toPubKey, nonce)
NOTE: the fromPubKey to obtain the privateKey inside scatter domain.

Returns the encryptionKey.

Advantages:

• avoids scatter from encrypt/decrypt Data.
• with nonce scatter can require user permission for each getEncryptionKey per message. Also avoids giving the shared secret to a rogue dapp.

Disadvantages:

• none so far? Please comment

[ChenLi0830]

Hi @mmcs85 thanks for migrating the issue. A couple of quick questions with regards to the proposal

1. how would you keep the record of the encryption key/keys on the client side?
2. if there are multiple clients (web & mobile) how are you planning to sync the encryption key between those clients?

Thanks!

[mmcs85]

1 - You can store with indexDB or localstorage.
2 - You can always reconstruct the same encryption key with the same parameters (fromPubKey, toPubKey, nonce) or with the inverse Pubkey and Privkey like asymmetric encryption. You just need to share this information between clients using a traditional server or the blockchain.

For example lets assume you want to do a scatter private chat dapp:
Lets assume you create a SmartContract with action:

sendprivmessage(account_name from, account_name to, string msg, nonce, checksum)

Use case, Alice sends msg to Bob:

• get Alice@active public key.
• get Bob@active public key.
• generate nonce.
• use scatter.getEncryptionKey(AlicePubKey, BobPubkey, nonce)
  This assumes scatter has the Alice entity loaded.
• encript msg with AES-256 and get the checksum.
• eos.pushTransaction(name = "sendprivmessage" , data:{from = alice, to = bob, msg = encrypt_msg, nonce, checksum})

Then Bob in another client can fetch the msg from Contract state or actions log and do:

• use scatter.getEncryptionKey(BobPubkey, AlicePubKey, nonce)
  This assumes scatter has the Bob entity loaded.
• decrypt using encryption_key + nonce + checksum

I hope you get the ideia.

Regards

[mlockett42]

Would also like this to be implement and have projects that could use it immediately if it was.
But the proposed solutions I feel are too complex, we only need the decryption functions. The encryption can be done with the standard eosjs functions and the target users publicly available key, it doesn't need to be in scatter.
Just something like
decrypted_data = scatter.decrypt(encrypted_data);
will do it. The only thing needed to decrypt the data is the private key which scatter has.
Also scatter would need to ask the user permission and throw an exception if the data cant be decrypted.
This link shows how to do this with eosjs if you have the private key.
EOSIO/eosjs-ecc#19 (comment)

[mmcs85]

Encryption inside scatter already was proposed before but that may create a maintenance issue that if scatter has to update the algorithm for security reasons. It may break dapp's before they have time to update.

The solution that I proposed is to avoid doing the encryption inside scatter. Instead the symmetric encryption key is calculated inside scatter and then eosjs OR any other lib can use it to feed many symmetrical algorithms. This way the encryption algorithm is deferred to the dapp devs and they have time to update their dapps.

NOTE: It works as long the new algorithms support the returned encryption key size.

[cppfuns]

@nsjames I also need this feature urgently. I feel that this function has a higher priority. Do you have any plans to support it?

[nsjames]

c8b8252

See this branch. I'm not too sure if this would actually work yet as I haven't had time to test the encryption/decryption.

[mmcs85]

Did this #141 PR to fix the public key format on the sharedSecret function

[nsjames]

Sorry this didn't make it into the most recent update, i'll have to start revisiting it for next release. This looks good though in general. Extrapolating it into plugin specific should make it far stabler into the future ( albeit more work when adding blockchains ).

[utilsites]

Created another issue on eos-transit project to push on a standard functionality for multiple wallets on this subject: eosnewyork/eos-transit#2

[angelol]

I see a huge security issue in the proposed solution. The problem is that ECIES is only secure if you can guarantee that a unique nonce is used every time. If you re-use a nonce, you leak your shared secret.

Now the problem is that the developer has to remember to request a new shared secret with a different nonce every time they want to encrypt a message. Since Scatter will ask the user for permission every time, the developer will also be tempted to minimise the number of confirmations shown to the user.

Considering the above, it doesn't take much imagination to see that this will happen rather sooner than later and that it will be used incorrectly more often than correctly. We can't expect the typical programmer to have extensive cryptography training to recognise this. I'd rather not see the FUD media articles about Scatter & EOS encryption having been hacked.

In my opinion, the best way to solve this, is for scatter simply implement the eosjs_ecc.encrypt and eosjs_ecc.decrypt functions (https://github.com/EOSIO/eosjs-ecc/blob/2cd505ccc717913b813488bcd652981203bb7586/src/aes.js#L30). These implement the ECIES standard and are identical for Bitcoin and other cryptocurrencies that use elliptic curve cryptography. The nonce has to be generated inside scatter to make sure it cannot be reused.

Does this create a maintenance issue for scatter if the encryption gets broken? I would argue that if ECIES gets broken, scatter maintenance issues are the least of our worries. The security of Bitcoin and other chains rely on the fact that the underlying ECC is secure. So replacing a know-to-be-secure implementation of cryptography with something the every developer has to roll on its own is not a very good trade-off. In fact we are violating the golden rule of cryptography to never roll your own.