How to securely send the private key from the client to the server?

[ubuntutest]

I am developing a Dapp with ethers.js. The application automates a series of transactions for users, to do this I understand that there is no other way than to use the users' private key, without the user having to accept every single client side transaction.

I use ajax to make a post call to the nodejs server, here I process a series of operations.

I do not in any way save the users private key in my server / database, it is not my interest to do so. I optionally give the possibility to save the private key in the user's localstorage so as not to have it entered every time.

My fear is that the private key may somehow be intercepted during the sending process to the server. I don't see any other possible risks at the moment.

What can be a way to increase security in the submission process? Maybe there is a functional client-side encryption and server-side decryption method with ethers.js?

[zemse]

The application automates a series of transactions for users, to do this I understand that there is no other way than to use the users' private key, without the user having to accept every single client side transaction.

Asking for user's private key is a trustful suggestion and defeats purpose of web3, for a trustless solution, you may have the client side application sign the transactions with a high base fee per gas (200 gwei) and a nominal priority fee per gas (1.5 gwei), the gas charged for the user is just the actual base fee at the time + priority fee. Your server can keep the txs and broadcast them later (without the user's privatekey).

My fear is that the private key may somehow be intercepted during the sending process to the server.

If the above suggestion does not work for some reason, and you need to have the private key sent, you can ensure that the requests are made using https protocol. The private key including the entire request is encrypted using the SSL certificate of the server and only the server can decrypt the request contents. There is a rare exploit case of man-in-the-middle attack which can be performed by a combination of DNS and someone who can generate a fake certificate for the domain (this includes certifying authorities), basically, the client browser will encrypt the request which will be read by the man in the middle (and they would encrypt the request and forward to your original server so attack kindof goes undetected).

If you do not want to rely on traditional SSL security, you can do Diffie–Hellman Key Exchange using ethers.js's computeSharedSecret util (docs) and use the shared secret + ricmoo's AES. This needs an ethereum wallet on the server (does not need any ether on it, just for encryption and decryption).

[ubuntutest]

The Dapp I am developing works as a sort of bot, it buys and sells certain tokens, each transaction cannot ask the user for confirmation, I can keep all the txes as they can change at any moment.

I will use both the https (this is obvious) and the computeSharedSecret utility of ethers.js. If you have an example of how to do this it wouldn't be bad.

Thank you for your suggestion

[ricmoo]

Do. Not. Do. This.

The entire point of crypto is to let the user control their data. If you send the private key over the wire, that is lost. Forever. It could have been intercepted. You could log it in a log file and not realize it. Your server could be compromised and it saved to a database or forwarded to another host the attacker controls.

You do not want to be in the business of managing a customers private key. Ever. In any way, shape or form.

You can design your contract to accept a signed message, or use approve patterns or have the user accept multiple pop-ups. There are plenty of existing techniques that address this. But your dapp should never have access to the users private key.

For general purpose secure data transfer, see @zemse solutions. You should definitely layer ECDH in, since users can opt out of security over https.

But do not ask the user for their private key. Do not put it in local storage. Do not send it over the wire. You will be responsible for people losing their funds and assets if you do. Don’t. Do. it. :p

[ubuntutest]

I could take a percentage like uniswap does, I think it uses this logic you suggested, it takes users' tokens, swaps it, and sends back the tokens while keeping a percentage.

The problem in my case is that by doing so I slow down the process too much, the goal of my DAPP is speed, if I use the logic you suggest I make too many transfers.

• what do you think of the alternative of not sending the private key to the server and running all the logic on javascript (client side)?

• i found this library, maybe it simplifies the permits method implementation process, i will try it https://github.com/dmihal/eth-permit

[tedy5]

About the speed.. you should do all this in one transaction.

For example, when I put limit order on 1inch, bots do:
-take my tokens
-swap them for ETH on dex
-return ETH amount I specified I want for my tokens
-send the rest (profit) to their wallet

All in one transaction :)

[ubuntutest]

they probably use multicall transactions, it is not easy for me to implement them, I have not found any working example in js

[tedy5]

Out of all this, multicall transactions are the easiest part. https://www.youtube.com/watch?v=xKiLdpshg6w

[ubuntutest]

Hi, sorry for the really late reply.
Thanks for the link, I've implemented it, but as explained in the video it doesn't work with tokens. With some modifications I succeeded but sometimes it works other times it doesn't, I can't really understand the reason, without changing any parameter or contract it sometimes works and sometimes it doesn't after a few seconds, I really can't find a real reason.

However, I managed to implement the auto router which solved many problems for me, it works both with V2 and V3 tokens and with pairs of any type.

Coming back to the main topic, I'm still trying to figure out how to get permit to work, I'm trying this library (https://github.com/dmihal/eth-permit) (also someone says it's deprecated) the transaction always fails. Also, from what a community user says, it doesn't seem to me that all tokens support this method by default.
If you for example check the UNI token, it supports it:
https://goerli.etherscan.io/address/0x1f9840a85d5aF5bf1D1762F925BDADdC4201F984#readContract

while the ZETA token does not:
https://goerli.etherscan.io/address/0xCc7bb2D219A0FC08033E130629C2B854b7bA9195#readContract

edit:
in the uniswap discord they told me that permit doesn't work for all tokens. standard is the ERC-20 approval