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 (49)

๐Ÿ‘€๐Ÿฅถ
bitcoinplebdev's avatar bitcoinplebdev
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
View quoted note →
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.
bitcoinplebdev's avatar bitcoinplebdev
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
View quoted note →
your nsec can be retired to cold storage and only used offline to rotate your signing shares
we have clients planned for desktop, browser, mobile, server and server-less environments all signing nodes communicate over nostr so they can live on any device with an internet connection
LFG
bitcoinplebdev's avatar bitcoinplebdev
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
View quoted note →
Nice little demo of this here that shows it in action. There's even hardware signers out there if you wanna get really nuts about it. nevent1qvzqqqqqqypzpqtjhys9y37al6vm0qejq7pdqvf05vz6rx0m90528ejk8cstfu8zqqs9vnnt0fmr3sqxdsewuz6wfz48vsajdvnaqrg9u8llsn36mmf2x7stx6pww
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 @cmd 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.
Promenade with a management layer (preview from daniele below) seems like problem solved almost entirely. I can't picture what else you'd want? And Frostr great for advanced users to take it further. nevent1qvzqqqqqqypzq77777lz9hvwt86xqrsyf2jn588ewk5aclf8mavr80rhmduy5kq9qqsqqqqv6w6jgsef6cfw8k8djv9yw36pdthjf0qa890vvzysgk964zqqsregp
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
You don't want to send requests to off-line or intermittent peers, so the "send" list let's you to select which peers you expect to handle your requests. The "receive" list is less important to manage, but you may want to be restrict your node's participation with high-risk nodes, in case they get compromised.
โ†‘