Using Nostr now is similar to using a crypto hot wallet. You need to enter your private key onto your device to gain full access via a client. When will “cold” accounts be possible? Meaning, having the ability to store your private key offline and using a device similar to a ledger to access a Nostr client.
#nostr #privacy
there are signer apps for browsers, keepass, etc
Do they currently work with nsec? I use a Yubikey already but don’t know if I can use it to access Nostr Clients.
Yes, all those can store your nsec so you don't have to paste it in your browser.
I dunno about Yubikey. I would never trust a hardware device for anything. Can fail anytime
I am able to store my nsec anywhere. The problem I see is that I need to add my nsec to a client to access it. It’s like adding your 12 word seed phrase to a device. It’s connected to the internet so its not 100% safe. Using a cold wallet in crypto allows you to sign transactions without the need to add your seed to an online device.
Adding my nsec to an online device makes it possible for someone to get to it. Very low probability but still a probability. That’s why cold wallets for crypto were made. To keep the seed offline permanently.
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.)
