UbQbit is a quantum-safe cryptographic solutions provider. We provide advisory services (quantum risk briefings, cryptographic inventory, PQC migration roadmaps) and Qausal, our quantum-safe document signing platform.
Qausal is UbQbit's quantum-safe document signing platform. The name is a portmanteau of "quantum" and "causal" — causality is the chain of events that proves something happened, which is exactly what a signature does. It establishes who signed what and when, creating an unbreakable causal chain.
Every digital signature in use today (RSA, ECDSA, EdDSA) will be breakable by quantum computers. NIST estimates this could happen within 10–15 years. Documents signed with classical cryptography today could be forged in the future — undermining contracts, voiding deeds, and exposing organisations to liability. If a document needs to be trusted in 2035, it must be signed with quantum-safe cryptography today.
Adversaries are already collecting signed documents today with the intent to forge or repudiate them once quantum computers are available. This is known as a harvest-now-decrypt-later (HNDL) attack. Documents signed with classical cryptography have no retroactive protection — you can't upgrade a signature after it's been created. Qausal protects against this from the moment of signing.
Qausal uses ML-DSA-65 (Module-Lattice-Based Digital Signature Algorithm), standardised by NIST under FIPS 204 (finalised August 2024). It provides Security Level 3 — equivalent security margin to AES-192. Public keys are 1,952 bytes, signatures are 3,309 bytes.
FIPS 204 is the U.S. federal standard published by NIST that defines ML-DSA, the first post-quantum digital signature algorithm approved for government and commercial use. It replaces the draft standard previously known as CRYSTALS-Dilithium.
Hybrid mode applies two signatures to every document: one quantum-safe (ML-DSA-65) and one classical (ECDSA P-256). This provides backward compatibility with systems that don't yet support post-quantum algorithms, while ensuring quantum-safe protection is already in place. When the industry catches up, you're already there.
Your private signing key is encrypted at rest with AES-256-GCM and is never stored in plaintext. It lives in a separate key-management service and is never returned by any page, export, download or log — there is no way for you, an administrator, or us to read it out. We can rotate the encryption protecting your keys without reissuing them, so your existing signatures stay valid.
Qausal uses incremental CMS/PKCS#7 signing via pyHanko (subfilter /adbe.pkcs7.detached, the classic Adobe-compatible signature format). Each signature is written into the PDF's CMS SignedData container, preserving all previous signatures. This isn't yet a PAdES profile specifically — that upgrade is planned alongside external timestamp authority support, so we don't list it as compliant until it is.
Yes. ML-DSA-65 (NIST Level 3) is the default; Levels 2 and 5 are fully supported. We set the level for your whole organisation rather than per signature, so if your standards or procurement require a different one, just ask. Changing it never affects documents you have already signed.
ML-DSA-65 uses the NIST-assigned OID 2.16.840.1.101.3.4.3.18. This identifier is embedded in every signature and proof bundle, allowing any standards-compliant verifier to identify the algorithm used.
Qausal is built on three layers: (1) Signing Engine — the cryptographic core using ML-DSA-65 via liboqs (Open Quantum Safe), with hybrid ECDSA support. (2) Document Lifecycle — upload, sign, verify, archive workflows with multi-party signing, audit trails, and role-based access. (3) Archival Vault (roadmap) — quantum-safe encrypted storage with automatic re-signing as algorithms evolve.
Our hosted cloud platform is the standard option and the fastest way to start. For enterprise customers we can arrange other setups — including keeping key storage separate — these are scoped case by case rather than picked from a list. If your procurement needs something specific, ask us. Dedicated HSM key storage is also on the roadmap
There is a REST API — it powers the Qausal web app. Today's API keys are read-only for organisation details, and cannot upload or sign. If you want to build signing into your own product, talk to us — it is early access by arrangement and a roadmap priority.
Every signed PDF is a self-contained cryptographic proof. The signature, signer identity, algorithm metadata, and verification hash are all embedded directly in the PDF file. The document doesn't reference Qausal's servers, doesn't phone home, and doesn't expire. You can verify it 20 years from now with open-source tools.
Every signed document has a visible stamp on the last page showing: the signer's name, algorithm used (ML-DSA-65), NIST security level, key fingerprint, verification hash, and timestamp. This provides a human-readable summary alongside the cryptographic proof.
A downloadable JSON file containing everything needed for independent verification: algorithm name and OID, document hash (SHA-256), the signer's full public key, the full signature bytes, key fingerprint, NIST security level, and classical signature (if hybrid mode was used).
Yes. A signed PDF + proof bundle can be verified using only Python and liboqs (open-source, 5 lines of code) or any ML-DSA-65 implementation. No vendor account, no API key, no subscription, no internet connection required. Qausal's public verification service exists as a convenience, not a dependency.
Your signed documents remain fully valid and verifiable. The PDF carries its own cryptographic proof, and the proof bundle contains all raw data needed for verification using open-source tools. There is no vendor lock-in.
Open: anyone with the link or the signed file can check the document is genuine, no account needed. Restricted: only you and the people you invited can see the full details. You can switch between them at any time. If someone outside that group uploads the exact file, they get a simple valid or not-valid answer and nothing else — no names, no filenames, no history.
Three ways: (1) By verification hash — paste the hash or URL from the proof stamp. (2) By document ID — paste the ID shown on the document. (3) By PDF upload — upload the signed PDF file and the system matches it by hash. All three methods work for public documents without requiring an account.
Quantum Seal protects a document that was already signed somewhere else, without altering it. Your original file is left exactly as it is, and we issue a separate certificate proving that this exact document existed in this exact form at the time you sealed it. A seal is a statement about a file, not a signature on it — it adds nothing to, and replaces nothing in, whatever signatures the document already has. Seals have no signers.
Yes. Someone you invite can sign without an account: they get a link by email, then a one-time code sent to that same address. No registration, no password, nothing to install. Their signature is marked "(guest, email-verified)" on the document so anyone checking it later can see how they were verified. Either way — account or guest — we confirm control of an email address and nothing more. We do not check identity documents.
Yes. You can require every signer to state the capacity they are signing in — for example "CFO, Acme Pty Ltd" — before their signature is accepted. It appears on the signature, on the document stamp, and in the audit trail. Note that it is what the signer typed: we record it, we do not verify it against a company register.
Upload one or more PDF documents and sign them all immediately with your quantum-safe key. Each document gets its own individual signature. Ideal for routine document processing — contracts, invoices, compliance filings. Only verifiers (not additional signers) can be added later.
Upload one document and invite multiple people to co-sign it. Each signer signs with their own quantum-safe key. The document owner signs first, then co-signers receive email invitations with a link to review and sign. The document tracks progress and shows status per signer.
The signer is marked as "declined" with their optional reason. The document owner is notified by email. The document remains signable by other assigned signers — a single decline does not cancel the document.
Yes, the document owner can cancel an in-progress document with an optional reason. All signer participants are notified by email. Cancelled documents cannot receive further signatures. Fully signed documents cannot be cancelled.
Yes. Adding a new signer to a fully signed multi-signer document changes its status back to "In Progress" until the new signer completes their signature.
No. Documents created via Single Sign mode only accept verifiers, not additional signers. If you need multiple signers, use the Multi Signer workflow instead.
A visual timeline showing every step in a document's lifecycle: upload, signers assigned, each signer's action (signed, declined, or pending), and the final result (fully signed, in progress, or cancelled). Available on the Documents page by clicking "Journey" on any document.
If you invited signers, only you and the people you invited can sign. If you did not, only you can. Having the link is never enough on its own. And once someone declines, they cannot sign that document afterwards — a decline is final, and stays on the record.
Three roles per document: Owner (the person who uploaded it — can manage participants, toggle verification mode, cancel), Signer (can sign or decline), and Verifier (can view and verify the document but not sign it).
An immutable, INSERT-only log of every action taken on a document: uploads, signatures, verifications, declines, cancellations, and participant changes. Each entry includes a timestamp, IP address, and client context (timezone, platform, language). Audit records cannot be modified or deleted.
You sign in with an email and password, and your session is held in a secure cookie your browser will not expose to scripts. Sessions expire automatically by default, and changing your password immediately signs out every other session. When you register we also create your quantum-safe signing key automatically — there is nothing to set up.
Three, all optional. Two-factor authentication with an authenticator app, which an owner can require for everyone. Single sign-on with Entra ID, Okta or Google Workspace, which can be set as the only way in. And IP allowlisting, to restrict access to your own networks. Owners keep a way in regardless, so a misconfiguration cannot lock your organisation out.
No. Your signing key is independent of your password. Changing your password does not invalidate existing signatures or issue you a new key.
ML-DSA-65: public key 1,952 bytes, secret key 4,032 bytes, signature 3,309 bytes. ECDSA P-256 (hybrid): standard 32-byte keys and 64-byte signatures.
SHA-256 for document hashing, key fingerprints, and file integrity verification.
10 MB per PDF file, enforced on both document upload and verification upload endpoints.
No. Notification emails are handed to a small fixed-size worker pool, so sending never blocks an API response and a slow or unresponsive mail server cannot stall the platform. If SMTP is not configured at all, email sending is skipped silently rather than raising an error.
No. Removing a document removes the file itself — the signed PDF. It does not remove the proof: the signature, what was signed, who signed it, and the full audit trail all remain. The evidence reamins.
Yes, from a copy you hold. Verification never depended on our storage in the first place — a signed PDF plus its proof bundle verifies offline with open-source tools, which is exactly why removing our copy cannot invalidate yours. This is the same property that means your documents survive us going offline entirely.
Two things happen automatically. You can download the signed copy from the platform. And if a document is ever scheduled for removal, we email you in advance. You can also ask us to keep a document longer if you need more time.
Free trials for individuals and teams, pay-as-you-go Starter plans, flat-rate Professional plans for solo practitioners and small teams, and custom Enterprise and API arrangements. See the Pricing page for current plans, limits and prices.
Whoever sends the document pays. If you invite someone to sign, their signature comes out of your plan — being asked to sign never costs the signer anything and never needs an account of their own. The other side of that: if you run out of capacity, your signers cannot sign until you top up.
Both let you start signing straight away with no card. The individual trial is a single seat; the team trial adds seats for colleagues and a higher monthly allowance. You get whichever matches the account type you pick at signup.
You can wait for the limit to reset next month, or upgrade. Either way you keep full access to everything you have already signed.
Starter has no monthly fee — you buy a prepaid pack of signature credits and each signature you complete spends one credit. There's no expiry and no use-it-or-lose-it: buy another pack whenever you're running low.
Payment is handled entirely by Stripe's hosted checkout and billing portal — your card details are never seen by, or stored on, Qausal's own servers. Plan changes, payment method updates, invoices, and cancellation are all managed there too.
Nothing you've already signed is ever at risk. Every document you've signed stays fully independently verifiable regardless of your subscription status — only starting new uploads or signatures requires an active plan. If a free trial period ends without upgrading, your account rolls over onto Starter's (or, for an organisation account, Starter Team's) pay-as-you-go rate rather than being locked out.
Part of the roadmap. If this is your use case, talk to us; it is what moves it up the queue.