How to Implement Signing with ed25519

[ym.u.ichiro]

I created the following code to set up an environment where I can handle a pair of private and public keys using ed25519.

const privateKeyProvider = new CommonPrivateKeyProvider({
  config: {
    chainConfig: {
      chainNamespace: CHAIN_NAMESPACES.OTHER,
      chainId: "0x1",
      rpcTarget: "RPC_URL",
    },
  },
});

const web3auth = new Web3Auth({
  clientId:  "xxxxxxx",
  web3AuthNetwork: WEB3AUTH_NETWORK.SAPPHIRE_MAINNET,
  privateKeyProvider,
});

web3auth.configureAdapter(
  new OpenloginAdapter({
    privateKeyProvider,
    loginSettings: { curve: "ed25519" },
  })
);

I researched several use cases on the web, but most cases involved downloading the private key to the frontend and implementing the signing method independently. Is there a way to complete the signing on the server side of Web3Auth without bringing the private key to the frontend?

Ideally, it would be reassuring if I could pass the data to be signed and only receive the signed result.

[Ayush]

Hey @ym.u.ichiro you can checkout our Solana example to see how you can use it to sign transactions for Solana which uses the ed25519 curve. In general idea, we only provide the key management solution, so once you have the private key, you can basically use any chain SDK which uses ed25519.

You can check out our blockchain connection examples, If you have any particular requirement of chain, please let me know.

For the backend signing, you can checkout our SFA node SDK.

[ym.u.ichiro]

@Ayush
Thank you for your response! I have reviewed the example. Is my understanding correct that since only the management of the private key is performed, the private key must be temporarily loaded to the frontend or backend, and the signing and announcement to the blockchain need to be done independently? (I am concerned about the possibility of interception during transfer when exchanging private keys between servers.)

The blockchain I want to use is NEM/Symbol. Since this very minor chain naturally does not have an existing plugin with Web3Auth, I was at a loss as to how to connect.

If possible, it would be very reassuring if I could send the transaction data to Web3Auth without transferring the private key, and only receive the signed result back. However, if I have to load the private key, I will try to implement it that way.

Expectations:

1. Create transaction data on the server side of the app.
2. Send the data to Web3Auth, and receive a signature signed with the private key on Web3Auth.
3. Publish the signed data to the blockchain from the server side of the app.

[Ayush]

Hey @ym.u.ichiro yes your understanding is correct, we only manage the private key part, you can access the private key in frontend for PnP/SFA SDKs, and independently integrate the blockchain.

Can you explain which possibility of interception are you considering? We don’t exchange private keys between servers, the private key is mathematically reconstructed on the frontend. We don’t store private key anywhere on our server. You can read more about the SSS architecture which is used in PnP SDKs.

When you access the private key on frontend, you will sign the transaction and broadcast to the chain, here as well, there will not be any possibility of interception, since you are broadcasting the signed transaction.

Usually, once you get the ed25519 pubkey, you can derive the EOA address is it’s derived in any particular way. You can definitely generate the data to be signed on backend, and use the Web3Auth private key to sign it, and send the result to chain. It’s again independent of how you want to implement it.

[ym.u.ichiro]

@Ayush

Thank you very much! I misunderstood the specifications. I now understand that what is stored is only part of the share from SSS, and it is restored using both the frontend share and the stored share.
The concern I had was that if the private key itself were to be transferred, it could be viewed before being encrypted by HTTPS in environments with vulnerable Wi-Fi, etc. However, I understand that if only the encrypted share is transferred, there is no issue even if it is viewed.
That’s excellent. Thank you. I understand now.