PAdES-B-T signatures · post-quantum ready

Signatures that hold up. Documents that stay private.

Sigil signs PDFs with a key that never leaves its PKCS#11 token, encrypts every file before it is stored, and seals a receipt of who received and signed what, to the second.

Create account Sign in

Registration is by invitation.

  • PAdES-B-T
  • RFC 3161 timestamps
  • PKCS#11 key custody
  • ECDSA P-384
  • ML-DSA-65
  • AES-256-GCM

How it works

The life of a signed document

Follow one file from upload to receipt: what happens at every step, and what is recorded. Nothing is stored in the clear, and nothing happens without a trace.

  1. Step 01 · 09:14:02 UTC

    Uploaded and encrypted
    document.uploaded

    The PDF is encrypted the moment it arrives. Storage never sees a readable byte.

    • A fresh 256-bit key for this version, AES-256-GCM
    • A keyed SHA-384 fingerprint pins exactly these bytes
    • Only ciphertext is written to object storage

  2. Step 02 · 09:14:02 UTC

    The key is locked away
    Envelope encryption

    The file key is never stored as it is. It is wrapped inside your own key, and yours inside the root key.

    • File key wrapped under your personal key (KEK)
    • Your key wrapped by a root key held in a PKCS#11 token
    • The database only ever holds wrapped keys

  3. Step 03 · 09:20:45 UTC

    Signers are asked, in order
    signing_request.created

    You choose who signs and in which order. Access is handed out one turn at a time, never up front.

    • Every signer is checked for a verified account and a valid certificate
    • Only the first signer is granted the key, by re-wrapping it rather than copying the file
    • Everyone after them cannot open the document yet

  4. Step 04 · 11:02:17 UTC

    Signed inside the token
    document.signed

    The signer reads the document, enters their PIN, and the signature is made inside their own token.

    • The PIN opens the token for this one signature, then is discarded
    • The private key signs the hash and never leaves the token
    • An RFC 3161 authority timestamps it; the result is a new version with its own key

  5. Step 05 · 11:02:18 UTC

    The turn passes on
    signing_request.turn_advanced

    Only now can the next signer decrypt the document, and only the version that was just signed.

    • The next signer is granted the new version
    • Anyone may decline instead, with or without a reason
    • A missed deadline closes the request on its own

  6. Step 06 · 15:47:09 UTC

    A sealed receipt
    receipt.sealed

    When the request closes, Sigil seals a receipt of who received the document, who signed it and when.

    • Sealed with Sigil's own electronic seal, as a PAdES PDF
    • Every participant gets a copy they can check a file against
    • Every step above sits in a hash-chained audit log

Root key · PKCS#11 token

Your key (KEK)

File key (DEK) · one per version

Your document

AES-256-GCM · 7c1e04b9a2…

Encryption

Three keys deep, so no single leak opens a file

Sigil uses envelope encryption. The database only ever holds keys that are themselves encrypted, and the key at the top never sits in the database at all.

  • A key for every version

    Each upload and each signed version gets its own 256-bit key. Old versions are kept, each sealed separately, so the record is never overwritten.

  • Access is a re-wrap, not a copy

    When someone is asked to sign, their key wraps the file key. The stored file is never decrypted or duplicated to hand it over.

  • Quantum-resistant at rest

    Storage is purely symmetric AES-256. Signatures can already use ML-DSA-65, the post-quantum NIST standard.

Signing

A signature that stands on its own

Signed files open in Adobe Reader or any PAdES validator. No Sigil account is needed to check them.

Keys stay in the token

Your signing key is generated inside a PKCS#11 token and is never exported: not to disk, not to the application, not to us.

Your PIN is never kept

It opens the token for one signature and is discarded. Only a salted hash remains, to count wrong guesses.

Independent timestamps

An RFC 3161 time-stamping authority countersigns every signature, so the moment it was made can be proven later.

Key custody

Signing keys kept the way an HSM keeps them

Every private key lives in a PKCS#11 cryptographic token, the industry standard interface of hardware security modules. Keys are created inside their token and stay there for life. The application never holds a key; it can only ask the token to sign.

  • Born inside, never exported

    Each key is generated in its token and flagged sensitive and non-extractable, so the token itself refuses to hand it out.

  • One token per person

    Your signing key sits in a token of its own and is opened only with your PIN, for one signature at a time.

  • Guarded against guessing

    Five wrong PINs within an hour lock signing. Your PIN is never stored, only a peppered Argon2id hash of it.

  • Separated by duty

    The root key, the certificate authority and the receipt seal each have their own token, so no key can ever stand in for another.

Key vault · PKCS#11

All keys sealed

  • Your signing key

    ECDSA P-384 or ML-DSA-65 · opened by your PIN

  • Root key

    AES-256 · wraps every personal encryption key

  • Certificate authority

    Issues and revokes signing certificates

  • Receipt seal

    Seals every delivery receipt

Ready to sign something that holds up?

Upload a PDF, sign it yourself, ask others to sign in order, or serve it on someone with a sealed receipt.

Create account Sign in