relevant xkdc when they bring back pasting
can't wait for arduino ide support and dev boards popping up 🥰
i first read "nutshell" and now i think they've missed an opportunity there 😅
OSM could be a great replacement for GMaps
i did get it to work, but after coming back from hibernation the system would be slow and unstable, so i stopped using it. it's a shame we can't have this on Linux...
anything with portals 😂
i really hope we'll see some more competitive open source risc-v designs in the future
Regarding encryption, I'm gonna write up a security-doc that goes into more detail, but in a nutshell yes, keys are encrypted using your password (see also here in the build instructions). Your password is salted and hashed and turned into a 256bit key. The ESP32 has a hardware AES module on board, and encrypts your crypto keys with AES-256 CFB128 before storing them. The password itself is not stored on the device. Currently you'd need to send the pw via RPC command to unlock the wallet, in the future you'll be able to input it on the device directly (display- and GUI-integrations are planned for 0.2.x).
After setting a pw, you can either add your existing keys, or generate new ones on-device (ESP32 comes with hardware TRNG capabilities). In the latter case, they're returned to you once in the RPC response so you can back them up, in the future you'll be able to show them on the display instead.
I appreciate the curiosity :) Let me answer your first and last question first: A hardware wallet acts as a store for your keys, with the premise that they cannot and will never be extracted from said device. A "software wallet" or app (like Metamask) which runs on a phone/PC might be exposed to vulnerabilities of the underlying operating system or environment. Your PC might be exploited, and someone steals the keys stored in the app you're using to sign, or injects bogus input into the signing process, etc.
In contrast to that, a hardware wallet is only sent the data to sign, returns the signature, and never exposes the keys to anything connected to it. In the case of Colibri, it has a BLE interface and you can pair your PC or phone, then send commands in JSON-RPC format. Sensitive commands (like signing) require approval on the device, by pushing a physical button.
Ideally, this process is integrated into a software wallet, to have a GUI to prepare and send your transactions, and double-check and sign them on the hardware wallet - I'm working on a proof of concept integration via a MyEtherWallet.com fork for this.
So the flow would be something like
- Connect hw wallet to PC/phone
- Set up hw wallet: set a password, add or generate keys
- Connect hw wallet to wallet app
- Unlock the hw wallet with your password
- Prepare transaction data in app, and send it to hw wallet
- Approve request on hw wallet; sign data and return signature to app
- App broadcasts signed transaction to the blockchain
yeah since its still in the pre-release stage, i'm focusing on the firmware and docs for the moment. i've started working on a webapp for device setup too, which will ultimately double as landing- and docs-page, and will become more visual.
here is a picture of various ESP32 dev-boards from my desk, any of these would work:
Just released v0.0.3 of colibri.diy - new features include Ethereum transaction signing and basic Bitcoin support <3
Now working on a companion webapp to ease device setup, and the first 3rd-party wallet integration. Please let me know what you think!
the colibri.diy-project is still under development, please give it a star on Github <3
just released the firmware three days ago, head over to colibri.diy to find build instructions and more info or read the intro post
view more: next ›
weird flex considering you are posting this to the privacy community that is the alternative to [email protected] already imho