1 comments

  • sasasavic a day ago ago

    For anyone interested in the underlying mechanics — here’s a quick breakdown of how the system works under the hood:

    Architecture Overview All timestamping happens client-side first: users hash their files locally using SHA-256. Only the hash is sent to our API — no file contents ever leave the client.

    The API then:

    Creates a dual signature — one using ECDSA P-256 (current classical cryptography standard) and one using ML-DSA-65, the NIST FIPS 204–approved post-quantum algorithm (Dilithium-family).

    Anchors both signatures into a Bitcoin transaction via OpenTimestamps, ensuring long-term public verifiability independent of our servers.

    Publishes a daily JSON ledger of all timestamped hashes and their dual-signature proofs.

    Verification Users can verify proofs in three ways:

    On-site via the verification tool https://sasasavic.ca/verify/

    Manually using OpenTimestamps and our public JSON

    Or by validating the ECDSA and ML-DSA signatures independently

    Why this matters Most timestamping systems are still vulnerable to future quantum attacks because they rely solely on ECDSA or RSA. By layering PQC (post-quantum cryptography) today, the proofs remain valid and independently verifiable even if quantum computing breaks classical cryptography later.

    This API is free to use during beta, with full documentation here: https://sasasavic.ca/beta-api/

    Would love feedback on:

    -Implementation of ML-DSA vs Dilithium variants

    -Any edge cases in JSON proof verification

    -Suggestions for improving developer tooling or SDK design

    Looking forward to seeing how developers use the API or integrate quantum-resistant timestamping into their workflows.