[Paper] When Security Meets Usability: An Empirical Investigation of Post-Quantum Cryptography APIs

Source: arXiv - 2602.14539v1

Overview

The paper When Security Meets Usability: An Empirical Investigation of Post‑Quantum Cryptography APIs examines how developers actually use the newly‑standardized post‑quantum cryptography (PQC) libraries. By observing real programmers tackling short coding tasks, the authors reveal why PQC adoption is lagging and what can be done to make the transition from RSA/ECDSA to quantum‑resistant schemes smoother.

Key Contributions

• First systematic usability study of PQC APIs – fills a gap left by earlier work that only looked at classical crypto libraries.
• Empirical data from 30+ developers performing realistic integration tasks with NIST‑standardized PQC primitives (e.g., Kyber, Dilithium, Falcon).
• Identification of cognitive friction points such as terminology mismatches, missing error‑handling guidance, and confusing key‑generation workflows.
• Actionable design recommendations for API designers, documentation authors, and tooling vendors (e.g., unified naming, example‑driven tutorials, IDE plug‑ins).
• Open‑source artifact package (task scripts, raw interaction logs, and a reproducible analysis pipeline) for the community to extend the study.

Methodology

1. Participant recruitment – 32 software engineers (mix of junior, mid‑level, and senior) with basic cryptography knowledge but no prior PQC experience.
2. Task design – Four short programming scenarios that mirror common real‑world needs:
   • Generating a key pair for a lattice‑based KEM (Kyber).
   • Signing and verifying a message with a hash‑based signature scheme (Dilithium).
   • Serializing/deserializing keys for storage.
   • Integrating a PQC KEM into an existing TLS‑like handshake flow.
3. Think‑aloud protocol – Participants verbalized their reasoning while working, allowing the researchers to capture decision points and misconceptions.
4. Data collection – Screen recordings, keystroke logs, and post‑task questionnaires (NASA‑TLX for workload, SUS for perceived usability).
5. Analysis – Qualitative coding of observed errors (e.g., misuse of API calls, insecure defaults) and quantitative comparison of task completion time, success rate, and mental effort across the four APIs.

The approach is deliberately lightweight: developers receive only the official README and API reference, mimicking the “minimal onboarding” scenario most teams face when swapping out a legacy crypto library.

Results & Findings

The authors attribute these outcomes to three main usability gaps:

1. Terminology misalignment – PQC literature uses domain‑specific terms (e.g., “ciphertext” for a KEM encapsulation) that clash with developers’ expectations from classic PKI.
2. Sparse, example‑driven documentation – Most libraries provide only API signatures and a single “hello‑world” snippet, leaving developers to infer correct key‑format handling.
3. Lack of defensive programming aids – No built‑in checks for parameter compatibility or safe random‑seed handling, forcing developers to write boiler‑plate validation code.

Practical Implications

• For library maintainers: Adopt a developer‑first API surface—e.g., expose high‑level “encrypt/decrypt” helpers that hide the encapsulation/decapsulation steps, and enforce safe defaults (constant‑time operations, secure RNG).
• For documentation teams: Publish workflow‑centric guides (step‑by‑step key lifecycle, migration cheat‑sheets from RSA/ECDSA to specific PQC schemes) and embed runnable code snippets in Markdown/HTML that can be copied directly into IDEs.
• For tooling vendors: Integrate PQC‑specific linting rules into static analysis tools (detect missing parameter‑set arguments, warn about insecure RNG usage) and provide IDE snippets or wizards that scaffold a complete PQC integration.
• For DevOps/security engineers: Anticipate a longer onboarding window when rolling out PQC‑enabled services; allocate time for code reviews focused on correct API usage and consider “wrapper” libraries that abstract away low‑level PQC details.
• For educators & training platforms: Include hands‑on labs that mirror the study’s tasks, reinforcing the correct mental model of PQC primitives before they hit production code.

By addressing these usability pain points, organizations can accelerate the NIST‑mandated migration timeline (targeted deprecation of RSA/ECDSA by 2035) without compromising software quality.

Limitations & Future Work

• Sample bias – Participants were recruited from a single tech hub and had a baseline familiarity with cryptography; results may differ for developers in other domains or with less security background.
• Scope of algorithms – The study focused on three NIST‑selected schemes (Kyber, Dilithium, Falcon). Emerging lattice‑based or code‑based candidates could exhibit different usability characteristics.
• Static tasks – Real‑world projects involve longer integration cycles, dependency management, and performance tuning, which were not captured in the short lab tasks.

Future research directions suggested by the authors include longitudinal field studies in production teams, automated usability testing of IDE plug‑ins, and cross‑language comparisons (e.g., Rust vs. Go vs. Java PQC bindings).

Authors

• Marthin Toruan
• R. D. N. Shakya
• Samuel Tseitkin
• Raymond K. Zhao
• Nalin Arachchilage

Paper Information

• arXiv ID: 2602.14539v1
• Categories: cs.CR, cs.SE
• Published: February 16, 2026
• PDF: Download PDF