Keyvault - dApp Staking Proposal

Cool! Can I get you to also re-ask the questions in Keyvault - UCG Proposal (the linked post is the UCG proposal that this dApp staking proposal has been converted into as recommended by others)?

In any case, to answer your questions in reverse order:

If there’s a data leak, what emergency plans does your team have?

It is impossible to have a data leak since everything is public and everything stored on the smart contract is encrypted with military-grade, 256-bit AES, encryption. As for how unlikely to break is that encryption, an overly conservative answer is “The encrypted password is not gonna be cracked even after billions of years unless someone tricks you into given him the encryption key.”

For a very nice video on illustrating how long/difficult it’d take to correctly guess the correct number or encryption key (since this is the only approach for cracking a 256-bit AES encryption without stealing your encryption key from you somehow), see https://www.youtube.com/watch?v=S9JGmA5_unY.

So, to summarize: Since all data is encrypted and public, there is no possibility of data leak. However, because everything is encrypted with military-grade encryption, there is nothing any attacker can do about it except for try and trick you into giving him the encryption key (which only you would have).

In terms of security, how does your team manage this? or What other protections exist?

So, now that we’ve established the near-impossibility of cracking a 256-bit AES encrypted password, the question is “Is there anything else that can be done to further protect the user?” The answer is yes.

Since the more contextual clues an attacker can find out, the more likely the attacker can

  1. figure out who you are offline and
  2. what are ways to socially manipulate you into giving him what he wants to know.

That is to say, we don’t want the attacker to know that the url of one of your passwords is <url of some regional bank and, hence, your attacker knows your location> or that your username is <name using the combination of tidbits that might be asked during password reset requests such as your name, your spouce's name, and the year you guys married or met>.

As such, what keyvault encrypts is not just your password, it is everything so that the only thing an attacker knows by seeing the data stored on the smart contract is that you have some uncrackable, encrypted entry stored but won’t even get to know if that entry is of a new password, an update of an existing password, or even the deletion of some previous password.

Additional, non-requested words from the devs at keyvault

The guiding principle we have is that security should not depend on how obscure the thing you want secret is. This is also the principle at the heart of public blockchains.

For example, your private key is a 256-bit number (note: it might not look like a number since it’s not base 10, but it is a number) and your public key is derived from it. If an attacker wants to steal the funds you have in <public key>, one approach is to guess your private key and check if that produces your public key. Once done, your funds are gone. What protects your funds is the same as what protects any password encrypted with AES: that it is near impossible to guess your encryption key or private key even after billions of years. Again, check out the cool video https://www.youtube.com/watch?v=S9JGmA5_unY.