“My heart has joined the Thousand, for my friend stopped running today.” –K’has, quoting Richard Adams, Watership Down
It is with heavy heart that we must report the passing of Tugrik d’Itichi, aka Tug, real name Tori (or Tor) Amundson, a much-respected figure from the early years of the fandom.
[Editor’s note: Much of this was gathered from things said at the memorial service held on FurryMUCK, from social media, from people who responded to my inquiries, and with the help of the wizards on FM. Thank you all for sharing your memories.]
And last but not least: Whether you’re team halo or team horns, Ludo “LudoDoodle” has art to steal your soul, in the best way!
With over a decade of furry fandom magic and credits on DreamWorks, Disney, and Hazbin Hotel, we’re beyond excited to welcome them as our Guest of Honor for #TFS2025!
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.
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.
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.
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.
The basic idea of threshold signatures.
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.
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.
: 
Convention Map: 
![The XKCD Security comic.
[Cueball is holding a laptop up in two hands, showing it to his Cueball-like friend who is examining it while holding a hand up to his head. Above the top of the panels frame, there is a box with a caption:]
A Crypto nerd's imagination:
Cueball: His laptop's encrypted. Let's build a million-dollar cluster to crack it.
Friend: No good! It's 4096-bit RSA!
Cueball: Blast! Our evil plan is foiled!
[Cueball is holding a closed laptop down in one hand while giving his Cueball-like friend a wrench with the other. The friend reaches out for it. Above the top of the panels frame, there is a box with a caption:]
What would actually happen:
Cueball: His laptop's encrypted. Drug him and hit him with this $5 wrench until he tells us the password.
Friend : Got it.
(Transcript from ExplainXKCD)](https://i0.wp.com/soatok.blog/wp-content/uploads/2025/08/xkcd-538-dark.png?resize=448%2C274&ssl=1)
