Thanks for taking the time to look over the site.
Yes, that's exactly the residual trust. We can make the firmware verifiable, we can't make the silicon verifiable from your chair. We'd rather say t...
For Bitcoin, I'd be nervous to keep keys that hold larger amounts on a device with WIFI capabilities. On the other hand, for keys holding smaller amounts for everyday use, this seems very appropriate and convenient, including the choice between QR and local network.
For Nostr, I'd again be nervous about holding my identity-securing key on a device with WIFI. But for my everyday signing key, a device that can do NIP-46 remote signing over WIFI seems ideal. As we had already discussed, this is complementary to the separation between identity key and signing key that I've implemented with Inkan.
Part of the reason I'm curious about all of this is that airgapped signing of certain transactions is part of the core idea of Inkan. The transactions that need to be signed in an airgapped environment are delegations and revocations of signing authority between key pairs, and these then need to be recorded on Ethereum.
I made the "Inkan Management Utility" (https://www.inkan.cc/settings/inkan-management-utility) to perform this airgapped signing. It's a working prototype / proof of concept at this point, certainly not an audited product. It's meant to be run on an airgapped Linux system (as I mentioned I use a de-networked version of Tails), but I'm sort of curious whether these types of key delegation transactions could ultimately also be signed on a bespoke signing device of the kind you're making.
For Nostr, I'd again be nervous about holding my identity-securing key on a device with WIFI. But for my everyday signing key, a device that can do NIP-46 remote signing over WIFI seems ideal. As we had already discussed, this is complementary to the separation between identity key and signing key that I've implemented with Inkan.
Part of the reason I'm curious about all of this is that airgapped signing of certain transactions is part of the core idea of Inkan. The transactions that need to be signed in an airgapped environment are delegations and revocations of signing authority between key pairs, and these then need to be recorded on Ethereum.
I made the "Inkan Management Utility" (https://www.inkan.cc/settings/inkan-management-utility) to perform this airgapped signing. It's a working prototype / proof of concept at this point, certainly not an audited product. It's meant to be run on an airgapped Linux system (as I mentioned I use a de-networked version of Tails), but I'm sort of curious whether these types of key delegation transactions could ultimately also be signed on a bespoke signing device of the kind you're making.
2
