Keyvault - UCG Proposal

Astar Initiatives dApp staking applications
63

I had, but I don’t think that’s gonna be affordable for me anymore (reason below).

(Note: I’m not trying to complain about the UCG amount, the following is to detail the difference between what it currently is and what I had hoped for when I wrote that I would use part of the grant for auditing purposes. I’m hoping it explains why I no longer than I can financially afford it and why I’m thinking of alternatives. And, to clarify, I am still happy I am doing this via UCG since it showed me that there are support for non-mainstream crypto projects. I’m very grateful for that support.)

To begin with, I had no clear idea of how much UCG would provide. Obviously, the higher, the better in my mind. Also, it seems that there was a proposal, that passed, that increased the staked amount for UCG projects from 2M ASTARs to 17M ASTARs, hopefully pushing the project to tier3 where the project would earn ~$100/day (at ~$0.06/ASTAR) as opposed to the ~$10/day in tier4. While that was true for the first couple of days, the tier3 threshold has since become 18,348,623 ASTARs, meaning keyvault, and I assume other UCG projects as well, is now listed under tier4.

Given that smart contract audits supposedly costs between $5,000 to $15,000 and keyvault will receive around $1,000 over the course of 4 months via the UCG grant, I just don’t see getting an audit for keyvault to be possible at this time. It was only even potentially possible at tier3 actually.

So, alternatives. One alternative is for keyvault to offer to host any audits anyone willing to perform pro bono. This would be targeting hopeful auditors. Maybe they would view it as being a fair trade for having a public audit they performed and that they can point future clients to? That said, this feels a bit predatory from my perspective, since it amounts to asking people looking for jobs to perform for free.

The other alternative I’ve been tinkering with in my head is the following. I put $300 (equivalent to ~1 month worth of UCG financial support at the current tier4) worth of ETH into a wallet, store the private key in keyvault, and publicly let people know both the wallet’s public key and the public key of the keyvault account that houses said private key to the $300 worth of ETH. This way, people get to monitor the account and, if the ETH goes missing, they’d know it was broken into and keyvault is unsafe. This is the leading candidate for me right now.

If anyone is comfortable sharing their opinion on the matter or thinks of other alternatives, I’d love to hear from you.

3 Likes
64

Hi @lousydropout , thanks for the details of sharing the current status. Let me dive into and share my thought on the alternative first and get back to the UCG part later.

From the idea you proposed, I can see your passion to Keyvault, and I personally appreciate it. Do you think there could be more than one round of it? One of my concerns is that if you can get the right feedback when the ETH is taken (or the private key in the Keyvault is taken). Would it always be possible to get the feedback or the root cause when the ETH is taken? otherwise, we merely know that there is somewhere having a security issue but we do not know where it could be.

If you are already very confident, then perhaps starting this with higher rewards, saying $1,000 in USD, then reducing it over time gradually if no one breaks in over a certain period of time (like a week).

1 Like
65

Glad to see Keyvault got back on Tier 3 again.
Another one about the UCG program, three things I would like to share.

  1. On top of the 17M staked from the UCG program (Unstoppable Community Grants Program - 2024 - Google Sheets), roughly 30k ASTR is staked on Keyvault, so perhaps more exposure is necessary to get more attention from the community, I assume. Not from one direction, rather it could be done in a multidirectional manner. After having the report, we can emphasize what the Keyvault is about and so on.
  2. You might be interested in reading in regard to the sudden increase of the threshold on each tier. How to Creat previsibility on dApp staking V3 Tier threshold
  3. I am sure you are already aware, the first month report is scheduled in the 30th of August :), consider this message as a kind reminder. Hope sharing the report would bring more exposure on Keyvault!
2 Likes
66

I understand. I had in mind that in polkadot there were some funds to get your projects audited, but I don’t know anything for L2s. Maybe keep in touch here and see what we can do with the finished product. Good way would be to have the community check it aswell.

1 Like
67

@Sequaja I had not considered there possibly being funds for audits. Thanks for pointing that out :+1: I’ll try searching. Although, yeah, I might need to look into both Polkadot and Polygon. Dunno which, if either, considers keyvault eligible.

@pithecus I think you’re right about that, should the ETH be taken, it wouldn’t necessarily lead to us finding out what is wrong with keyvault, just that something is horribly wrong. Maybe half would be in the account associated with the private key and half to be sent after a demo + explanation? (I’m not sure yet.) The reducing the reward over time also makes sense. Definitely, more to think about. Thx!

As for increasing the reward, I’m down with that and that’s hardly gonna a problem with the newly renewed tier3 status.

Also, yes, thanks for the reminder about the report :slight_smile: I might need to push publishing it to the end of August 30th U.S. pacific time (my time zone) – I didn’t make as much progress as I wanted in the past week (more personal life getting in the way) but want to get as much done as possible before this first report.

3 Likes
68

Hi @lousydropout

Glad to see that you are indeed focusing on developing Keyvault professionally!

I am sure you already have tried some, but there seems a few potential alternatives, for example, using Github Copilot or Bugbounty program platforms.

And I came across the following paper, not sure helpful for you, but let me share, WASAI: uncovering vulnerabilities in Wasm smart contracts | Proceedings of the 31st ACM SIGSOFT International Symposium on Software Testing and Analysis

Hope these help you at least a little bit!
Looking forward to the first report!

2 Likes
69

I understand your point of view and I am glad you continue to build!
About the audits, I have done a few in my regular job but never on blockchain. When I have time, I can review your code and see if something is exploitable in the contracts. I am not an expert in cryptography. So my work will not be worth a real audit.

3 Likes
70

[I’m going to submit the report/check-in via multiple posts. Please let me know if you’d like me to expand on anything.]

Initial goals for 1st month

The follow are my initial goals as stated in the UCG proposal for the first month as well as new goals that were added.

  1. add security measures to communication between chrome extension (can only read) and webapp (can submit txs to smart contract)

background: the chrome extension and webapp will at times need to communicate with each other and, while I don’t see how it’d benefit attackers, this task is to help prevent forged messages from being possible.

  1. set up RPC servers, so as to avoid congesting public RPC servers

  2. add autofill capability for destop browser

  3. update chrome extension so that user can choose their own RPC server (in case they want additional assurance of privacy)

  4. create extension for firefox and safari

  5. publish chrome extension on chrome marketplace

  6. (Added) switch from ink! to solidity due to lack of 3rd party verification tools for ink!

  7. (Added) combine the previous 3 repos into a single repo so that (1) it’d be easier to developer and (2) it’ll hopefully be easier for auditors or anyone interested to test for bugs.

  8. (Added) make use of hardhat to allow devs/testers to develop/test locally

Status on the above goals

  1. Done. There was significant simplifications in terms of the achitecture

  2. Sort of done. I signed up for a QuickNode service but haven’t added the link to the repo. Will do that soon.

  3. PoC done. Figured out how to send username+password from Chrome extension to a webpage directly instead of requiring user to copy and paste. I haven’t gotten around to implementing it though.

  4. Neglected to do. This was low on my list of priorities and I simply never got around to it.

  5. I need to research this some more. I initially assumed Firefox & Safari also had side panels, but am not sure anymore. Apparently side panels don’t exist in Firefox’s and Safari’s version of the manifest.json V3 file, but they have a sidebar option instead. I didn’t get around to finding out if side panels and sidebars are equivalent or not.

  6. Did not do. Still planned, but this is another thing that’s low on my list of priorties. From my perspective, the safest option for users is to compile and load the extension themselves instead of relying on the Chrome store.

  7. Done. There are some UX bugs and quirks that I need to get rid of, but I feel comfortable in claiming this is done.

  8. Done.

  9. Half-done. There was a weird bug when I tried to submit a transaction to the local Hardhat network. The local Hardhat network kept rejecting the transactions, saying “unrecognized function selector” or something like that. However, I was able to switch from using the local Hardnet network to using the Astar EVM network and the error went away.

6 Likes
71

Withdraws and transactions

I made 4 transactions.

2 Likes
72

Great job on the progress! It’s impressive to see the architectural simplifications and transitions to Solidity and Hardhat. Your dedication to updating the Chrome extension, exploring RPC server options, and addressing browser compatibility is commendable. Thanks for the transparency and keep up the good work!

1 Like
73

Thanks for the update!

  1. Do you want to run the RPC Servers you use locally or in the cloud?
  2. Would be great to see a video on it, how it works, when you have something to show :slight_smile:
1 Like
74

Ramblings

The following is essentially just my ramblings about changes I made to keyvault’s architectural design and thoughts about how else I’d like to modify keyvault’s architectural design.

Btw, the consolidated GitHub repo is GitHub - lousydropout/keyvault: Password manager built on the Astar network. It has been consolidated from

Dumb issues I encountered and stuff like that

Finite State Machines (part 1)

Chrome extension’s FSM hook: password-manager-extension/src/hooks/useFiniteStateMachine.ts at main · lousydropout/password-manager-extension · GitHub

Webapp’s FSM hook: password-manager/frontend/src/hooks/useFiniteStateMachine.ts at main · lousydropout/password-manager · GitHub

Initially, I had imagined keyvault’s webapp and chrome extension being able to communicate with each other seamlessly. In order to do this, they’d each need to be able to respond both to any and all valid incoming messages from the other side AND messages from within. So, finite state machines sound like the perfect fit, right? Well, it may or may not be, but my implementation certainly was not. In brief, the state machine ended up being overly complicated even though FSMs, I’d imagine, are supposed to help simplify things by providing organization and clarity. Instead, I occasionally opted to bypass the state machine out of laziness, so states started changing without the state machine being aware. Then, there were also a bunch of “autoreplies” from one state machine to the other’s messages, and, before long, 10+ messages have been passed between the two. Those were a nightmare to try and debug.

So, in the new version, I got rid of state machines. Users will now need to click the occasional button or copy and paste their pubkey from Metamask or Subwallet. That’s probably worse UX, but much better for my sanity.

Finite State Machines (part 2) and Chrome Storage

Chrome storage hook: password-manager-extension/src/hooks/useChromeLocalStorage.ts at main · lousydropout/password-manager-extension · GitHub

For context, this useChromeLocalStorage hook is a custom React hook that also reads and stores the state into chrome.storage.local. This turned out to be pretty cool since it both provided persistent storage and acted as a global state manager. So, think something like Zustand or Redux but with the added persistent storage.

The issue ended being that both my finite state machines and this useChromeLocalStorage hook were modifying, occasionally, the same states. So, using both just became a headache.

Finite State Machines (part 3)

So, what was the before and after?

Before: Chrome extension and webapp communicated with each other. Webapp submits transactions to blockchain. Chrome extension reads data from smart contract via AWS Lambda (see next section).

After: Chrome extension sends messages to webapp (thus far, none going the other way). Webapp continues to submit transactions to blockchain. Chrome extension reads data directly from blockchain without AWS Lambda.

Summary:

  1. Webapp no longer sends messages to Chrome extension and, so, no more state machines.
  2. No more webassembly and so no need for AWS Lambda.

@polkadot/api-contract and webassembly

It turned out @polkadot/api-contract makes use of webassembly and Chrome extensions do not like that (I dunno why). So, I packaged the needed node modules into an AWS Lambda Layer package and used AWS Lambda as a proxy API.

Viem, the typescript library used to interact with EVM chains, apparently doesn’t contain any webassembly bits (maybe it’s a Polkadot thing because it uses Rust?). Took me a while to realize this but, once I did, I got rid of AWS Lambda.

A design I wish I thought of earlier

One thing I really want is for users to know there is no middleman that can get in between them and their passwords.

Having a verified smart contract that users can confirm doesn’t contain any malicious code goes a long way in my opinion, especially when the main alternative is a private company who gates access.

However, I recently learned about solidity’s delegatecall, which allows a contract (let’s call it A) execute another contract’s (say, B’s) function in A. The result is that it’s A’s states that changes and not B’s even thought it’s B’s function that was executed.

If I had known earlier, I think I’d want each user to deploy their own contract A that keeps track of their ciphertexts and that delegatecalls functions in B as appropriate instead of B storing everybody’s ciphertext. Then, A might also have an additional field that keeps track of B’s address and a function that can switch from B’s address to that of their own deployed version of B if something happens to B (e.g. some sort of malicious action such as hiking the fee from the current zero to some large number).

Oh, well. maybe for keyvault version 2.

An idiotic mistake

One thing I only realized after submitting a verified contract’s address is that there was a useful function I neglected to include.

So, the keyvault smart contract keeps track of ciphertexts and who those ciphertexts belong to. And, I have a storeEntry function for that.

However, storeEntry accepts a single ciphertext. So, if a user creates/updates/deletes, say, N credentials, that user will need to approve the storeEntry transaction N times. Not great for UX.

I’m obviously gonna deploy a new version with a storeEntries function. I just wish I noticed prior to submitting the address of a verified contract that lacks this function.

4 Likes
75

Hi,

  1. Me wanting to get a dedicated RPC node/server is simply to avoid congesting the public nodes. So, I got one with Quicknode. As for local vs cloud, I was hoping the hardhat local net would suffice for testing, but maybe forge’s anvil or maybe I’ll switch to testing on some Sepolia devnet instead? I dunno.
  2. I will definitely do that. Recently found out about SimpleScreenRecorder. So, videos will be added to the list, but low priority lol.
76

Hi @lousydropout , simply very amazed about all the technical details and your dedication! And glad to see you set own milestones and tackling them on your way! :+1: Fully support your work!

1 Like
77

wonderful job! @lousydropout !
It is great to hear all of the technical updates from you and also shared the technical issues you have! Any plan on the sonieum L2 integration?

1 Like
78

This is the first UCG project to submit such a detailed report.
It is very wonderful!

3 Likes
79

Great report and love the dedication you put in. Definitly a big supporter here!

  1. yeah Local net would suffice I think for your testing.
1 Like
80

Thank you for the detailed report.
It’s great to see that you have thoroughly reviewed the initial goals.

1 Like
81

@DrCAO i’m still pretty ignorant about soneium. need to catch myself up on its benefits first

@Sequaja actually, that’s the thing. for reasons unknown to me, viem is not playing nice with the hardhat local net but works fine on astar’s evm network. has me completely baffled lol. hopefully viem will get along with the astar testnet?

1 Like
82

Hello…

As per me… the project roadmap includes improving security, adding social recovery features, creating extensions for different browsers, and developing mobile apps. With these developments, Keyvault could be a strong competitor to existing password managers by offering a decentralized, censorship-resistant alternative.

Thanks!

1 Like