Keyvault - UCG Proposal

Hi buddy, really grateful for your proposal and for sincerely sharing your complications with the project.

Personally I have encountered many problems, issues or bugs when working with ink! but the biggest problem is that there is very little documentation or support in the ecosystem, that is something I would like to help with in the future.

I think you can work on all this together with a team if you go to the UCG program, once you are there I recommend you to share your idea with good devs to help you to take this to the next level, however you can always count on the support of the Astar community.

I will study this problem to find solutions for future problems, thanks for sharing all the data.

1 Like

An additional issue is that, based on what I see in threads of approved UCG proposals, a verified contract’s address is required. Given the issues I mentioned with third-party services, I’m not confident I can get the ink! contract publicly verified in a timely manner.

That said, especially given that this project started as an ink! hackathon project, I’m also not keen on abandoning ink!.

One approach that I’m considering is using solidity for official purposes (i.e. the required verified contract address and the proposal’s roadmap) while working on the ink! version as well. I’m hopeful this is possible since this project’s smart contract is pretty basic given that most tasks, such as encryption and decryption, need to occur off-chain. That is to say, I expect much of the upcoming work to be shareable across the two versions.

1 Like

The roadmap is very clear, and the section on competitors demonstrates that the team has thoroughly researched the market. I have just one small question regarding the security of storing users’ passwords. Users may choose to store their passwords on-chain, but if hackers become familiar with your protocol, could they potentially locate and decode those password fragments?

1 Like

Hi! Thanks for checking out the proposal!

TL/DR: What’s stored on-chain are not the passwords themselves but the encrypted versions of them. Further, knowning the structure of the smart contract won’t help a hacker in deciphering the password from the encrypted text.

Longer version:

Let me answer 3 questions that you’re likely to ask:

  1. What is actually stored on-chain?
  2. What does a user need to decrypt/decipher the encrypted passwords stored on-chain?
  3. How easy is it for a hacker to decrypt an encrypted password without the master key?

1. What is actually stored on-chain?

The passwords themselves are not stored. Rather, it is the encrypted versions of the passwords. For example, suppose we have the following

    "url": "",
    "username": "",
    "password": "this_is_not_my_actual_password_123",
    "description": "password for personal gmail account",
    "idx": "-1",
    "timestamp": "2024-07-02T14:34:01Z",
    "deleted": false

What ends up being stored on-chain is something like the following (btw, this is what I’m referring to as the “encrypted password” for simplicity):


As you can see, the encrypted password that’s stored on-chain are 2 strings that look essentially like gibberish.

(Note: The encrypted password shown here contains my actual gmail username and password.)

2. What does a user need to decrypt/decipher the encrypted passwords stored on-chain?

In order to decrypt the encrypted text and get back the actual username and password, a user needs a “master key” of sorts. A “master key” looks like the following:

  "alg": "A256GCM",
  "ext": true,
  "k": "MR9ioAcPn-zI_M5k8AfCCORnDw12AWZhLCM_um9jKAM",
  "key_ops": ["encrypt", "decrypt"],
  "kty": "oct"

The important thing to note here is the field k. k acts as the “master password” that lets you decrypt an encrypted text and, as you can see, k is a very long, random string (meaning, very difficult to crack or figure out).

3. How easy is it for a hacker to decrypt an encrypted password without the master key?

The encryption algorithm used here is called AES (Advanced Encryption Standard) and is generally considered to be the most secure form of encryption available.

Aside from certain rare and specific situations that are not applicable here, the only way to crack AES encryption is by brute force. And since keyvault uses 256-bit AES, it will take approximately 2^(256-1) = 2^255 attempts.

To give an idea as to how computationally intensive it’d be to make 2^255 attempts, please see a very nice and short video by 3Blue1Brown: (The video uses SHA-256 for its context, but the calculation is directly applicable to 256-bit AES encryption.)

Spoiler: An attacker can have a ridiculous number of Google supercomputers attempting to crack the encryption non-stop for billions of years and the attacker would still only have a 1 in 4 billion chance of succeeding.

1 Like

Great Move!!! We’re looking forward to make great things together =)

1 Like

Me too! Very excited :slight_smile:

Hi, I have a question, if you try to create a key recovery system, how do you plan to do it? will you do some point to point encryption, a black box, with the smart contract?

I think security in this case goes hand in hand with privacy and if the conditions are not adequate many users may be at risk, thank you.

1 Like

Let me first explain the basic concept of a key recovery system independent of keyvault.

Basic description of recovery using Shamir Secret Sharing

The idea is to split up your encryption key into multiple pieces such that, say, any 3 of them together can restore your encryption key and then share those pieces with your trusted contacts (e.g. friends and family).

Then, when you need to recover your key, you’d call any 3 of those you shared it with (assuming they haven’t lost theirs).

They’d confirm that you’re not some deepfake scamming trying to steal their piece of your key from them by, ideally, talking to you in person or, less ideally, through whatever procedure you guys have decided.

Once your contact has confirmed that you are who you say you are, they’d give you their piece of your key.

You’d then combine the 3 pieces together to recreate your encryption key.

The difficulties with the above version and if/where keyvault fits in

  1. Your friends and family, whom you’ve shared your key with, could lose their piece of your key.

  2. You need a secure way to share your key with your friends and family.

  3. Your friends and family could be tricked into giving their piece of your key to someone pretending to be you.

keyvault can deal with points 1 and 2.
(1) by providing a place for your contacts to securely store their piece of your key and (2) by faciliating secure messaging.

Point 3 requires more of a human solution. Your contact simply needs some way of confirming that it is not just some attacker pretending to be you (maybe by talking to you in person) before sending their piece of your key.


Awesome!!! Thank you so much for your clarification =)

1 Like

Thanks for the explanation, now I understand better how they operate, this dispels my doubts.

Hello @lousydropout

Congratulations! :tada:

The voting is passed.

To proceed with the registration, please do the following:

  1. Have a native Astar wallet with some transferrable 10 ASTR. Share the address here. No ledger wallet or EVM wallet.
  2. Have a verified smart contract on Astar Network (Layer 1) and share the contract address here. No zkEVM smart-contract.
  3. Add #astar-network, #dAppStaking tags to your GitHub repo.
  4. Fill the form to be added to the Ecosystem Page on the Astar Network website.

Guide: Register dApp | Astar Docs

We will whitelist your addresses for dApp Staking.


Congratulations team! I hope to see the improvements and protocol updates soon
Let’s go and welcome aboard.


Thank you for the clear and concise explanation of recovery using Shamir Secret Sharing. It perfectly outlines the process and potential challenges, and how keyvault can address some of these issues. Much appreciated!

1 Like

Woohoo! Thank you to all who voted and/or asked questions, providing me a chance to better explain the proposal :pray:

This is very exciting for me! Thanks!


Much success with your project, I want to see how you solve the current issues and see the next status of it, you have the support of the Astar Network community!

1 Like
  1. 5EUpj7L99RyhgiWis74drfTMd8V9hFacSEgsCteoBX2BcJAF
  2. 0xC273ea964b5C975Fdbba9DF9624649F1038aAf9B, verified on Astar address details for 0xC273ea964b5C975Fdbba9DF9624649F1038aAf9B | Blockscout
  3. Added tags on GitHub - lousydropout/keyvault
  4. Filled out form for keyvault from Google account
1 Like

Congratulations to the team. I hope we’ll get to do awesome things together. =)

1 Like

Looking forward to your continued success!

1 Like