# ETSI GS QSC 001: Quantum-Safe Cryptography Use Cases **Source**: https://quantumsequrity.com/blog/etsi-gs-qsc-001 **Category**: Standards & Documents --- [← Back to Blog](../../blog.html) Standards & Documents # ETSI GS QSC 001: Quantum-Safe Cryptography Use Cases 11 min read Designing a quantum-safe migration plan for an entire organization is one thing. Designing it for a specific use case, like protecting a 5G subscriber identity, signing firmware updates for a power grid sensor, or encrypting medical imaging data for archival, is another. Each use case has its own constraints: latency budgets, memory limits, key lifetime, regulatory requirements. Generic guidance does not always fit. To bridge generic guidance and specific deployments, ETSI's Industry Specification Group on Quantum-Safe Cryptography (ISG QSC) publishes use case documents. The foundational one is ETSI GS QSC 001: "Quantum-Safe algorithmic framework." It catalogs use cases, maps them to algorithm requirements, and provides recommendations for matching the right algorithm family to each scenario. This post walks through what GS QSC 001 contains, the use case categories it covers, and how the recommendations apply to current PQC algorithms (now that NIST has finalized FIPS 203 and 204). For organizations trying to figure out which PQC algorithm fits which need, GS QSC 001 is the operational reference from a European industry perspective. ## What ETSI ISG QSC Does ETSI's Industry Specification Group on Quantum-Safe Cryptography is a working group of cryptographers, industry vendors, and operators. Founded in 2014, ISG QSC produces documents that complement (rather than compete with) ISO/IEC and NIST standards. ISG QSC publishes two types of documents: - **GS** (Group Specification): formal specifications agreed by the group - **GR** (Group Report): informational reports, surveys, analyses GS QSC 001 is one of the foundational specifications. The latest version is v1.1.1, with updates tracking PQC standardization progress. ## Use Case Categories GS QSC 001 organizes use cases into several categories. The categorization helps map cryptographic requirements to algorithm choices. ### Confidentiality of long-term data Examples: medical records, intelligence archives, legal documents, financial records. Requirements: data encrypted today must remain confidential for decades. Vulnerability to harvest-now-decrypt-later is highest. Quantum-safe encryption is most urgent. Algorithm fit: large key/ciphertext sizes are acceptable because storage and transmission happen once, decryption is rare. ML-KEM with X25519 hybrid is appropriate. HQC (when standardized in FIPS 209) provides a non-lattice backup option. ### Real-time confidentiality Examples: TLS handshakes, VPN tunnels, streaming media. Requirements: low latency, small handshake overhead, billions of operations per day at scale. Algorithm fit: ML-KEM-512 hybrid with X25519 is the practical choice. The handshake adds a few kilobytes, which is acceptable for most networks. ML-KEM-1024 only when CNSA 2.0 mandates it. ### Authentication and integrity Examples: TLS server identity, code signing, document signing, IoT device authentication. Requirements: signature size matters less than verification speed for high-volume use; signing operation latency varies by use case. Algorithm fit: ML-DSA-44 for general use, ML-DSA-87 for high-assurance. Ed25519 in hybrid for transition. SLH-DSA for small-scale firmware signing where simplicity matters. LMS for ultra-long-lived signatures with careful state management. See [LMS stateful signatures](../lms-stateful-signatures.html). ### Code signing and firmware integrity Examples: software updates, embedded device firmware, secure boot chains. Requirements: keys live for years to decades. Signature verification on the device must be fast and small. Hash-based signatures attractive because of minimal cryptographic assumptions. Algorithm fit: LMS or XMSS for stateful hash-based with smallest signatures (Business tier of QNSQY supports LMS). SLH-DSA for stateless hash-based with simpler operations but larger signatures. ### Group communication Examples: secure conferencing, multicast, group messaging. Requirements: efficient group key updates, forward secrecy, post-compromise security. Algorithm fit: MLS protocol (RFC 9420) with PQC enhancements. ML-KEM for member key exchange. See [IETF RFC 9420 MLS](../ietf-rfc-9420-mls.html). ### Constrained devices Examples: smart cards, IoT sensors, RFID, low-power microcontrollers. Requirements: tiny RAM, slow CPU, limited bandwidth. Algorithm fit: this is where PQC migration is hardest. ML-KEM-512 has 800-byte public keys, which is large for some smart cards. HBS schemes (LMS, XMSS) can fit if signature verification is rare. Some research targets lightweight PQC variants. ## Algorithm Selection Matrix GS QSC 001 effectively provides a selection matrix mapping use cases to algorithm families. A simplified view: | Use Case | Primary | Hybrid | Backup | |----------|---------|--------|--------| | TLS handshakes | ML-KEM-768 | + X25519 | HQC-128 (future) | | Long-term file encryption | ML-KEM-1024 | + X25519 | HQC-256 | | Code signing | ML-DSA-65 | + Ed25519 | SLH-DSA | | Firmware (long-lived) | LMS | (none) | SLH-DSA | | Document signing | ML-DSA-44 | + Ed25519 | SLH-DSA | QNSQY's tier mapping aligns with this matrix: - Free: ML-KEM-512 hybrid + X25519, ML-DSA-44 (matches general TLS / lightweight use) - Pro: all ML-KEM hybrid sizes, ML-DSA-44/65, all symmetric algorithms (matches business use) - Business: adds HQC, FN-DSA, LMS, pure (non-hybrid) KEM (matches high-assurance use) ## Algorithmic Trade-offs GS QSC 001 helps users understand trade-offs. Some highlights: ### Key size vs security level ML-KEM key sizes scale with security level. ML-KEM-512 (Cat 1, ~AES-128) has 800-byte public keys. ML-KEM-1024 (Cat 5, ~AES-256) has 1568-byte public keys. The size doubles for the security level jump. For most uses, Cat 1 is sufficient. Cat 5 only when policy or regulation demands. ### Signature size vs signing speed ML-DSA signatures are 2.4 to 4.6 KB. SLH-DSA signatures are 8 to 50 KB. FN-DSA (Falcon) signatures are 700 bytes to 1.3 KB. Smaller signatures usually mean slower or more complex signing. Choose based on what is scarce: bandwidth, signer CPU, verifier CPU. ### Stateful vs stateless LMS and XMSS are stateful. The signer must track which one-time keys have been used. Reusing a one-time key destroys security. SLH-DSA is stateless: any number of signatures, no state required. The trade-off is signature size: SLH-DSA signatures are 5x to 30x larger than LMS or XMSS at equivalent security. ### Pure vs hybrid Pure PQC: smaller, faster, but bets entirely on the new algorithm. Hybrid: larger, slower, but secure if either algorithm holds. Most organizations should default to hybrid through 2030+. CNSA 2.0 will likely move to pure PQC after that. ## Use Case: Hospital Imaging Archives A specific example to make this concrete. A hospital archives medical imaging data (CT scans, MRIs) for at least 7 years per regulation, often for the patient's lifetime. Each scan can be hundreds of megabytes. The data must remain confidential indefinitely. GS QSC 001 guidance for this use case: - Long-term confidentiality: highest priority for PQC migration - Hybrid mode: ML-KEM-1024 with X25519, AES-256-GCM for the bulk encryption - Keys: rotated annually for the KEK, derived per-file for DEK - Validation: FIPS 140-3 / ISO/IEC 19790 modules required by HIPAA-equivalent regulations QNSQY's Business tier supports exactly this configuration: ML-KEM-1024 hybrid, AES-256-GCM, with file-by-file key derivation via HKDF-SHA-256. Multi-recipient encryption lets multiple authorized users (radiologist, primary physician, audit office) read the same encrypted scan without re-encrypting. ## Use Case: 5G Subscriber Identity Another concrete example: 5G subscriber identity confidentiality. The IMSI (subscriber identifier) must be protected when a phone connects to a network. Currently encrypted with the network operator's RSA or ECC key. Quantum threat: harvested encrypted IMSIs decrypt to reveal subscriber identity in the future. GS QSC 001 guidance: - Long-lived confidentiality (decades of subscriber privacy) - Real-time performance (millions of attaches per day) - Hybrid: ML-KEM-768 with classical ECC 3GPP is working with ETSI on 5G PQC migration. Expected deployment in 5G-Advanced and 6G generations. ## Use Case: Power Grid Sensor Firmware A third example: firmware updates for power grid sensors. Sensors deployed in the field for 20+ years. Updates rare but critical. Constrained processors with limited RAM and flash. GS QSC 001 guidance: - Long-lived signing key (must be valid for sensor lifetime) - Stateful hash-based signature (LMS) for smallest signature size - Careful state management: signing key on a hardware security module that tracks state QNSQY supports LMS in Business tier exactly for this kind of use case. ## Use Case: Connected Vehicle Over-the-Air Updates A fourth example worth detailing: automotive over-the-air firmware updates. Modern cars carry 80 to 150 ECUs, each with its own software, and most major OEMs have committed to OTA delivery for the lifetime of the vehicle, which is typically 12 to 20 years. The signing keys used to authenticate update packages must remain trusted for that entire window. GS QSC 001 guidance for this use case: - Long-lived key validity matched to vehicle service life - Verification on constrained ECUs with sub-megabyte RAM budgets - Strong evidence trail to satisfy ISO/SAE 21434 cybersecurity requirements - Resistance to fleet-wide compromise if any single key leaks Recommended posture: use SLH-DSA-128s or LMS for the trust anchor (small verification cost, hash-based hardness, no lattice), with ML-DSA-65 in hybrid for the operational signing layer that rotates more frequently. Several OEMs are now deploying this two-tier model in pilot fleets, building on ISO/SAE 21434 conformance. QNSQY's signature support covers ML-DSA-44/65/87 hybrid plus LMS in the Business tier, which matches the recommended automotive posture for both anchor and operational keys. ## Use Case: Pharmaceutical Cold-Chain Telemetry A fifth example: pharmaceutical cold-chain telemetry. Vaccines and biologics must be tracked from manufacturer to patient with continuous temperature logging. The telemetry sensors live in shipping containers, run for months on a battery, and must produce signed evidence that holds up in regulatory inspections years later. The cryptographic profile here is unusual. Each data point is small (kilobytes), the signing rate is low (one log entry per minute), but the device must run for nine months on a single CR2032 cell. Classical ECDSA over P-256 fits comfortably. ML-DSA-44 signatures are 2420 bytes versus 64 bytes for ECDSA, which means more flash writes and more BLE radio time per log entry. The radio cost dominates the energy budget. GS QSC 001 guidance suggests SLH-DSA in the small parameter set for these cases, since the public key is small (32 bytes) and verification is cheap on the cloud side, even though signing is slower. The trade-off favors hash-based signatures over lattice for ultra-low-power IoT until lattice processors arrive in microcontrollers. ENISA's 2024 IoT cryptography report covers these constrained-device profiles in detail. ## Implementation Considerations GS QSC 001 also notes implementation considerations that PQC introduces: ### Side-channel resistance Lattice arithmetic involves polynomial multiplication, which has cache and timing characteristics that classical ECC does not. Constant-time implementations are essential. Reference implementations from NIST submissions are a starting point but production code needs additional hardening. ### Memory requirements ML-KEM key generation needs more RAM than ECC. For constrained devices, this rules out some configurations. ML-KEM-512 is the most accessible for memory-constrained environments. ### Random number generators PQC algorithms consume more randomness than classical algorithms. ML-DSA in particular uses substantial random bytes per signature. RNG quality and throughput matter more. QNSQY uses OS RNG (`getrandom` on Linux, `BCryptGenRandom` on Windows) directly without intermediate state, ensuring fresh entropy for every cryptographic operation. ## FAQ ### Is GS QSC 001 free to read? Yes. ETSI publishes most documents free at https://www.etsi.org/. Search for "GS QSC 001" to find the latest version. ### How does GS QSC 001 differ from TR 103 619? TR 103 619 is a Technical Report focused on migration strategy. GS QSC 001 is a Group Specification focused on algorithmic framework and use case fit. They complement each other: TR 103 619 tells you how to plan, GS QSC 001 tells you what algorithm to pick for which use. ### Does GS QSC 001 endorse specific algorithms? It catalogs algorithm families and their fit to use cases. The specific algorithm choices are deferred to NIST PQC standards (now FIPS 203, 204, 205, with 206 and 209 in progress). GS QSC 001 maps these algorithms to use case categories. ### Does QNSQY align with GS QSC 001 use cases? Yes. QNSQY's tier structure (Free, Pro, Business) maps to common GS QSC 001 use case categories: general use, business use, high-assurance and long-term archival. The algorithm support matches: ML-KEM hybrid for confidentiality, ML-DSA hybrid for signing, LMS for long-lived signatures, HQC for non-lattice diversification. See [pricing](../../pricing.html). ### What is the relationship between ETSI ISG QSC and the IETF? ETSI ISG QSC focuses on standards and use case framework. The IETF focuses on protocol specifications (TLS, IPsec, etc.). They coordinate informally; many of the same experts contribute to both. ETSI documents inform IETF drafts and vice versa. See [IETF PQUIP drafts](../ietf-pquip-drafts.html). ### How often is GS QSC 001 updated? ETSI revises GS documents on a roughly two- to three-year cycle, faster when underlying standards (NIST FIPS) move. The current v1.1.1 will likely be superseded by a new version once HQC is finalized in FIPS 209 and ISO/IEC 18033 incorporates ML-KEM. Subscribers to the ETSI announcement list receive notifications of new drafts. ### Does GS QSC 001 cover homomorphic or attribute-based encryption? No. The current scope is symmetric encryption, KEMs, signatures, and hash functions. Advanced primitives (homomorphic encryption, attribute-based encryption, post-quantum identity-based encryption) are tracked by separate ETSI working groups and ISO/IEC 18033-7 (in development for FHE). ## Sources 1. ETSI GS QSC 001 v1.1.1, "Quantum-Safe Cryptography (QSC); Quantum-safe algorithmic framework," July 2016. https://www.etsi.org/deliver/etsi_gs/QSC/001_099/001/01.01.01_60/gs_QSC001v010101p.pdf 2. ETSI ISG QSC, Industry Specification Group on Quantum-Safe Cryptography. https://www.etsi.org/committee/qsc 3. ETSI TR 103 619, "CYBER; Migration strategies and recommendations to Quantum Safe schemes," July 2020. https://www.etsi.org/deliver/etsi_tr/103600_103699/103619/01.01.01_60/tr_103619v010101p.pdf 4. NIST FIPS 203, "Module-Lattice-Based Key-Encapsulation Mechanism Standard," August 2024. https://csrc.nist.gov/pubs/fips/203/final 5. ETSI Quantum-Safe Cryptography page. https://www.etsi.org/technologies/quantum-safe-cryptography 6. ISO/SAE 21434:2021, "Road vehicles — Cybersecurity engineering." https://www.iso.org/standard/70918.html 7. ENISA Post-Quantum Cryptography for IoT report, 2024. https://www.enisa.europa.eu/publications/post-quantum-cryptography-current-state-and-quantum-mitigation ## Related Articles - [ETSI quantum-safe standards](../etsi-quantum-safe-standards.html) - [ETSI TR 103 619](../etsi-tr-103-619.html) - [LMS stateful signatures](../lms-stateful-signatures.html) - [Hybrid encryption](../hybrid-encryption.html) - [What is post-quantum cryptography?](../what-is-post-quantum-cryptography.html) --- ### Protect Your Data Before Q-Day Arrives QNSQY's NIST-standardized post-quantum encryption protects files against both current and quantum-era threats. [Try QNSQY](../../pricing.html)