Thread

TURN YOUR NSEC INTO A ROTATABLE MULTISIG WITH FROSTR This is a demo of our first two signing clients Frost2x & Igloo converting an nsec into a Frostr keyset and signing a note in nostrudel FROSTR IS STILL UNDER DEVELOPMENT, ALL CODE IS OPEN SOURCE, PLEASE POKE HOLES IN IT AND BE ADVERSARIAL

Replies (33)

This is super cool. Do you have any ideas around where users might store their keys? I think for a good UX, it would be cool to label the keys I.E.: 1. This is your client key, 2. This is your igloo key, 3. This is your recovery key. But honestly, this feels like nsec bunker but where the bunker can't sign for you by itself which I guess is where you are going with this.
Il problema delle chiavi private di Nostr La sicurezza delle chiavi private di Nostr è cruciale. Se una chiave privata viene compromessa, un utente perde il controllo della propria identità e dei propri dati. Tuttavia, gestire e proteggere una singola chiave privata può essere rischioso. Frostr: Una soluzione per la sicurezza delle chiavi di Nostr Frostr risolve questo problema introducendo un sistema di firma remota e rotazione delle chiavi "t-di-n" per Nostr, basato sul protocollo FROST (Flexible Round-Optimized Schnorr Threshold signatures). Ecco i punti chiave: t-di-n Multisig: "t-di-n" significa che sono necessarie "t" firme su "n" partecipanti per autorizzare una transazione o un'azione. Ad esempio, in un sistema 2-di-3, sono necessarie le firme di 2 su 3 partecipanti. Questo distribuisce il controllo delle chiavi private tra più partecipanti, riducendo il rischio di un singolo punto di fallimento. Firma Remota: Frostr consente la firma remota, il che significa che i partecipanti non devono avere le chiavi private memorizzate sullo stesso dispositivo. Questo migliora la sicurezza, poiché le chiavi possono essere conservate in luoghi sicuri e separati. Rotazione delle Chiavi: Frostr facilita la rotazione delle chiavi, il che significa che le chiavi private possono essere cambiate periodicamente. Questo riduce ulteriormente il rischio di compromissione delle chiavi, poiché le chiavi compromesse possono essere rapidamente sostituite. FROST: Il protocollo FROST fornisce un modo efficiente e sicuro per implementare la firma di soglia. È ottimizzato per prestazioni e sicurezza. Nsec: Nsec è il formato con cui le chiavi private sono salvate in Nostr. Frostr permette di utilizzare queste chiavi Nsec, e di dividerle e gestirle tramite multisig. In parole semplici: Immagina di avere una cassaforte (la tua identità Nostr). Invece di avere una sola chiave, Frostr ti permette di avere più chiavi (distribuite tra più persone o dispositivi). Per aprire la cassaforte, è necessario un certo numero di queste chiavi. Inoltre, puoi cambiare queste chiavi periodicamente per una maggiore sicurezza. Vantaggi di Frostr: Maggiore sicurezza delle chiavi private di Nostr. Riduzione del rischio di perdita o furto di chiavi. Migliore controllo e gestione delle chiavi. Resilienza contro la compromissione delle chiavi. In sintesi, Frostr offre una soluzione robusta e sicura per la gestione delle chiavi private di Nostr, rendendo il protocollo più sicuro e accessibile per un'ampia gamma di utenti. image View quoted note →
🛡️
Can you compare/contrast this with fiatjaf's promenade project? Can frostr be reconfigured to support third-party shard custody? It would be great to solve key management and rotation without users having to learn how to do it (at least to start). Short of collusion between providers, I would imagine custodial shards would be pretty safe.
I haven’t looked into promenade so not sure on that. if I’m understanding your question correctly with Frostr you can configure basic permissions on a given share within signing client (send / receive / both) meaning it has permission to either send a request to another share for sig, only receive requests, or both. This effectively allows you to have a “third-party“ share (receive only) that you could give out to different clients/services for signing @npub1gg5u...ulq3 I get this right?
🛡️
I don't understand the receive/send distinction and why it's important. Is it just that you want certain shards to be passive and unable to initiate requests because they're in an untrusted context? This seems like it could be a nice complement to the usual pattern of nagging the user about every permission request. On promenade, I highly encourage you to check it out: https://git.fiatjaf.com/promenade It's currently used by https://start.njump.me to encourage new users to get started with a multisig bunker, without having to set up any signer software on their end. This seems pretty close to the ideal of abstracting away keys for new users without compromising security too much. If we get key rotation, simplier coordination, and/or encryption using frostr, that's an improvement over promenade. But third-party shard custodians have to be plugged into the nostr social layer via NIP 89 so that we can avoid collusion of dishonest signers.
yes you can have a keyshare held by a custodian, and have that custodian participate in signing it's the same model as 2/3 with bitkey, casa or unchained, or any other multi-sig-as-a-service solution we are developing a server-less API gateway that people can run themselves, or a professional custodian can run on behalf of their customers that being said, you are better off running your own server, and handing out revocable tokens. remember that 2/3 with custodians is a compromise to help on-board normies away from single-sig setups, and should not be a desirable long-term solution nostr literally fixes the need for inviting custodians into your quorum. just run a gateway node on a laptop under the bed, don't give up *any* of your keys to a custodian. this goes for all multi-sig setups period. I'm running permafrost + frost2x, and soon(tm) heimdall for permissioned API access to my key