Question: Where is the FROSTR polynomial saved? Only on the signer that has the seed? That signer must be online all the time, right? Meaning, can the FROSTR's main account nsec be airgapped?

Yes, you can run igloo offline and just use it as an airgapped key manager

also, the full polynomial only exists in memory for the short time you are creating the shares. it is up to you to save those shares elsewhere, either encrypted to disk, or copy/paste.

If Igloo is offline, who is checking if a pubkey is in the most up-to-date polynomial?

to be clear, there is no protocol interaction between the nodes to rotate keys or update the polynomial. you simply use your nsec to generate a new set of shares, then swap out the shares manually this keeps share rotation simple, and reduces the attack surface available to a compromised share I do have an example of performing an interactive rotation in the main frost library, that is designed for a group of adversaries:

GitHub

frost/test/example/refresh.ts at master · cmdruid/frost

Flexible, round-optimized threshold signature library for BIP340 taproot. - cmdruid/frost

That's fine. What I am trying to understand is the role of the online signing component that need to check which keys are signing and the role of the master key that can rotate key shares. Does the online component have a list of authorized pubkeys or does it just check if the incoming signature comes from any key that is inside the polynomial? Meaning, can I rotate single device keys while keeping all the others in place, without changing the key set of the online service? Or do I need to update the online signer with a new public key that is authorized? Ideally those two things would be separate. I load a polynomial on the signing service and then the air-gapped share creation/rotation service can generate new keys for new devices without having to update any of the old ones and the main signer.

yes, that is possible. you could create multiple sets of shares for your nsec, and run them concurrently. generating a new set doesn't invalidate the old set (you have to dispose of shares properly). the bifrost node will only cooperate with peers who have a pubkey in the same group as them in the future, igloo will be able to run multiple shares/nodes, which means you can participate in multiple signing groups, even for the same nsec I don't have a clear use-case for doing this, other than more graceful rotation between sets (phase out the old set after the new set is in place).

If I want to airgap my nsec, how would I set this up? Is Igloo the piece that stays offline? If so, How do I transfer a newly generated share set from the offline application to the main signer that knows the pubkeys of all shares? What I am trying to do is this: - no online device has my nsec. - I use an offline computer to generate 3 shares in 2 of 3. - 1 share goes into Amethyst. - 1 share goes into Olas. - 1 share goes into Amber. All of them are in the phone. Amethyst and Olas both need to communicate with Amber to sign. No single app has the full nsec. Questions: - Do I need to pick a coordinator among the 3 signers? - What do I need to transfer from the offline nsec holder application to each of the app? Just the nsec? or the nsec + the group of other keys authorized to sign on my behalf?

- Do I need to pick a coordinator among the 3 signers? No, the node requesting the signature is the coordinator. - What do I need to transfer from the offline nsec holder application to each of the app? there are two encoded strings that you copy/paste: the group string and the share string. You do not need to transfer the nsec. You can run igloo offline and air-gapped as a key manager, and another copy of igloo as a desktop signing node. We have plans for a mobile app that will run as a remote signer using NIP-46. TBD.

@bitcoinplebdev how should we go about tracking interoperability of FROST implementations over nostr - what are the criteria etc

GitHub

FROST support [NIP-07 NIP-47] Positive Interoperability Tracker · Issue #172 · nostrability/nostrability

app key creation encryption decryption comment nstart ✅ ✅ ? creates nsec, ncryptsec, optionally uses bunker and stores keys in multiple locatio...

Frostr does not require any nostr protocol changes, it can integrate with NIP-07 and NIP-46. What we need to do is finish our reference signing clients (so other signers can understand and implement it themselves) and then after that create a spec for Bifrost the underlying library that powers the implementation into a signing client (if someone wants to reimplement to create their own library) But none of this changes or requires anything new of the nostr specs

How are you going to encrypt and decrypt messages, mute lists, drafts, application data, etc? A big chunk of Nostr requires encryption.

Doesn’t NIP-07 and NIP-46 support encryption?

They do, but the underlying key must be able to encrypt/decrypt. And I think FROST keys cannot do that.

Why do you think that?

Because sharing the keys works for signing, but not encryption/decryption. FROST doesn't do 2 of 5 decryptions.

It is not well known, but you can perform a collaborative ECDH with the key shares. I have an example in the @cmdcode/frost library.

Very interesting. Can you do an example with NIP-44? I'd love to get NIP-17 DMs working with FROSTR if possible.

That's interesting. How would you combine that with a symmetric cipher?

frost2x has NIP-44 integrated. Bifrost nodes construct the shared secret, then pass it into NIP-44 methods (from nostr-tools) for encryption and decryption. NIP-17 should be doable on top of that.

The threshold of signers in the keyset can encrypt / decrypt

Very cool, then why is @fiatjaf freaking out that nip44 doesn't work with frost?

Once you construct the shared secret, you can plug that into any cipher scheme like normal. Frost2x already handles nip04 and nip44 encryption.

honestly I didn't know of an ECDH solution until fairly recently. I stole it from Jesse Posner, full credit to him:

GitHub

jesseposner - Overview

jesseposner has 36 repositories available. Follow their code on GitHub.

Wow, I didn't know this. Good to learn about this arcane knowledge here. It is still kinda bad in the multisig bunker case because the coordinator can decrypt your messages, but better than nothing? I'll try to implement it.

Nice, that's very elegant, great find. Some time back we used Pallier threshold encryption to basically do Frost for encryption (this was for an online contest use case). That worked in terms of not exposing the encryption key to any single party (keep it cold like Forst) but then we needed a separate Pallier keypair and as far as I remember it could only handle chunks of 100 words or so, depending on the length of the key and byte limit that unlocks, so required stitching up longer texts (or jacking up the key length to get more bytes). I guess that's just a mathematical limit in context of threshold encryption without exposing the full key to any one party. But not keeping the full encryption key cold here doesn't seem like a dealbreaker to me, and the whole thing is really neat and tidy all bundled in to FROST. You guys are taking some seriously big whacks at this problem. 👍