SQIsign
SQIsign is a post-quantum digital signature scheme built on the mathematics of isogenies between supersingular elliptic curves, and it’s the leading candidate from the isogeny family in NIST’s additional-signatures process, where it advanced to the third round in May 2026. Its defining trait is size: SQIsign produces the smallest public keys and signatures of any serious post-quantum signature, on the order of a hundred bytes each, which no lattice or hash scheme comes close to matching. That compactness is bought with slow signing, historically the slowest of the candidates, though recent optimizations have narrowed the gap. It’s not a finished standard, so it belongs in the “track closely” pile rather than the “deploy now” one.
The short version:
- SQIsign is an isogeny-based signature whose security rests on the hardness of finding isogenies between supersingular elliptic curves, a problem Shor’s algorithm doesn’t solve.
- It has the smallest keys and signatures of any post-quantum signature, roughly 65 to 129 bytes for the public key and 148 to 292 bytes for the signature across the three NIST security levels.
- Its tradeoff is slow signing. Signing runs into the hundreds of millions of CPU cycles, far slower than lattice signatures, while verification is fast.
- It advanced to Round 3 of NIST’s additional-signatures effort in May 2026 as one of nine candidates and the only isogeny-based one, so it’s a research candidate, not a FIPS standard.
- It matters because it gives the signature portfolio mathematical diversity on a basis unrelated to lattices, and because its tiny artifacts fit places nothing else does.
Picture mailing a signed contract where the whole signature is a single line of text at the bottom of the page. Every other post-quantum signature makes you staple on extra pages, sometimes dozens of them, to carry the proof. SQIsign fits the proof on that one line.
The catch is what it takes to write that line. Producing an SQIsign signature is slow, computational work that takes a machine noticeably longer than the alternatives. Reading it back, checking that the signature is genuine, is quick. So SQIsign suits the world where you sign something once and it gets verified many times, and where every byte on the wire is precious.
What is SQIsign?
SQIsign is a digital signature scheme in the isogeny-based family, submitted to the NIST additional-signatures process, whose name stands for Short Quaternion and Isogeny Signature. Its job is the standard signature job: a signer produces a value that anyone holding the public key can check came from that signer and wasn’t altered, which is authentication and integrity, not key establishment or confidentiality.
Three facts pin down its identity:
- Canonical name and family. The scheme is SQIsign, and it belongs to the isogeny family, the same broad area as the famously broken SIDH/SIKE key exchange, though SQIsign is a distinct construction with a different security foundation.
- Mathematical basis. Its security rests on the difficulty of finding an isogeny, a structured map, between two supersingular elliptic curves, and on the hardness of related problems in the quaternion algebras that describe those curves.
- Distinguishing property. It produces the smallest keys and signatures of any post-quantum signature candidate, which is the entire reason people care about it despite its slow signing.
Source: SQIsign submission team, project overview, sqisign.org.
How does SQIsign work?
SQIsign signs by proving knowledge of a secret isogeny without revealing it, and it verifies by checking that proof against public curve data. The construction turns a hard isogeny problem into a signature through the Fiat-Shamir paradigm, the same general recipe used to turn an interactive proof into a non-interactive signature. The flow has the same three moves as any signature scheme:
- Key generation. The signer computes a secret isogeny from a fixed public starting curve to a new curve. The new curve becomes the public key, and the secret isogeny (the specific path between the curves) is the private key.
- Signing. To sign a message, the signer uses knowledge of the secret path to construct a fresh isogeny that answers a challenge derived from the message, then compresses that isogeny into a compact signature. Finding these paths is the expensive step, which is why signing is slow.
- Verification. Anyone with the public key follows the signature’s compressed path and checks that it correctly connects the challenge, which confirms the signer knew the secret path without ever learning it. Verification is fast.
Source: sqisign.org, scheme overview.
A quantum computer doesn’t help an attacker here in the way it helps against classical public-key cryptography. Shor’s algorithm breaks RSA and elliptic-curve schemes by solving factoring and discrete logarithms, and the supersingular-isogeny problem SQIsign rests on isn’t one of those. The best known quantum attacks on the isogeny problem offer only modest, sub-exponential improvement, and the parameter sizes are chosen to absorb them. That quantum resistance is why the scheme is in the post-quantum toolbox at all.
Why are SQIsign’s keys and signatures so small?
The artifacts are small because an isogeny between two curves can be described very compactly once the right compression is applied, and the security comes from the difficulty of finding that isogeny rather than from the size of the object itself. This is the opposite of the situation in lattice and hash signatures, where the security margin is tied directly to how much data the scheme carries. A lattice signature has to ship vectors sized for its security level, and a hash-based signature like SLH-DSA has to ship a large bundle of hash values, so both run into the kilobytes or tens of kilobytes. SQIsign’s proof is a short description of a path between curves, and that stays tiny.
The exact figures show how dramatic the gap is. Across the three NIST security levels, SQIsign’s public key runs from about 65 to 129 bytes and its signature from about 148 to 292 bytes.
| NIST level | Public key (bytes) | Signature (bytes) |
|---|---|---|
| I | 65 | 148 |
| III | 97 | 224 |
| V | 129 | 292 |
Source: SQIsign submission team, specification figures, sqisign.org.
For contrast, the smallest finalized lattice signature, FN-DSA (Falcon), has a signature of about 666 bytes at level I, and the general-purpose ML-DSA runs to roughly 2,420 bytes, so SQIsign is several times smaller than the most compact lattice option and more than an order of magnitude smaller than the default. On the signature-plus-public-key total that a certificate has to carry, nothing standardized comes close.
Why is SQIsign so slow to sign?
Signing is slow because producing the signature means computing a fresh isogeny, and the algorithms for constructing and compressing those isogenies are computationally heavy compared with the arithmetic in a lattice signature. On an optimized Intel Raptor Lake implementation, SQIsign signing at NIST level I takes around 101 million cycles, and higher levels cost more, into the hundreds of millions of cycles. A lattice signature like ML-DSA signs in a small fraction of that, so on raw signing throughput SQIsign is genuinely at a disadvantage.
Verification tells the opposite story. At level I, verifying an SQIsign signature takes roughly 5 million cycles, which is fast and comparable to other schemes. That asymmetry, slow to sign and quick to verify, shapes exactly where SQIsign fits: settings where an artifact is signed once, or infrequently, and then verified many times, and where the compactness of the artifact outweighs the cost of producing it. The signing speed has improved substantially in recent versions, so the gap is narrower than it was, but the profile still favors sign-rarely, verify-often, size-critical uses.
Source: SQIsign submission team, performance figures, sqisign.org.
What is SQIsign’s standardization status?
SQIsign is a Round 3 candidate in NIST’s additional digital signature schemes process, and it isn’t a finished standard. NIST ran a separate call, opened in 2022, to add post-quantum signatures beyond the finalized ML-DSA, SLH-DSA, and FN-DSA, with a stated preference for designs built on math other than structured lattices. SQIsign is the only isogeny-based scheme still in that process, and it advanced to the third round along with eight others when NIST published its second-round status report, NIST IR 8610, on May 14, 2026.
Source: NIST IR 8610, Status Report on the Second Round of the Additional Digital Signature Schemes for the NIST Post-Quantum Cryptography Standardization Process, May 14, 2026, csrc.nist.gov.
The correct positioning follows from that status:
- Not a FIPS, not a deployment default. SQIsign has no finalized standard, no CMVP validation path yet, and no long production track record. It’s a candidate under active cryptanalysis.
- A mathematical-diversity play. Its value in the portfolio is that its security basis is unrelated to lattices, so a future advance against lattice cryptography wouldn’t touch it. That’s the same instinct behind keeping HQC as a code-based backup to ML-KEM.
- A timeline measured in years. A third round in 2026 means any resulting standard is still well out, so the sensible posture is to deploy the finalized standards and build for crypto-agility so a scheme like SQIsign can be adopted later as a configuration change.
Source: NIST, “Round 3 Additional Signatures,” project page, csrc.nist.gov.
How does SQIsign compare to the standardized signatures?
The cleanest way to place SQIsign is against the three finalized-or-drafted signatures it would eventually sit beside. All four do the same signing job; they differ on math family, status, size, and speed.
| Property | SQIsign | ML-DSA | SLH-DSA | FN-DSA |
|---|---|---|---|---|
| Math family | Isogeny-based | Lattice (Module-LWE) | Hash-based | Lattice (NTRU) |
| NIST status | Round 3 candidate | Final (FIPS 204) | Final (FIPS 205) | Draft |
| Public key | ~65 to 129 bytes | ~1.3 KB and up | ~32 to 64 bytes | ~897 bytes and up |
| Signature | ~148 to 292 bytes | ~2.4 KB and up | ~7.9 KB and up | ~666 bytes and up |
| Signing speed | Slow | Fast | Slow | Moderate |
| Best fit | Size-critical, sign-rarely niches | General-purpose default | Conservative, long-lived roots of trust | Compact lattice option |
Source: NIST IR 8610 (SQIsign status), csrc.nist.gov; sqisign.org (SQIsign sizes); NIST FIPS 204/205/206 for the standardized figures.
The practical reading: ML-DSA is what almost every program deploys, because it’s the balanced, finalized default. SQIsign is the specialist you’d reach for only where the combined size of the signature and public key is the hard binding constraint, verification happens far more often than signing, and a non-lattice basis is worth waiting for a standard to settle.
Common misconceptions
- “SQIsign is a NIST standard you can deploy.” It isn’t. It’s a Round 3 candidate in the additional-signatures process, with no finalized FIPS and no validation path yet.
- “Isogeny cryptography broke in 2022, so SQIsign is broken.” The 2022 break hit SIDH/SIKE, an isogeny key-exchange scheme with a specific structure that SQIsign doesn’t share. SQIsign is a distinct construction that survived into Round 3, though it’s still under active cryptanalysis like every candidate.
- “Small artifacts mean it’s the best choice.” Its keys and signatures are the smallest in the field, but its signing is the slowest, so it’s a specialist for size-critical, sign-rarely uses, rather than a general default.
- “SQIsign fixes harvest-now-decrypt-later.” It doesn’t touch it. Harvest-now-decrypt-later is a key-establishment risk solved by ML-KEM. Signatures only fail once a quantum computer exists, which is why the signature track moves more slowly.
- “Fast verification means it’s fast overall.” Verification is quick, but signing is the slowest of the candidates, so the overall speed profile depends entirely on how often you sign versus verify.
Questions people ask
Is SQIsign a NIST standard? No. It’s a third-round candidate in NIST’s additional digital signature schemes process, advanced in May 2026, with no finalized standard yet. The finalized post-quantum signatures are ML-DSA and SLH-DSA, with FN-DSA in draft.
What makes SQIsign special? Size. It produces the smallest public keys and signatures of any post-quantum signature, roughly a hundred bytes each, which is several times smaller than the most compact lattice option and vastly smaller than the hash-based one.
Why is SQIsign so slow? Signing requires computing a fresh isogeny, which is computationally heavy, so signing runs into the hundreds of millions of CPU cycles. Verification, by contrast, is fast, which is why SQIsign suits sign-rarely, verify-often uses.
Is SQIsign related to the isogeny scheme that broke? It’s in the same broad isogeny family as the broken SIDH/SIKE key exchange but is a separate construction with a different security foundation. That earlier break is one reason the isogeny family draws extra scrutiny, and it’s part of why SQIsign is still being studied rather than standardized.
Is SQIsign quantum-safe? Its security rests on the hardness of finding isogenies between supersingular elliptic curves, a problem Shor’s algorithm doesn’t solve, and the best known quantum attacks offer only modest improvement that the parameters absorb.
When would anyone use SQIsign? Where the combined size of the signature and public key is the binding constraint, verification vastly outnumbers signing, and a signature basis independent of lattices is worth the wait. Certificate and identity contexts with tight size budgets are the natural fit.
Should my organization deploy SQIsign now? No. For any signing today, use the finalized standards, ML-DSA by default. SQIsign is a research candidate to track, adopted later through crypto-agility if it becomes a standard.
SQIsign is the scheme you reach for when the whole proof has to fit on one line and you’ll read it far more often than you write it. Everything here is the map, given freely. When your team needs to decide whether an isogeny-based signature belongs anywhere on your roadmap, that’s what an alignment briefing is for.
Last verified 2026-07-12 · Maintained by Addie LaMarr, LaMarr Labs.