We inspected DSS 6.4's actual bytecode

Shor's algorithm, proposed in 1994 and still not runnable at the scale required on a real quantum computer, solves in polynomial time two mathematical problems that all of today's deployed public-key cryptography depends on: factoring large integers (the basis of RSA) and the discrete logarithm, including its elliptic-curve variant (the basis of ECDSA and EdDSA).

This isn't a weakness in a specific implementation: it's that the underlying mathematical problem stops being hard, at any key size. An RSA-2048 is no more resistant than an RSA-4096 against Shor. Both fall the same way, which is why this tool marks RSA and ECDSA as vulnerable regardless of key length.

Grover's algorithm, by contrast, only offers a quadratic speed-up against hash functions (SHA-256, SHA-3) and symmetric encryption (AES). A 256-bit hash keeps an effective security level of about 128 bits against a quantum-computer attacker, exactly what's considered adequate against a classical attacker today. That's why this tool doesn't flag SHA-256 as vulnerable, while it does flag RSA-2048 and ECDSA-256.

The concrete qubit count needed isn't static, and it's moving in the direction that matters: the 2019 estimate by Craig Gidney and Martin Ekerå required twenty million noisy physical qubits to factor an RSA-2048 in eight hours. In May 2025, a new result from Gidney himself (Google Quantum AI) cut that to under a million, using approximate residue arithmetic and more efficient surface codes: twenty times fewer resources in six years. No existing processor comes close: Google Willow (December 2024) and the IBM Heron family operate with hundreds of qubits, not millions, and without error correction at the scale Shor requires. IBM's own public roadmap points to a first fault-tolerant system, IBM Quantum Starling, with 200 logical qubits, by 2029; its successor, Blue Jay, at 2,000 logical qubits, by 2033. Neither figure is enough yet to run Shor against RSA-2048. The trend, however, is what has led NIST to set 2030 and 2035 as the deprecation and ban dates for RSA and ECDSA (NIST IR 8547), not a forecast that the computer will exist tomorrow.

In August 2024, NIST standardized ML-DSA (FIPS 204), a signature scheme based on the hardness of certain lattice problems, as the reference replacement for RSA and ECDSA. It's the algorithm this tool's sealing engine uses, in its ML-DSA-65 variant (NIST security category 3, signatures of about 3.3 KB).

There's also SLH-DSA (FIPS 205), based solely on the security of hash functions: much heavier signatures (tens of KB) but with a more conservative security argument, since it doesn't depend on lattices holding up over time as well as hashes themselves have.

No post-quantum algorithm carries the three decades of cryptographic scrutiny RSA has had. That's why this tool's sealing doesn't use ML-DSA alone, but a hybrid (composite) signature: ML-DSA-65 and ECDSA-P256 signing the same data at once, so verification requires both components to be valid. If an unforeseen attack against lattices showed up twenty years from now, the design at least never depended on a single bet.

Preserving a signature isn't simply re-signing it: you can't re-sign on behalf of someone who no longer can (a retired notary, a dissolved company). The standard technique is the evidence record (RFC 4998, or its XML variant RFC 6283): a timestamp over a Merkle tree that covers one document or thousands at once with a single cryptographic operation.

An individual inclusion proof for any single document can later be extracted from that tree, verifiable without needing the rest. That's what this tool's sealing layer generates when you try it: a real evidence record, signed in hybrid classical and post-quantum, not a simulation.