The safest software wallet for crypto

Nash has upgraded our client protocols to generate signatures with secure multi-party computation (MPC), the technology behind our decentralized API keys. Our non-custodial blockchain wallets can now offer hardware-level security at no cost!

This upgrade means that users’ full private keys no longer play a role in signing transactions on Nash. Instead, transactions are co-signed with Nash via MPC, enabling us to enforce security policies like address whitelisting and withdrawal limits.

Users can still store their seed phrase and private keys offline for use with third-party wallets, giving them full access to their funds if Nash is offline – just like the paper backup of a hardware wallet seed phrase.

Unlike hardware wallets, however, Nash accounts are completely free and have the look and feel of familiar online platforms. What’s more, with configurable security policies, they are arguably safer than hardware. If your Nash login is hacked, the damage an attacker can do is limited.

Thanks to MPC, holding the keys to your crypto became safer and easier!

What is multi-party computation (MPC)?

A blockchain approves or refuses a transaction by verifying its signature. A private key is one way of generating a valid signature. If you have the private key for an address, you can always sign transactions going out of that address.

However, there are other ways of generating signatures that do not give one party all the power. By splitting the generation of signatures between two parties, it becomes impossible for one party to approve transactions unilaterally.

This can be achieved using secure multi-party computation (MPC), where two parties must collaborate to generate a valid blockchain signature. Using our new protocol, both Nash and a user have their own key. These keys each generate what is known as a “pre-signature”. The two pre-signatures are then combined into a single valid signature.

Advanced non-custodial security

MPC makes it possible for users to set up specific permissions associated with their account – for instance, a withdrawal address whitelist or withdrawal limits. If a user attempts to withdraw too much, or to the wrong address, Nash will withhold its pre-signature and nothing will happen.

Of course, Nash alone is also unable to issue or authorize any transaction. The system is designed such that the user is the only one capable of initiating transactions. It remains non-custodial.

You can hear our Applied Research team – Nash co-founder Ethan Fast and applied cryptographer Robert Annessi – discuss MPC on Episode 1 of our podcast Beyond the Chain.

The Nash wallet system in detail

Here’s a more technical overview of how Nash’s MPC protocol is implemented. First, we describe how keys are set up when the user creates an account, then how they are used on subsequent logins.

Account creation

1. A master secret is generated securely in the user’s browser. This secret is used to derive private keys for all blockchains supported by Nash.
2. The user’s login information (email and password) is hashed in the browser and two key pairs are derived, one for authentication (normal login) and one for encryption/decryption. The encryption/decryption keys are never sent to Nash but are rederived locally whenever a user logs in – meaning Nash can never decrypt the user’s private wallet information. The authentication key is used to authenticate user login with the Nash server, just like a normal password exchange on a typical website.
3. The master secret is encrypted using the user’s encryption key. Call this the encrypted master secret. A backup of the encrypted master secret is sent to Nash – but Nash cannot decrypt this information, since this would require the user’s decryption key.
4. For each blockchain key derived from the master secret, the user’s browser generates two sub-keys using a 2-2 MPC key generation protocol. When some data is signed by each of these keys independently, the resulting signatures can be combined to produce a signature as if the original private key signed the information. This kind of protocol is called a threshold signature protocol, with the central property that one sub-key alone cannot sign anything, and when co-signing the original private key is never accessed or constructed by either party.
5. One sub-key is sent to Nash to store unencrypted. This is Nash’s key, which can be used to approve future trades and transactions. The other sub-key is encrypted with the user’s encryption key and stored by Nash for retrieval by the user’s browser when they next log in. Nash cannot use or access this key because it is encrypted.

So, Nash has access to one sub-key but not the other. The user retrieves their sub-key by logging in, getting an encrypted data package from Nash and decrypting it. This all happens automatically with keys derived from user login information.

Login

1. The user’s decryption key is derived in their browser from their username and password. The authentication key is also derived and used to log in, with an optional 2FA check.
2. After the user authenticates with their account info, authentication key and optional 2FA, their encrypted MPC sub-key is sent from Nash to their browser.
3. The user’s browser decrypts the MPC sub-key and uses it to provide signatures for trades or other transactions on the Nash platform. If the activity meets the policy requirements set up by the user, Nash will “complete” these signatures with its own sub-key to produce the signatures required for the user’s activity. For transactions, the resulting completed signature will be sent to the chain. For trades, the signatures will be processed like any other user signatures in the Nash state channels.

In the event that their sub-key is compromised, a user can log in and revoke it, and an attacker does not have the power to do anything with the blockchain funds in their account. Users can also retrieve their encrypted master secret from Nash to recover their full private key information by passing additional 2FA and email verification rounds.

The future of crypto funds management

The Nash wallet system represents a significant advance over current popular solutions for storing cryptocurrency.

• Funds held on centralized exchanges are vulnerable to hackers and contradict one of the basic principles of digital assets: self-custody.
• Software wallet solutions, e.g. encrypted private keys, are vulnerable to hacks of user machines. Once a keylogger or phishing website has stolen your password, all your funds can be drained.
• Hardware wallets are an excellent solution for secure long-term storage, but inconvenient for users who make frequent transactions or want a mobile wallet. They are also expensive and too complicated for first-time users.

Nash’s MPC-based system overcomes all these issues. Nash wallets are fully non-custodial, but at the same time offer advanced security unlike other software wallets, protecting users whose login details are compromised. Moreover, they are completely free and as simple as email – on both desktop and mobile!

This new system represents the future of crypto funds management: secure, convenient, free and accessible to anyone.

Read our technical paper on Nash’s MPC protocol.

You can stay up to date with Nash by following our Twitter and Instagram, as well as joining our official Telegram group. We also encourage all Nash Exchange token (NEX) holders to join our community platform, where they can talk directly with the team and receive reliable answers to questions.