Summary of FROST/Gordian Meeting @ April 3, 2024

[shannona]

The April 3, 2024 Gordian Meeting with a special presentation on FROST by Jesse Posner was one of the biggest Gordian Developer Meetings ever, with more than 25 participants. Thanks to Jesse and to everyone who attended!

Gordian Advances

SSH Keys

Blockchain Commons wants to broaden its key retention/protection methodologies to cover more than just cryptoassets, to show they're more broadly accessible. Since we're all developers, Blockchain Commons is looking at SSH keys

Right now Blockchain Commons has proof-of-concept experimental Python code working with SSHs and Gordian Envelope. This new Python code shows how you can sign Envelope with other types of signatures, including SSH, not just the formats within the Envelope CLI!

The Blockchain Commons specifications have always been designed so that they can be used in a number of environments and with a number of different standards. This is an example.

Rust Stack

Blockchain Commons is also working on expanding their Rust Stack into embedded environments

Updated the dCBOR library and will be bringing more of their Rust code base to no_std in the future.

Meanwhile, Rust stack is becoming the Blockchain Commons reference stack, but they still want to support Swift.

Gordian Server

Server 1.1.0 is out. This is the exemplar TorGap server from Blockchain Commons.

Wyoming Legislation

Blockchain Commons does advocacy on legislation.

• Wyoming is where they've done a lot of work.

Private Key Disclosure law protected disclosure of private keys

Registered Digital Asset law allows "perfection" of digital assets

• Wyoming citizens were already protected
• Now anyone can prove they have sovereignty under law over asset

See Blockchain Commons blog post for more.

DAO Laws

• Not just Ethereum!

For the future

• Micro-DAOs
• Data Minimization, Elision

FROST

Welcome to Jesse Posner

• Sr. Blockchain Engineer, Bitkey wallet
• Working on FROST in the Open Source World

What is FROST?

Flexible Round-Optimized Schnorr THreshold Signature (FROST)

• Uses Schnorr instead of ECDSA
• ECDSA had been a work-around to get around a now-expired Schnorr patent
• Schnorr can do things that ECDSA can't
• Allows for distributed key generation & threshold signing, without script, using multi-party computation (MPC)

ECDSA multisig was script-based

Now, instead of using Bitcoin script, with FROST you split a private key into multiple pieces using off-chain protocols

• Then create that key & do signature off-chain!

What Are major Elements of FROST?

• Shamir Secret Sharing
• Verifiable Secret Sharing
  • Commitments that allow you to verify a share is part of a secret, same set as other participants, and that it can be reconstructed & matches a public key
  • Can avoid malicious shares!
• Distributed Key Generation
  • Creates shares without private key ever being constructed!
• Schnorr Signatures
• Signature Aggregation
  • People sign with shares!
  • FROST aggregates those shares
  • Again, never brought together!

Why is FROST Important?

• Advantages over Bitcoin Script
  • Better privacy: just a single key & sig on chain
    • Doesn't matter if it was a multisig!
    • Can foil chain analysis
  • Lower fees: smaller redeem scripts than script-based multisig
  • off-chain resharing
    • Newer research!
    • Piggy-backing on work with Shamir shares research
    • For example, if a share is lost, can initiate REPAIR protocol: a node can reconstruct its share without revealing that!
    • Then, can run REFRESH protocol so all shares change, but don't change underlying private key, so no on-chain transaction!
    • Similarly, ENROLL a new participant or DISENROLL an existing participant, or MODIFY threshold, all without on-chain changes!
  • More theoretical things: Lightning-like setup with keys that are cold/warm instead of hot
• Advantages over Sharmir's Secret Sharing
  • No trusted dealer
    • Eliminates Single Point of Failure
    • Eliminates need for secure process
  • No secret reconstruction
    • Eliminates SPOF/bottleneck on other side
    • Allows smaller groups to manage!

FROST PRs

• Multiple PRs for secp-zkp
  • Original PR
  • A Trusted Dealer PR might go in first!
• BIP for DKG
  • FROST has a great RFC
  • But doesn't define DKG
  • The new BIP does
  • And the BIP is "batteries included", which means that it also defines the requirements for producing FROST (broadcast channel, pairwise secure schannels)
• Frost Signing BIP
• Zcash FROST Taproot PR

New Papers

• Re-Randomized FROST
  • Proves the security of key tweaking
  • Had known we could tweak keys with Taproot, BIP32
  • This proves they're secure!
• Arctic
  • Threat is that reused nonce can lead to private key extraction!
  • ECDSA avoids by creating nonce with hash of message
  • But multi-party protocols like FROST can fall victim to malicious nonce which can lead to attack similar to nonce-reuse problems
  • This has meant multi-party protocols can't use deterministic nonce
  • Arctic is more lightweight and allows them in something similar to FROST
    • Which allows signing in one round!
    • Still requires honest majority!

Proactive Secret Sharing

The cutting edge of FROST research is using methods to change aspects of threshold signing without changing the secret.

REFRESH

• This is how we can change Shamir Shares without changing the private key.
• Allows update without changing secret
• n participants can update shares
  • Can disenroll others, refresh, then reenroll them!
• This is also how disenroll works! You refresh without them!

REPAIR

• Participants send data to participant who lost share
• t participants, not n
• Already implemented in Zcash!
• Can also enroll a new participant!
  • Effectively repair share that had not previously been there!

Dynamic Secret Sharing

• Increase or decrease threshold
• Threshold Increase by Zero Addition
  • Like REFRESH Protocol, Where You Generate 0 Secret
• Threshold Decrease by Public Evaluation
  • Repair a share that doesn't exist
  • Reveal it to all participants
  • And then subtract it!

FROST Questions & Discussions

ROTATION

We have language challenges talking about topics like "rotation". FROST isn't technically rotating because key isn't changing, but we need a new word for this. Maybe, "refresh".

IS THERE A WAY TO COMBINE FROST SHARES TO GET SECRET IF YOU DON'T UNDERSTAND OR TRUST FROST?

Yes! You can pull out VSS as a transitional method, using Trusted Dealer

You could then reconstruct from those VSS shares if you had a VERY trusted network & computer

BIP32 & FROST?

No problem!

You have a public key and you can generate non-hardened public keys from it using a random chain code. That's your master xpub.

BIP85 IS A POPULAR FEATURE RIGHT NOW, NEED TO BE ABLE TO VIEW, LABEL, AND EXPORT KEYS. WITH FROST, WHERE MASTER PRIVATE KEY DOESN'T EXIST. HOW DO WE GENERATE KEYS, BUT NOT BRING TOGETHER ORIGINAL KEY?

Need an MPC-friendly protocol. These are the sort of wallet-level issues that Blockchain Commons is trying to address.

IS ANYONE USING FROST IN PRODUCTION?

Brink & Blockstream have been doing work ...

• Not used yet in development!

FROST-like systems some places like Coinbase

• Schorr-style MPC

[other solutions are threshold ECDSA and MuSig2, which are FROST-like. There are advantages and disadvantages, but they're in some ways hacks, whereas FROST can be better proven by cryptographers!]

ZCASH FROST IMPLEMENTATION DOES NOT INCLUDE X-O PRIVATE KEYS

x-o private keys are a challenge, saved 1 byte for Taproot outputs, 32 bytes instead of 33, but didn't see negative consequences coming, that it makes engineering harder, but still a reasonable optimization

ARE THERE CHALLENGES IN MATH & IMPLEMENTATION?

Math seems solid

• But there are challenges!
• Just creates a private key, not a seed, not a chain code

But if you have multiple devices, you have to a have a threshold of them corrupted to corrupt your key!

Implementation is always a challenge!

IS THERE A WAY TO SIMULATE FROST?

Yes!

Use Trusted Key Generation to simulate DKG

We need to explore these sorts of things

• As transition to a FROST/MPC world

WHAT IS THE STATUS OF ROAST?

For situations with active adversary (denial failure), it's hard to see who "cheater" is.

When ROAST is added to FROST, it throws out dishonest adversaries

Done from the research point of view, but no one is working on an implementation

• But ROAST is ultimately a FROST wrapper, so the FROST implementation will be useful for ROAST as well

HOW CAN WE USE DKG FOR OTHER THINGS?

STORM will prove that DKG is useful (and cryptographically secure!) for things other than FROST

HOW IS FROST DIFFERENT FROM OTHER MPCs?

FROST is a specific, optimized MPC

• Can work on regular hardware

HOW IS ADOPTION OF INTERACTIVE PROTOCOLS IN PRACTICE? THERE'S BEEN A LOT OF ALLERGIC REACTION TO INTERACTION ON BITCOIN. WHAT ARE THE OBSTACLES?

Biggest impediment: we need good implementations

You can remove the interactivity with pre-generated nonces (if you can make that secure)

But often not an issue! The interactivity can be easy, in a single request/response cycle.

WALLET DEVELOPER FEEDBACK ON DEVELOPMENT

Nonce State & Storage has been Biggest Hurdle for Many Wallet Developers

Arctic might be a big step forward!

CRAMIUM LABS FEEDBACK ON DEPLOYMENT

Has been a struggle to get ECDSA and MPC to go fast enough

• FROST is already so much faster!

Next Month

• Dan Gould with PayJoin!