Keyvault - dApp Staking Proposal

Governance dApp Staking Applications
21

Regarding the suggestion of diagramming: Yes, you’re right. I’ve been meaning to work on getting visuals to help communicate the mechanism. I’ll try to make time to do that soon-ish.

Regarding how audits are conducted and managed: Part of what I want to use the money from dApp staking is to get audits from 3rd parties. At the moment, it’s just me coming up with ideas and just keep trying to see if there are issues with it. Far from a 3rd party audit (something I want but can’t afford for the project currently), but if it helps, here’s an example of something I had to change and my thought process (simplified) behind it.

(For example, my initial version for the data structure that stores the passwords is something like

struct EncryptedEntry { string iv; string ciphertext; }

// usage: entries[msg.sender]["some_bank.com"]["lousydropout"] -> ciphertext
mapping(address => mapping(string => mapping(string => EncryptedEntry))) private entries;

and then the Chrome extension would decrypt the ciphertext.

I started implementing this, then realized that 1. the username being public could mean leaking the user’s real world identity and 2. the url being public could at the very least potentially attract unwanted attention. So, I switched to something like

struct EncryptedEntry { string iv; string ciphertext; }
mapping(address => EncryptedEntry[]) private entries;

where to get any info (such as url, username, password, if the entry is new, an update of an earlier entry, or an earlier entry marked as deleted), it’d have to be decrypted first.)

2 Likes
22

Hi @lousydropout and the Keyvault team,

Glad to see your dApp staking application. I totally agree with your mission that everyone has to have own access to their passwords. The idea is truly amazing and a great example of blockchain usecase! Very curious to see how it goes and grows!

Let me have a few questions to clear some of my curiousity.

  • Personally, I prefer to use KeePassXC, as it stores the data locally and I found it secure the most among many password manager applications after some DD. If I am not mistaken, it is an open-source application (see GitHub - keepassxreboot/keepassxc: KeePassXC is a cross-platform community-driven port of the Windows application “Keepass Password Safe”.). Can you give me major difference between this type of open-source password managers and Keyvault other than blockchain-based application, for example, in terms of security etc., I am just very curious to know :slight_smile:

  • Will Astar Network be the main network for Keyvault? If so, if any, would you be able to what brought Keyvault to Astar Network than other protocols?

Best regards,
pithecus

1 Like
23

Hi,

Regarding the difference between security for open-source password managers and keyvault: I would say it depends on whether or not the data is encrypted using a passphrase or a randomly generated number/string.

Here are how the two look like:

  • passphrase: Roses are red and violets are blue, not violet!
  • encryption key: here is how an AES-GCM encryption key look like in JWT format. The key part is the randomly generated number/string k:
    {
  "alg": "A256GCM",
  "ext": true,
  "k": "MR9ioAcPn-zI_M5k8AfCCORnDw12AWZhLCM_um9jKAM",
  "key_ops": ["encrypt", "decrypt"],
  "kty": "oct"
}

Since memorable-but-hard-to-guess passphrases can be difficult to generate, they are considered to be less secure than using a randomly generated 256-bit string.

So, if a password manager encrypts using passphrases, then I don’t believe the encrypted data should be stored anywhere public such as a blockchain. Instead, they should be coupled with another gating mechanism.

If the password manager encrypts with an encryption key generated using a random 256-bit number, then storing this in public is fine. This is because cracking a 256-bit encryption is the same as guessing correctly the 256-bit key and it is essentially impossible guess with a non-insignificant chance of success. For example, your bitcoin public key is generated from your private key, a 256-bit number. If an attacker can correctly guess that number, then your funds are lost. Since that is a near-impossible task, your public keys are safe to show publicly.

I would say that a password manager’s security is determined by its encryption and not by using, or not using, a blockchain. Instead, the main benefits of using a blockchain for a password manager are

  • availability (it’s much harder for an attacker to take down all the validator nodes than it is to take down an API server or database) and
  • censorship resistance (if a password manager gates access to your encrypted passwords behind an API, then your continued access is at their mercy. similar if you store your encrypted data in dropbox, google drive, or what not).

Yes, the idea is for Astar Network to be the main network for keyvault. I don’t think there’s a need for multiple networks in any case. As for why… well, to begin with, this project started as an ink! hackathon project and the judge from Astar was the only one to reach out and encourage me to continue with the project. That, plus that Astar’s gas fees are sufficiently low for me (my main requirement), simply lead me to focus on the Astar network.

5 Likes
24

Hello hello @lousydropout and welcome to Astar :star2:
This seems like an interesting project to list on dApp staking :smile: As @Juminstock suggested I think it would be more suitable for a UCG application. I will support this proposal

2 Likes
25

Thanks! I am definitely open to that and have been thinking about it since @you425 brought up UCG and reading @Juminstock’s explanation.

If I am understanding correctly, based on checking out past UCG proposals in this forum, the main thing I need to convert my current proposal into a UCG proposal is to provide a clear timeline in the roadmap? Is that correct? My current roadmap lists things I want to accomplish but lack an ETA since it’s not clear to me how long these will take. I’ll need to look over them again and consider a proper ETA for each.

Is there anything thing else I need to do to convert the current proposal into a UCG proposal? Change tags for this thread? Or, resubmit?

2 Likes
26

Yes, there have been instances in the past where it has been converted to UCG, but at that time it was a new thread. However, that time the change was made before so many comments were made, so I don’t know if it would be appropriate this time as well.
If you are going to convert to UCG, as you say, a more specific roadmap will be needed.

@Gaius_sama @0xRamz
What do you think about this case?

3 Likes
27

@lousydropout yes, for UCG I would recommend a new thread (and link this thread if readers want more context) - mainly to keep things in order and if voted to join UCG, you can post your monthly updates in the thread. In case you haven’t seen what the UCG expectation are, you can find out more here:

I would suggest to take the current roadmap and break it down to realistic, feasible milestones, that is manageable given your resources and that can be brought forward to the community as proof of your continuous building.

In the end the most important aspect of UCG is to support you as a builder with a monthly reward, allow you to develop at your pace, and be connected to a great community that is following along your journey and giving input as you build.

Thanks again for building on Astar :slightly_smiling_face:

3 Likes
28

Thank you to everyone for all the feedback, questions, and recommendations!

Following the growing recommendation to switch to UCG, I’m gonna take a day or two to try and create a roadmap with ETAs before submitting a new proposal for UCG. (The roadmap I provided in the proposal above listed the main goals I’d like the project to achieve but lacked an estimated timeline. Further, it also left out more mundane but important tasks that I intended to take care of in the background but perhaps that they should be better specified in the new proposal.)

Thanks again!

2 Likes
29

Very interesting project.

In this case, are you using some technology similar to MPC to secure this password, similar to what Web3Auth is using?

1 Like
30

Thanks!

As for the question: There is a tech similar to MPC called Shamir's Secret Sharing algorithm (SSS). However, I believe SSS to be useful as a “social recovery” mechanism rather than as a way to help secure passwords.

The encryption key acts as a master password within the design of keyvault and SSS would allow you to, for example, split up your encryption key into 5 strings (called “shares”) such that your encryption key can be recovered if 2 or more of those “shares” are brought together. So, you can imagine sending out those 5 “shares” out to friends and family members in case you ever lose your encryption key.

Since, I’d imagine, it’s probably somewhat of a tall order for your friends to NOT accidentally misplace/lose the “share” you entrusted them with over time, keyvault does intend to build a management layer on top of the password manager. So, if you lose your encryption key, you’ll be able to recover if at least 2 of your friends (who you gave a “share” to) still has access to their keyvault account (i.e. have not lost their encryption key).

31

Hey, nice project!
Have I am used Keepass before. WIll there be an app for that in the future too and not only an browser extension?
Nice work so far! :slight_smile:

1 Like
32

Thanks! And, yes, definitely :slight_smile: An app (I assume smartphone, and not desktop, app) for keyvault is definitely on the roadmap.

33

Just submitted the UCG proposal version of this proposal: Keyvault - UCG Proposal.

3 Likes
34

@defiguy, wanted to say, while answering your question about whether keyvault uses tech similar to MPC for securing passwords (answer: yes, Shamir Secret Sharing algorithm, as a social recovery mechanism for recoverying the encryption key or master password), I realized that this feature is also useful for recovering one’s wallet private key or seed phrase.

Thanks for triggering this realization for me! :slight_smile:

1 Like
36

This looks very interesting. I’d like to ask a few more questions:

  1. In terms of security, how does your team manage this?

  2. On the other hand, if there’s a data leak, what emergency plans does your team have?

1 Like
37

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.

38

Great. Thanks for the answer, looking forward to test it.

1 Like
39

Loud and clear!!! Thank you a lot for your clarification =)

40

[also posted in the UCG proposal thread]

Hi, quick update.

I’m gonna switch the smart contract from ink! to solidity. I dunno if anyone really cares to know this, but thought I should report it nonetheless for transparency’s sake. Also, I don’t expect this initial switch to take more than a few days.

The reasons for this switch are

  1. the service I was depending on to validate the ink! smart contract, polkaholic.io via ChainIDE, is currently down (The outage has apparently been noticed by others a while ago, but, since it’s still down, I don’t expect it to come back up anytime soon) and

  2. other services for verifying ink! smart contracts, as detailed in articles and blog posts, are also down.

Plus, given that I feel fairly familiar with solidity, I expect switching to solidity is gonna prove much less of a hassle.

– lousydropout

2 Likes
41

Thanks for the update ! Glad to see You have also shared this detail :slight_smile:

1 Like