Improving Geographical Resilience For Distributed Open Source Teams with FREON

Original post by Soatok

In a recent blog post, I laid out the argument that, if you have securely implemented end-to-end encryption in your software, then the jurisdiction where your ciphertext is stored is almost irrelevant.

Where jurisdiction does come into play, unfortunately, is where your software is developed and whether or not the local government will employ rubber-hose cryptanalysis to backdoor your software.

If you’re a European, you probably already assumed this sort of attack is inevitable in America under the Trump administration.

Unfortunately, this isn’t a new threat.

The U.S.A. P.A.T.R.I.O.T. Act–which Congress keeps re-authorizing despite how much it shits all over the Constitution and human rights–has emboldened government agents to flagrantly disregard the 4th Amendment for years already. The CLOUD Act, passed in 2018, adds further legal backdoors to data privacy.

Well-Tread Paths

There are multiple layers of mitigations that open source teams can adopt to make this sort of attack less attractive for human right violators.

Commonly discussed mitigations include:

• Releasing your software publicly under an free or open source license allows your users to inspect the software, modify it, or fork it entirely if you’re totally compromised.
• Reproducible builds allow you to assert that the software you’re installing matches the version you expect from the open source repository. This introduces a mechanism that makes attacks significantly less stealthy.
• Digital signatures and attestations published to SigStore (or some other binary transparency technology) provide a notion of supply-chain security between the provider of a software package and its users.

  See also: PEP 740.

  In the context of end-to-end encrypted messaging apps, you also have the congruent notion of key transparency for preventing key substitution attacks.

Nothing in the above list is new. If you cannot publish reproducible artifacts to SigStore (or equivalent) today, your developer ecosystem should already be planning or developing this capability.

If they aren’t, kick ’em into gear, maybe?

Humans: The Weak Link

Any software that implements all three layers of protection is doing a remarkable job.

There is, however, one additional mitigation layer we can introduce to dissuade rubber-hose cryptanalysis by rendering it largely ineffective.

Today, software releases are signed with an asymmetric keypair. The signing key can produce signatures (and therefore must be secret), while the verifying key is released publicly to allow anyone to verify signatures.

There are some approaches that implement so-called “multi-sig” approaches, where multiple signatures must be present before a payload is considered valid, but this is not a universal strategy.

Therefore, the publisher of software that controls the signing key is the weak link, even in today’s state of the art security software.

Stay FROSTy

So what if we removed this single point of failure by not having a single signing key?

FROST (RFC 9591) is a technique for implementing Threshold Signatures. One of the FROST ciphersuites is backwards compatible with Ed25519.

Threshold Signatures

Building an intuition for threshold signatures is easy.

Imagine for a moment, instead of having 1 secret key, you have 7 secret keys, of which 4 are required to cooperate in the FROST protocol to produce a signature for a given message. You can replace these numbers with some integer t (instead of 4) out of n (instead of 7).

This signature is valid for a single public key.

If fewer than t participants are dishonest, the entire protocol is secure.

Okay But How?

Welp, that’s where things get tricky, because threshold cryptography is different depending on the algorithm you use.

If you’re trying to generate ECDSA-compatible threshold signatures, good luck. The complexity involved, even with recent advancements, makes it only generally worth it for non-custodial cryptocurrency wallets. This mess is unavoidable because ECDSA requires computing the modular inverse of a secret value.

Schnorr signatures, such as Ed25519, use a different construction that’s more amenable to threshold cryptography.

FROST is a protocol that implements Schnorr signatures in two rounds, once the initial key setup has concluded.

You can think of it as a variation of Shamir’s Secret Sharing that doesn’t require actually reconstructing the secret to actually use it to calculate signatures.

In FROST, the first round commits to the message (and therefore to the nonces), and the second creates the shares of the final signature. The shares are then validated by the Coordinator and aggregated into a final signature.

If you want to understand in more detail, RFC 9591 is the best document to refer to.

Introducing FREON

Today I am releasing FREON (which stands for “FOSS Resists Executive Overreaching Nations”).

Freon is a set of software tools, written in Go, that implement the FROST protocol to generate Ed25519 signatures.

• The Freon client software is used for each participant that holds a share of the secret key. These shares will be encrypted locally by the Freon client, using age.
• The Freon coordinator software is a webserver intended to be deployed in a private network or VPC to facilitate the protocol between asynchronous clients.

The primary intended use case for Freon is to generate OpenSSH-compatible signatures for signing Git releases (instead of PGP), but it also supports bare signature generation for integration in other protocols.

The Freon client is intended to be straightforward:

# Initiating DKG in a 3-of-7 config:
$ freon keygen create -h hostname:port -n 7 -t 3
# Returns a Group ID to pass to other participants

# Joining the DKG 
$ freon keygen join -h hostname:port -g GroupID -r AgePublicKey
# Your local share of the Secret Key will be encrypted using age
# Returns a Signing Public Key once all participants have enrolled

# To begin the Signing Ceremony
$ echo -n "foo" | freon sign create -g GroupID
# Returns a CeremonyID to pass to other participants

# To participate in a Signing Ceremony
$ echo -n "foo" | freon sign join -c CeremonyID

The details of the underlying cryptography are abstracted away from the end user.

Freon is open source on GitHub: soatok/freon.

In the future, I plan on building a more sophisticated Freon coordinator. Some ideas include:

• Passkey-based authentication
• A web interface
• Support for third-party service hooks (i.e., for Git release tagging so signatures can be sourced from a signing ceremony)

Other ideas are welcome, of course.

(The Freon clients should largely remain unchanged, except maybe to authentication workflows.)