Encrypted private keys stored by Nash?

exchange
extension
(Fabibi) #1

Dear community,@ethan, @canesin

According to the Nash Exchange User Agreement, it is indicated in some parts of the document that some encrypted keys are stored by Nash. While in other parts, it is stated that encrypted private keys will never be stored.

12 The CAS manages user accounts and authenticates users across all Services. The most important role of the CAS is to store encrypted key data on behalf of a user and serve it to client software. This key data includes blockchain keys (e.g., for NEO and Ethereum) used for state-signing and also RSA keys that are used to authenticate requests with the matching engine. The Company will at no point in time have access to raw key data and stores the Account Access Information only such that it can be decrypted client-side and used to interact with the exchange.

15 When creating an account with the Nash Exchange, the User will be prompted to create a Wallet. The Wallet consists of a number of different blockchain wallet addresses upon different chains, interaction with which is only possible through the use of cryptographic private keys, which will be provided to the User in encrypted form and which will never be stored in any way by the Company.

I may be misunderstood something. Are we talking about the same type of keys? Could you clarify this please.

.

.

1 Like
(Ethan Fast) #2

The above is saying two things:

  1. Private keys will never be stored in any way by Nash
  2. Nash stores encrypted keys for you, which will be decrypted client-side using information only you know (but totally automatically!) to interact with your funds.

There is no inconsistency in (1) and (2). You encrypt your private keys and store them in Nash, and we (or anyone else who somehow finds those encrypted keys) don’t have enough information to decrypt, and so fundamentally do not have access to the keys.

6 Likes
(Guardian Circle) #3

We are solving this exact same issue for the $GUARD wallet in this exact same way – I am familiar with what Ethan is describing here: he is correct, I can vouch for it, having spent a ton of time looking at the same legal and technical issues.

2 Likes
(Alex) #4

Illustrative example:

Your Private key (A) is: f63da72
Nash stores key (B): h32l983HF5sfd1a3

To go from B to A (decrypting) you need information that is only available to you. It works because to go from A to B (account creation) you had to give some input like a password, or the encryption program (on account creation) generated and stored some unique information locally on your device only.

_https://en.wikipedia.org/wiki/Client-side

Because a client-side program is running locally inside you browser, it has access to this local stored information allowing the decryption to happen. Running the same program on a different device, will give a different output (key A) because the information on this device is different or non-existent.


If B (server) gets compromised somehow. It will be very difficult to hack the actual private key. Hackers could then aswel try to generate each possible private key in the world. (requires similar efforts)

Nash could even choose to change the stored key (B) each time you login. For example by running the encryption program again (inside your browser), but with different instructions…
Thats really up to the Nash security designers to decide what works best with their key-management soulution. This key-management soulution is important because its not the cryptography that is the weak link here. Its the end-user himself.

Storing an encrypted key on Nash its end, allows for building such user-friendly key management soulutions.

2 Likes