Signature schemes
FALCON explained mathematically
How a McGesund review is signed with FN-DSA (FALCON) — and why a single changed character breaks the signature.
Last updated: 2026-09-07
1. What this is about
A review on McGesund is not a text field in a database that you have to take on trust. It is signed digitally when it is submitted, and every visitor can recompute that signature later in their own browser.
For some of these signatures we use FALCON — more precisely FN-DSA-512 and FN-DSA-1024. This article explains what happens mathematically.
One thing up front:
FALCON is not encryption. The review text is meant to be read. FALCON does not prove secrecy, it proves origin and integrity.
2. What exactly gets signed
What is signed is not the running text but a compact data object that pins the text down unambiguously:
{
"v": 1,
"typ": "rev-comment",
"f": "<company ID>",
"c": "<review ID>",
"h": "<SHA-256 of the review text>",
"rh": "<SHA-256 of the entire submission record>",
"rv": 1,
"qh": "<SHA-256 of the QR envelope, QR reviews only>",
"iat": 1757203200
}
This is our message . It ties together:
- which company the review belongs to (
f), - which review is meant (
c), - what text was behind it — as a hash value (
h), - what record was submitted as a whole (
rh): text, hearts, geo status and occasion details, canonically serialised and hashed, in schema versionrv, - which QR code the review came from (
qh) — for a review without a QR the field is omitted, - when it was signed (
iat).
A single changed character in the review text breaks this chain. That is exactly the purpose — and since rh the same holds for a heart moved afterwards or an altered geo status.
3. The underlying problem
A reader arriving at a company profile faces two questions:
- Does this review really come from the McGesund system?
- Was it altered afterwards?
That is what the key pair is for:
- a private key — stays inside the signing service
- a public key — anyone may have it
Signing uses the private key, verifying the public one. And it happens on the reader's device, not on our server.
4. Why FALCON?
Many of today's signature schemes rest on problems that are hard for classical computers but could become considerably easier for sufficiently large quantum computers.
For a review that matters more than for a fleeting message: a review should still be verifiable in five or ten years. Whoever signs today signs for the entire lifetime of the entry.
FALCON therefore rests on lattice cryptography:
You build a lattice that is easy to describe mathematically and in which one particular search task is extremely hard.
5. What is a mathematical lattice?
Two vectors:
All integer combinations
form a lattice of points. For example:
The decisive part:
The lattice itself is easy to describe. Finding certain properties inside it is very hard.
6. The secret is short vectors
The classic hard task reads:
That is the shortest vector problem. In two dimensions you can simply try everything. FALCON works in dimension 512 or 1024 — there it is hopeless.
FALCON, however, does not need the shortest vector as such but something related: finding a lattice point close to a given target point. That, too, is hard without the right additional information.
7. Polynomials instead of numbers
FALCON uses an NTRU lattice and computes with polynomials. So instead of single numbers, with lists of coefficients:
The arithmetic happens in the ring
That means:
- : arithmetic modulo . With , for instance, , since .
- : keeps the polynomials at a fixed length.
FALCON specifically uses:
8. The central trick
The private key consists of four small polynomials
satisfying the NTRU equation
Together these four form a secret, well-behaved lattice basis — a description of the lattice made of short vectors.
The public key is essentially a single polynomial:
From you get the same lattice, but in an unwieldy basis of long vectors:
That is the whole core of FALCON. Both bases describe the same lattice. It is just that one of them is usable for computing and the other is not.
You can picture it like a street map: public is the complete map. Secret is the knowledge of the shortcuts.
9. The review becomes a point
Before signing, the payload object goes through a hash function. FALCON uses hash-to-point for this: the message does not become a numeric value but directly a point in the ring.
In addition, the signing service draws a random salt (320 bits) and hashes it along:
The salt is not decoration. Without it the same review would always produce the same signature, and from many signatures the secret basis could be reconstructed. It therefore travels along inside the signature.
10. What a valid signature is
What is sought is a pair
with two properties:
The first condition alone is trivial to satisfy — set and . The second condition is what makes the task hard.
11. A fully worked miniature example
We shrink everything to toy size: polynomials with only one coefficient, so ordinary numbers, and
The secret key. Two small numbers:
The public key. We have , since . So:
The lattice. .
The public basis follows directly from :
Both lie in — and both are long.
The secret basis is known only to the signing service:
since and . The determinant is
so the NTRU equation works out. Both vectors are short.
Step 1: Hash the review
Suppose the review's payload object yields
Step 2: A first, poor solution
satisfies . But its length is — far too long.
Step 3: Shortening with the secret basis
The signing service expresses the target point in its short basis:
This leads to and . Rounded to , , we get the lattice point
Check: , so it really is in . Subtracting:
Length:
That is the signature.
Step 4: The same procedure with the public basis
Anyone who knows only has the basis . The same rounding computation gives the lattice point there and therefore
Also a valid solution of the equation — but seven times longer. If the acceptance bound is set below 26, it is worthless.
That is FALCON's trapdoor in one line.
Step 5: The browser verifies
The browser receives the review, the salt and . It recomputes the hash, obtains , reconstructs
and checks the length:
Step 6: Someone changes the review text
If the text is altered afterwards, the content hash changes and with it the point, say
The old signature stays , but
We can delete a review. We cannot alter it without it showing.
An honest note about the example
In two dimensions an attacker can simply try out short solutions — for , for instance, . The example is not secure; it only shows the mechanism. With FALCON-1024 the vector has 2048 coefficients, and there trying things out leads nowhere.
12. Why not simply round?
The procedure from step 3 is called Babai rounding. For a textbook example it is enough — for a real signature scheme it is not.
The reason: rounded signatures are not evenly distributed. Their shape depends on the geometry of the secret basis. From enough signatures that geometry could be reconstructed — and with it the private key. Earlier lattice-based signature schemes failed on exactly this.
FALCON therefore draws its short vectors from a discrete Gaussian distribution over the lattice:
Values near the target point are more likely, but which one is chosen exactly is random. The result is a distribution that reveals nothing about the basis used — mathematically: it is indistinguishable from a distribution that depends only on the lattice itself.
This sampler is the most demanding part of FALCON. It runs recursively over a tree structure and works with floating-point numbers — which makes the implementation delicate and is the main reason why FALCON is harder to implement correctly than ML-DSA.
13. What is actually transmitted
The signature consists of
Only — not the pair. The verifier computes itself:
Because the coefficients of are small and scatter around zero, they compress very well. That is the reason for FALCON's strikingly compact signatures:
| public key | signature | |
|---|---|---|
| FALCON-512 | 897 B | ~666 B |
| FALCON-1024 | 1,793 B | ~1,280 B |
For comparison: ML-DSA-87 needs 4,627 bytes. At McGesund, however, none of these signatures sits in the QR code itself — the sticker carries only the Ed25519 envelope; the PQ stamps are attached to the record and are loaded when verifying. So size does not decide printability here but storage and transfer: a FALCON stamp is a good quarter of the size of an ML-DSA stamp.
14. Why FALCON verifies quickly
Naive polynomial multiplication costs
With the fast Fourier transform this drops to roughly
At that is the difference between a million and about ten thousand operations. That is why verification runs in a visitor's browser in milliseconds — and why the F is in the name:
FAst Fourier Lattice-based COmpact signatures over NTRU.
15. The process in one picture
16. Why an attacker fails
They know and therefore the entire lattice. They also know the target point as soon as the review is public. What they lack is the short basis.
To forge a review they would have to find a short vector for a of their own choosing — from the public description alone. That is the task step 4 of the example illustrated: without the good vectors the very same computation ends up at a far too long solution.
In dimension 1024 the best known methods — classical and quantum-based alike — are nowhere near it.
17. What McGesund does with it in practice
The envelope. Every signed review carries an Ed25519 signature. That is the mandatory variant — classical, very small, natively verifiable in every browser.
The post-quantum stamps. Alongside it sit one or two quantum-resistant signatures. Which ones depends on the plan:
| Plan | available signature levels |
|---|---|
| Basis | Ed25519, FN-DSA-512 |
| Klassik | Ed25519, FN-DSA-512, FN-DSA-1024 |
| Pro | Ed25519, FN-DSA-1024, ML-DSA-87 |
| Premium | Ed25519, FN-DSA-1024, ML-DSA-87, both in parallel |
The parallel variant is deliberately redundant. FALCON rests on NTRU lattices, ML-DSA on module lattices. Should one of the two families turn out weaker than assumed today, the other carries on.
The time anchor. The fingerprint of the signing key is anchored in a Bitcoin block via OpenTimestamps. That establishes not only that the signature is genuine but also that it already existed at a particular point in time — without anyone having to believe our timestamp.
All of this is computed in the reader's browser, via a WASM module. We supply the data; the check runs on the visitor's device. If we went offline tomorrow, a review once loaded would remain verifiable.
On the names: FALCON is currently being standardised as FN-DSA; the draft is intended as FIPS 206 but is not finished yet. That is why the levels are called FN-DSA-512 and FN-DSA-1024 in the McGesund code, even though people continue to say FALCON in conversation.
18. The most important intuition
The public key is the complete description of a maze. Anyone may look at it.
The signature is the proof: "For exactly this review I found a very short path."
The private key is the knowledge of the shortcuts.
The reader does not need to know the shortcuts. They only measure whether the path presented really is short and really belongs to this review. Both can be done without us.
Change the text and you move the point — and the old path leads nowhere.