I discussed an option with someone before. He never did follow up. I guess not interested.
There is something with some limitations, that can work. It's fairly freeform. Either work with a secret embedded on the device, which you cannot choose, or work with a secret that's stored on the client such that the device is needed to work with the private key, e.g. on-device signing.
If someone gains access to your nsec then you will lose your profile. Something needs to be done. It’s still early for Nostr, I hope something is done about it eventually. Hardware wallets for crypto took many years to be developed.
No, sry, I think you misunderstood. I can (with reasonable likelihood) have hardware-backed mechanism (prototype) in a couple of weeks, maybe one if dependency libraries work out and I allow myself to be very optimistic.
It's a small general-purpose security device, more of a prototype. Not with extreme hardware security (yet), but the necessary computations would be (protected and) executed in hardware. Also depends on design and expectations, given that device would need to be present for signing. I can think of variations in which device protects nsec at rest, then unlocking secret to load in client-app memory. We can prly support multiple varations for different purposes (simultaneously).
The problem is that support would need to be present in the clients to be useful, and it would require a considerable amount of time to also modify the clients. I am quite limited on time/resources so, with no support from any devs, I don't want to further divide my focus. I proposed this idea before, but got no response.
Surprised you got no response. I hope someone with the right abilities helps you.
Maybe I could/should whip up a design with the variations in a code-repo. Establish the idea and see if I can get some support. It would probably take (almost) as long as writing the prototype, but at least there can be a conversation then.
nostr:nprofile1qqsfc56gtpy4rray98x2s996zrh2jkvmma8ps0vzqtznhd9hr9p860qpzemhxue69uhhyetvv9ujuenpd4ehgu3w0puh5qgmwaehxw309aex2mrp0yhxummnw3e8qmr9vfejucm0d5hsz9rhwden5te0wfjkccte9ejxzmt4wvhxjmc5jn23j do you have a technical background? Software development?
No.
I asked in case you'd be interested in more in-depth info. 👍
I got the basics set up. Not a functioning client yet. Will probably only be a minimal client to prove that everything works as expected. Device program-binary should do what's necessary but not fully tested yet. Then see where we go from there.
Interested to see how it works out for you.
😂😂😂 just testing with sending a 10 MiB message to the device for signing. With this device, probably in part because it's a fairly new idea/experiment, transfer is rather slow. It took 28 minutes. 😋
Of course, small messages of few KiB are fast. (seconds)
This #nostr note is posted from a small test application and signed with a key that is internal to the #security device.
Ironically, I have no access to this key, which is deterministically generated within the device, so with the next changes to the firmware-binary I'm going to lose access to this key, .. at least when I use the updated program-binary.
There are multiple modes of operation. nostr:nevent1qqs99ehnglvqm7zjp4jt0g2x803s3sl0cxc5ejlrgps0jxqrlx4d0yspz4mhxue69uhhyetvv9ujuerpd46hxtnfduhsygz2plnksne0pxs73kj6a4q03a044z4ncpunun8eg4ryjl233jpwsvpsgqqqqqqs4lrtxf
You have a device already?
You can buy a general purpose "security device", currently a sort of early experiment, IIUC. (See https://tillitis.se/ ) It can load small programs. I'm writing such a program.
I'm not claiming this device is perfect, but it allows for many solutions like this one. (I'm not associated with them. Just playing around with the device.)
