ImportShare RPC call failing on the first RPC node

Hello, we need to import a private key to a verifier via the ImportShare call and for some reason on the node 1 we are consistently getting error 502 while on other nodes the call works fine. Are you aware of any issue with the node 1 on sapphire mainnet (https://node-1.node.web3auth.io/sss/jrpc)? The error happened around 10 PM CEST, June 28th, could you please look into it?

Interestingly, we observed the same error also on the first RPC node at sapphire devnet:
https://node-1.dev-node.web3auth.io/sss/jrpc

Here’s an example of the failing RPC call (which now in turn fails because the timesigned params have expired):

curl 'https://node-1.node.web3auth.io/sss/jrpc' \
  -H 'accept: */*' \
  -H 'accept-language: en-US,en;q=0.9' \
  -H 'content-type: application/json; charset=utf-8' \
  -H 'origin: https://wallet.nu.fi' \
  -H 'priority: u=1, i' \
  -H 'referer: https://wallet.nu.fi/' \
  -H 'sec-ch-ua: "Not/A)Brand";v="8", "Chromium";v="126", "Google Chrome";v="126"' \
  -H 'sec-ch-ua-mobile: ?0' \
  -H 'sec-ch-ua-platform: "macOS"' \
  -H 'sec-fetch-dest: empty' \
  -H 'sec-fetch-mode: cors' \
  -H 'sec-fetch-site: cross-site' \
  -H 'user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/126.0.0.0 Safari/537.36' \
  --data-raw '{"jsonrpc":"2.0","method":"ImportShare","id":10,"params":{"encrypted":"yes","use_temp":true,"distributed_metadata":true,"item":[{"verifier_id":"katushkadubajova@gmail.com","idtoken":"eyJhbGciOiJSUzI1NiIsImtpZCI6IjJhZjkwZTg3YmUxNDBjMjAwMzg4OThhNmVmYTExMjgzZGFiNjAzMWQiLCJ0eXAiOiJKV1QifQ.eyJpc3MiOiJodHRwczovL2FjY291bnRzLmdvb2dsZS5jb20iLCJhenAiOiIxMDk4MDY5MjQ2ODk1LTVuczQ2ZWl1MGlpM2hsaWE3NHFpOWZiOXBidWhyNzQ3LmFwcHMuZ29vZ2xldXNlcmNvbnRlbnQuY29tIiwiYXVkIjoiMTA5ODA2OTI0Njg5NS01bnM0NmVpdTBpaTNobGlhNzRxaTlmYjlwYnVocjc0Ny5hcHBzLmdvb2dsZXVzZXJjb250ZW50LmNvbSIsInN1YiI6IjEwNzk1NTIzNjUyMjU1MTI1ODkzMiIsImVtYWlsIjoia2F0dXNoa2FkdWJham92YUBnbWFpbC5jb20iLCJlbWFpbF92ZXJpZmllZCI6dHJ1ZSwiYXRfaGFzaCI6IjBMVVRGQ3VQcE5mYkh0T0FlbE5QSnciLCJub25jZSI6InQ4N3VrYzcyY3VtIiwibmJmIjoxNzE5NjA0MzQ5LCJuYW1lIjoiS2F0YXLDrW5hIEtvcmJhxaFvdsOhIiwicGljdHVyZSI6Imh0dHBzOi8vbGgzLmdvb2dsZXVzZXJjb250ZW50LmNvbS9hL0FDZzhvY0sycURwalhTQnY4ZW01T3RHaHppNzNQSGl3Tk9pd1pCbW5Vd05ib2xyS3NBQjl2cUx6Mmc9czk2LWMiLCJnaXZlbl9uYW1lIjoiS2F0YXLDrW5hIiwiZmFtaWx5X25hbWUiOiJLb3JiYcWhb3bDoSIsImlhdCI6MTcxOTYwNDY0OSwiZXhwIjoxNzE5NjA4MjQ5LCJqdGkiOiJiNjNjODMyODRkMGM2ZDllY2NkNTFhMWUwMGE4N2FkZDYyNDk3ZjA2In0.cXEsJ1VHQIoqmCXzzIPHUj3CeWzLMku2xQnbFJ_8cbrx94uhzVyOQbyHZ0GbUvl_dy2bdSAIRc_NnO58fQVeZbOGNDYMOmHjjn4dr37Hf8kmXEZUrugyS-ormWkOVPh18p0aJ1r9dWaFH5HFGQgbbWFd8kkyJOthnea88XRxUPSB6QL4uuHMZqPdx25bz5o2dga_CunvYsQHmL5qhaCI0zYktAPn3eZrL5_RjFGreCAtuB6V9iOSudQaOBPd9k-sNAKwRtVDs_B9UD4wOeDWxUM_c3TDz-ADjWlkDdfFfEBX3lhvW1MkatSOfEn7konH8CPzILIHDRdE6I0HpJmhzg","nodesignatures":[{"signature":"ca7b8150c994b56416b94eed8e145047841e93dbff8a40668237933ac4e66724056e45809f5afe731979158826995d36a05f9dd47d3a106a08ac9c60a3c4d6021c","data":"mug00\u001ce0da8edaa33bcc99d515d52bd2c4c43cfe44672c33e2b1ad14dd82cd674b2363\u001c6f23bfba78e61b97f6757e86970e6b9406350558f578375ca9270924bf7687e7\u001c5dc35c70555e3810cc6f563fac5a134aac30c7458f0ce34b8f1d24071533259c\u001cnufi-w3a-google\u001c1719604665","nodepubx":"e0925898fee0e9e941fdca7ee88deec99939ae9407e923535c4d4a3a3ff8b052","nodepuby":"54b9fea924e3f3e40791f9987f4234ae4222412d65b74068032fa5d8b63375c1","nodeindex":"1","pub_key_x":""},{"signature":"cd52ba2412a891607ad2bde30a2bf6cd5f683d74b5e8a64fe0c9b6b9c92c2f0e2fda7be3dcf50447ac80c16e2e566f3a87a309d815daad13a764ae06d584ac851c","data":"mug00\u001ce0da8edaa33bcc99d515d52bd2c4c43cfe44672c33e2b1ad14dd82cd674b2363\u001c6f23bfba78e61b97f6757e86970e6b9406350558f578375ca9270924bf7687e7\u001c5dc35c70555e3810cc6f563fac5a134aac30c7458f0ce34b8f1d24071533259c\u001cnufi-w3a-google\u001c1719604665","nodepubx":"9124cf1e280aab32ba50dffd2de81cecabc13d82d2c1fe9de82f3b3523f9b637","nodepuby":"fca939a1ceb42ce745c55b21ef094f543b457630cb63a94ef4f1afeee2b1f107","nodeindex":"2","pub_key_x":""},{"signature":"9b8f91f5c218774fed956999c825e03088cf669590642ac20ff08ab13912d78f518e44f4666d9a4d06577407ba555ef6db4be3399dd7c528ac7e03d013ba437d1c","data":"mug00\u001ce0da8edaa33bcc99d515d52bd2c4c43cfe44672c33e2b1ad14dd82cd674b2363\u001c6f23bfba78e61b97f6757e86970e6b9406350558f578375ca9270924bf7687e7\u001c5dc35c70555e3810cc6f563fac5a134aac30c7458f0ce34b8f1d24071533259c\u001cnufi-w3a-google\u001c1719604665","nodepubx":"555f681a63d469cc6c3a58a97e29ebd277425f0e6159708e7c7bf05f18f89476","nodepuby":"606f2bcc0884fa5b64366fc3e8362e4939841b56acd60d5f4553cf36b891ac4e","nodeindex":"3","pub_key_x":""},{"signature":"218a38fe26084aa70a49c3400d5a5aff3577c231cebd53d744aa2958f68d190f042a7ddaac713083e742736979712a0dbc0ae813da44c22f5e74b5669e9da0af1c","data":"mug00\u001ce0da8edaa33bcc99d515d52bd2c4c43cfe44672c33e2b1ad14dd82cd674b2363\u001c6f23bfba78e61b97f6757e86970e6b9406350558f578375ca9270924bf7687e7\u001c5dc35c70555e3810cc6f563fac5a134aac30c7458f0ce34b8f1d24071533259c\u001cnufi-w3a-google\u001c1719604665","nodepubx":"2b5f58d8e340f1ab922e89b3a69a68930edfe51364644a456335e179bc130128","nodepuby":"4b4daa05939426e3cbe7d08f0e773d2bf36f64c00d04620ee6df2a7af4d2247","nodeindex":"4","pub_key_x":""},{"signature":"4ca4a01f2688e94bed9916bc2f897a864bd0d9a14ef93018175e2ae263c3c74b5fb6d0df13c1535491ff953c16fff99263cd1c072d4d2e72e383cf65c72c08031b","data":"mug00\u001ce0da8edaa33bcc99d515d52bd2c4c43cfe44672c33e2b1ad14dd82cd674b2363\u001c6f23bfba78e61b97f6757e86970e6b9406350558f578375ca9270924bf7687e7\u001c5dc35c70555e3810cc6f563fac5a134aac30c7458f0ce34b8f1d24071533259c\u001cnufi-w3a-google\u001c1719604665","nodepubx":"3ecbb6a68afe72cf34ec6c0a12b5cb78a0d2e83ba402983b6adbc5f36219861a","nodepuby":"dc1031c5cc8f0472bd521a62a64ebca9e163902c247bf05937daf4ae835091e4","nodeindex":"5","pub_key_x":""}],"verifieridentifier":"nufi-w3a-google","pub_key_x":"f33ffc3d5c249f73dad6f0279785a236d1d97092b43fb88ffc2055f3c3c21da5","pub_key_y":"07d55119b7cae69183358c2b44ec645f49b6b016b0a37a9b94336f434bacd7a1","encrypted_share":"9b4d3f4bde427f40dbb287a986353860e182b807724e414b368092c2eb5ea1520848f190140c8be1771709b7571c2f77","encrypted_share_metadata":{"iv":"616ad5576a2eca859e036e5ce6113249","ephemPublicKey":"04ab4a77e9273c4748d8aec5e16f369b5432a11d8cef1f6f54e689d071d6ec6f8c53f109bdf7691e451a23acc720aa48aabe9e9cc4fcc1b5cdb93a072db97b5d63","ciphertext":"9b4d3f4bde427f40dbb287a986353860e182b807724e414b368092c2eb5ea1520848f190140c8be1771709b7571c2f77","mac":"1dacf06d2935ad723674d34a498754ef8cd645aec90e4d3f64b4974509f79389","mode":"AES256"},"node_index":1,"key_type":"secp256k1","nonce_data":"eyJkYXRhIjoiOTkwNmVlOWU0MWRhNjAyOWU2NjBlMWQ4ODBiMzIxYTIwZTY1MjQ5OTZkNTRkZmZiMjFlZDkzODg5OWU2ODY2YiIsIm9wZXJhdGlvbiI6ImdldE9yU2V0Tm9uY2UiLCJ0aW1lc3RhbXAiOiI2NjdmMTViOSJ9","nonce_signature":"ON6hmmRYC/frYEW761rVKm9gnwvBTUCjoPIfDQQeUh38TsVcaaYwD2SP930gd1MK8aCxLGvVo8O/sb/P9vvPcgA=","session_token_exp_second":86400}],"one_key_flow":true}}'

<html><head>
<meta http-equiv="content-type" content="text/html;charset=utf-8">
<title>502 Server Error</title>
</head>
<body text=#000000 bgcolor=#ffffff>
<h1>Error: Server Error</h1>
<h2>The server encountered a temporary error and could not complete your request.<p>Please try again in 30 seconds.</h2>
<h2></h2>
</body></html>

We tried doing the key import with the latest torus.js library from npm (v12.3.6), this is how the relevant code looks like and it worked in the past without issues:

import NodeDetailsManager from '@toruslabs/fetch-node-details'
import Torus from '@toruslabs/torus.js'

...
const authInstance = new Torus({
      clientId: web3AuthClientId,
      enableOneKey: true,
      network: web3AuthNetwork,
    })
...
const fetchNodeDetails = new NodeDetailsManager({network})
  const {torusNodeEndpoints, torusIndexes, torusNodePub} =
    await fetchNodeDetails.getNodeDetails({
      verifier,
      verifierId,
    })
  return await authInstance.importPrivateKey(
    torusNodeEndpoints,
    torusIndexes,
    torusNodePub,
    verifier,
    {verifier_id: verifierId},
    idToken,
    privateKey.toString('hex'),
  )

Hey @rafael.korbas, thanks for reporting. We’ll try to reproduce and update you on the issue.

1 Like

Hi @Ayush, are there any updates on this? Were you able to reproduce the issue?

Hey @rafael.korbas sorry for delays, yes, I’m able to reproduce the issue of 502 bad gateway for node1. I’ll have a talk with team, and let you know the next steps.

1 Like

Hey @rafael.korbas, looks the implementation was still work in progress. We’ll be releasing a new version of torus.js, meanwhile if you want to test it out. You can use the 13.0.0-alpha.7 of torus.js. Please let me know if this fixes.

Thanks @Ayush , 13.0.0-alpha.7 seems to work fine for me indeed. I tried also version 14.0.0 of torus.js and that is still failing though.

I have 3 questions/requests:

  1. Could you please port the relevant changes to torus.js v14 so that we can safely use the latest version of the lib?

  2. if we have some existing “partially” imported keys (which for some reason happen to differ from the original one), are they safe to use or can they somehow get corrupted over time? An example for such key that got “corrupted” by import failing on node1 is e.g. this one (non sensitive) if you’d like to check:

network: sapphire_mainnet
verifier: nufi-w3a-google
verifierId: registracia7@gmail.com
keyType: secp256k1
  1. Could we provide you over DM the impacted verifiers/verifierIds so that you reset the keys and we can initiate the migration again?

Hey, glad to know. The 14.0 won’t have the fix, the fix will be available in 15 or greater version. The new release will go live soon.

  1. I’ll need to check, we don’t maintain a migration guide or docs for torus.js since it’s a low level SDK and we don’t recommend using it. Alternative would be to use tKey JS SDK.
  2. You mean because of node 1 failing, new addresses were generated for the users instead of getting existing wallet imported? If yes, it won’t get corrupted. If a private key new is not imported, a new BN is generated, in case of private key imported, it uses the existing BN, you can check the implementation. We do recommend enabling the MFA for the users so they can always recover account in case of share not available.
  3. I’ll have to check on this, will update
1 Like

@rafael.korbas can you tell me how did you create the account? Did you have any fallback mechanism which created a Web3Auth account incase of importPrivateKey failure?

Hi @Ayush, sorry for the late reply

@rafael.korbas can you tell me how did you create the account? Did you have any fallback mechanism which created a Web3Auth account incase of importPrivateKey failure?

I’d say there isn’t any special fallback mechanism on our end, the failed import just seems to have automatically resulted in a creation of a new (or at least different) key on the custom verifier. We can check with the user if they “care” about this key, but most likely not, in which case it would be great if we could just wipe this new key off our custom verifier to let the user go through the migration again - would such key deletion be possible on your end?

A more detailed description of our process:
We (i.e. our app, client-side) reconstructed locally the original private key from the public verifier (tkey-google) and then within our migration flow we imported that key with the importPrivateKey() call to our nufi-w3a-google custom verifier, as outlined in the question above, but the process failed which apparently resulted in the creation of a new key in our custom verifier (fallback logic by torus network? - we don’t handle failure of import on our end) .