A working reference for security and crypto engineers

Post-quantum cryptography: the sizes are the surprise

The move off RSA and elliptic curve is underway because a large quantum computer would break both. NIST finalised the replacements in 2024: ML-KEM (FIPS 203) for key establishment, ML-DSA (FIPS 204) and SLH-DSA (FIPS 205) for signatures. The algorithms work, but the first thing engineers hit is that the keys and signatures are much larger than what they replace. An RSA-2048 signature is 256 bytes; the comparable ML-DSA-44 signature is 2,420 bytes, roughly nine to ten times larger. An ML-KEM-768 public key is 1,184 bytes against 32 bytes for X25519. SLH-DSA trades size for the most conservative security assumptions, with signatures from about 7,856 bytes up to nearly 30,000.

That size jump is what actually complicates a migration. A TLS handshake now carries kilobytes where it used to carry tens of bytes, certificate chains grow, and some embedded and networking protocols have hard limits that the new material bumps into. For most web traffic the overhead is manageable; the pain concentrates in constrained links and in formats with fixed fields. The size comparator puts every parameter set side by side so you can see the exact byte cost before you commit to an algorithm, and the migration lookup maps a use case to the required algorithm and deadline under NSA CNSA 2.0 or general NIST guidance.

Timelines matter as much as sizes. NIST SP 800-131A is moving classical algorithms toward deprecation, and NSA CNSA 2.0 sets firm dates for National Security Systems, with quantum-resistant algorithms mandated for use by the end of 2031. A lot of the guidance circulating online quotes dates from superseded revisions; the deprecation timeline is built from the current drafts and flags where the common numbers are stale.

CVE triage: severity is not urgency

Every vulnerability program drowns in CVEs, and the usual mistake is to sort by CVSS and patch from the top. CVSS measures how bad a vulnerability would be if exploited. It says nothing about whether anyone is actually exploiting it. Two other signals answer that question. EPSS, published daily by FIRST, estimates the probability that a CVE will be exploited in the wild within the next thirty days. CISA KEV is an evidence-based list of CVEs confirmed to be under active exploitation. A vulnerability can carry a CVSS of 9.8 and an EPSS near zero, meaning it is severe in theory but nobody is attacking it; another can be moderate on CVSS yet sit on the KEV list, which makes it an emergency.

Sensible triage reads all three together: anything on KEV is top priority regardless of its other scores, high EPSS raises urgency, and CVSS sets the ceiling on how bad a successful exploit would be. The CVE triage tool pulls all three live from NVD, FIRST and CISA for any CVE ID and returns a single plain-language verdict, so you are not stitching three tabs together by hand.

Password storage: the hash decides everything

Whether a password is safe depends less on the password than on how the service stores it. After a breach, an attacker has the stored hashes and guesses against them at the full speed of their hardware. Against a fast hash such as MD5, SHA-1 or Windows NTLM, a modern GPU tries tens of billions of candidates per second, and even a complex password falls quickly. Against a deliberately slow hash such as bcrypt, scrypt or Argon2, the same GPU manages only a few thousand per second, and the same password holds for years. The password did not change; the storage did.

That is why OWASP recommends Argon2id first, then scrypt, then bcrypt, then PBKDF2, each with specific parameters tuned so a single verification takes a fraction of a second while mass guessing stays expensive. The hashing parameter recommender lists the current OWASP values and measures your own hardware to size a PBKDF2 iteration count, and the crack-time estimator shows how the same password fares across online and offline attacks so the orders-of-magnitude gap is concrete.

How this reference is maintained

The numbers here come from primary sources, not from other blogs: the FIPS standards for post-quantum sizes, NVD, FIRST and CISA for vulnerability data, and the OWASP Password Storage Cheat Sheet for hashing parameters. Where sources disagree or a standard is in draft, the tools say so rather than picking a number and hiding the uncertainty. The tools run entirely in the browser; nothing you type into them is sent anywhere or stored. They are free, supported by advertising, and each tool site has its own privacy policy describing how advertising cookies work and how to opt out.