Important News:SafeLogic Announces CryptoComply v3.5 with OpenSSL 3.5 Compatiblity, PQC and Improved Performance! Read the announcement.
Comparing PQC and Classical Algorithms
June 13, 2025 •Aryeh Archer
More and more companies are starting to incorporate post-quantum cryptography (PQC) in their products and infrastructure. These algorithms provide much needed security against future attacks by a cryptographically relevant quantum computer (CRQC). However, new implementers often have questions about the differences in key sizes, as well as use of the new KEM algorithm type.
Background – NIST Security Categories
While classical algorithms have security strengths that correspond to specific bit lengths, PQC algorithms have security strengths corresponding to NIST security categories. These security categories are intended to compare the difficulty of breaking an algorithm with a given parameter set to the difficulty of breaking a comparable classical algorithm. See additional details here.
NIST security categories can be summarized as follows:
- Security Category 1: comparable to AES-128
- Security Category 2: comparable to SHA-256
- Security Category 3: comparable to AES-192
- Security Category 4: comparable to SHA-384
- Security Category 5: comparable to AES-256
Background – KASs and KEMs
With the publication of the NIST standard for ML-KEM, NIST introduced the concept of Key Encapsulation Mechanisms (KEMs) for key establishment. KEMs differ from Key Agreement Schemes (KASs), as briefly outlined below.
- KASs are classical key agreement schemes, such as Diffie-Hellman. Parties use public and private keys to establish a shared secret. A key derivation function (KDF) must be used on the shared secret to create a shared secret key.
- KEMs are key encapsulation mechanisms introduced with the PQC algorithms. Unlike KASs, KEMs are not symmetric for both parties and cannot be used to encapsulate the same key for multiple parties (e.g. for key distribution). KEMs also do not incorporate any digital signature algorithms. In a KEM, Alice sends an encapsulation (public) key to Bob, Bob generates a random key and sends it to Alice as ciphertext using her encapsulation key, and Alice uses her decapsulation (private) key on the ciphertext to obtain the random key. For more details on KEMs, see the initial public draft of SP 800-227 - Recommendations for Key-Encapsulation Mechanisms.
Comparing PQC and Classical Parameters for Digital Signatures
In general, PQC algorithms for digital signatures have much larger parameters than corresponding classical algorithms, as detailed below:
Comparing PQC and Classical Parameters for Key Establishment
As with digital signatures, PQC algorithms for key establishment (KEMs) have much larger parameters than classical algorithms (KASs), as detailed below:
Using PQC algorithms
Although PQC algorithms have larger parameters and introduce a new key establishment methodology, using them is well worth the effort. Classical asymmetric algorithms will not be able to provide security against the growing threat of quantum computers. And while large parameter sizes may require implementation adjustments, PQC algorithms can often be as fast or faster than classical algorithms.
To get started today with SafeLogic’s PQC products, reach out to our sales team here. Or learn more from our recent blog post here.

Aryeh Archer
Aryeh is Safelogic's Director, Operations and Compliance.
Popular Posts
Search for posts
Tags
- FIPS 140 (114)
- FIPS validation (85)
- Encryption (69)
- cryptography (67)
- NIST (62)
- CryptoComply (60)
- SafeLogic (57)
- Industry News (52)
- cryptographic module (51)
- CMVP (48)
- Conversations (47)
- RapidCert (46)
- compliance (40)
- Ray Potter (33)
- SafeLogic News (32)
- Event (26)
- federal (26)
- CAVP (24)
- Cybersecurity (23)
- FIPS 140-3 (22)
- post-quantum cryptography (17)
- PQC (16)
- OpenSSL (15)
- FedRAMP (14)
- government (14)
- CryptoCompact (12)
- Cryptology (12)
- DoD (12)
- healthcare (12)
- partners (11)
- RSA (10)
- Cloud (9)
- NSA (9)
- CMMC (8)
- Suite B (8)
- security (8)
- whitepaper (8)
- testing (7)
- Approved Products List (APL) (6)
- HITECH (6)
- ICMC (6)
- NIST 800-53 (6)
- CEO (5)
- Entropy Source Validation (5)
- NIST 800-171 (5)
- OpenSSL 3.0 (5)
- iOS (5)
- lab (5)
- procurement (5)
- C3PAO (4)
- Common Criteria (4)
- HITECH Act (4)
- OpenSSL 3.x (4)
- TLS 1.3 (4)
- entropy (4)
- innovation (4)
- procure (4)
- Air Force (3)
- DFARS (3)
- HIPAA Safe Harbor (3)
- HITECH Safe Harbor (3)
- OpenSSL 1.1.1 (3)
- POA&M (3)
- deadline (3)
- encrypt (3)
- magazine (3)
- public sector (3)
- queue (3)
- ACVP (2)
- BAA (2)
- BSAFE (2)
- CIO (2)
- CSP (2)
- Defense Industrial Base (2)
- FISMA (2)
- HIPAA security controls (2)
- Historical Status (2)
- MFA (2)
- OpenSSL 1.0.2 (2)
- SPRS (2)
- StateRAMP (2)
- excellence (2)
- founder (2)
- gold (2)
- leader (2)
- maturity (2)
- pilot (2)
- rsa conference (2)
- solution (2)
- transition (2)
- year (2)
- 3PAO (1)
- Active Status (1)
- Alliance for Digital Innovation (1)
- Android (1)
- CIO Prime Views (1)
- Cyber Defense Magazine (1)
- DHS (1)
- DIU (1)
- DIUx (1)
- DOJ (1)
- DoDIN APL (1)
- FCA (1)
- FIPS Compliance (1)
- GSA (1)
- HITRUST (1)
- Matt Cornelius (1)
- Matthew Cornelius (1)
- Maturity Model (1)
- NCCoE (1)
- OMB (1)
- OpenSSL 3.5 (1)
- SLED (1)
- SP800-131A (1)
- SP800-90A (1)
- TLS 1.1 (1)
- background (1)
- best (1)
- co-founder (1)
- congress (1)
- cybertech (1)
- education (1)
- elliptic curve cryptography (1)
- faq (1)
- finance (1)
- fintech (1)
- fiscal (1)
- fiscal year (1)
- fraud (1)
- globee (1)
- hill (1)
- interview (1)
- kratos (1)
- libgcrypt (1)
- national cybersecurity strategy (1)
- opportunities (1)
- overlap (1)
- parallel (1)
- profile (1)
- representatives (1)
- reseller (1)
- senate (1)
- senators (1)
- simplify (1)
- sponsors (1)
- stealth mode (1)
- story (1)
- sunset (1)
- vendor (1)