Pith. sign in

REVIEW 4 major objections 4 minor 61 references

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

T0 review · 4 major / 4 minor · reviewed 2026-08-02 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read A usability study of two post-quantum cryptography APIs finds that every participant omitted error handling and key destruction, with multiple shared-secret leaks.

desk verdict First systematic usability study of PQC APIs, with real qualitative value, but the headline completion-rate finding is confounded by the session length and the API comparison has an unresolved conflict of interest. read the letter →

arxiv 2602.14539 v1 pith:4R5XCRD7 submitted 2026-02-16 cs.CR cs.HCcs.SE

Marthin Toruan , R.D.N. Shakya , Samuel Tseitkin , Raymond K. Zhao , Nalin Arachchilage This is my paper · ORCID
classification cs.CRcs.HCcs.SE
keywords post-quantumcryptographyPQCAPIusabilitydeveloperstudyKEMML-KEMML-DSAthink-aloudprotocolsecure-by-defaultdesign
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

This paper argues that the usability of post-quantum cryptography (PQC) APIs is an unexamined and serious barrier to secure migration. In a controlled study, 16 developers implemented a KEM/DSA secure channel using two different PQC APIs with minimal onboarding; every participant failed to add error handling for encapsulation/decapsulation and none explicitly destroyed keys, while several leaked shared secrets. The authors identify cognitive friction points—low-level granularity, jargon-heavy documentation, hidden workflow sequencing—and trace them to API design choices. If correct, the findings mean that shipping NIST-standard algorithms inside an API is not enough: without secure-by-default design and developer-centered documentation, PQC adoption will repeat the misuse failures of classical crypto APIs.

What carries the argument

The carrying mechanism is the controlled usability experiment combining think-aloud observation with the Cognitive Dimensions Framework (a taxonomy for rating how API design affects comprehension). Participants were asked to implement a KEM/DEM hybrid encryption channel and a digital-signature handshake using two contrasting PQC APIs—one a local library, one an endpoint service—and their code was audited for security-relevant errors. The framework maps observed friction to dimensions such as abstraction level, penetrability, and error-proneness, letting the authors tie specific API design choices (e.g., exposing KDF separately, returning 32-byte vs 64-byte keys, requiring auth headers) to sp

What would settle it

Ask a fresh cohort of, say, 40 professional developers to implement the same secure channel using a widely used production PQC library (or the same two APIs) with their normal documentation and usual search/AI tools, then audit for the seven error classes in Table III; if the rates of missing error handling and key destruction drop substantially below 100%, or if shared-secret leaks vanish, the claim that PQC APIs are intrinsically unusable for generalists would be falsified.

Watch

Extended reading notes

Core claim

The paper's central discovery is that non-specialist developers, when given PQC APIs with minimal onboarding, systematically produce insecure implementations: 100% of participants omitted error handling for KEM wrap/unwrap and explicit key destruction, 4 of 16 leaked shared secrets, and no one completed all four tasks in a secure-channel construction. The authors attribute these failures not to individual incompetence but to structural API usability issues—excessively low-level abstraction, documentation written for cryptography-aware readers, non-intuitive naming, and unstated operation sequencing—and support this with think-aloud transcripts and a Cognitive Dimensions analysis. The result

Load-bearing premise

The central claim assumes that the two APIs and the minimal-onboarding test setting are representative of how PQC APIs are actually used; if production PQC libraries come with better onboarding or the participants were atypical, the near-universal failure rates could be an artifact of the experiment rather than a property of PQC APIs.

Editorial extensions

If this is right

  • If PQC API usability is as poor as observed, the 2035 deprecation of RSA/ECDSA will push developers toward insecure integrations unless libraries add higher-level, secure-by-default entry points.
  • APIs that internally apply the KDF and return a ready-to-use symmetric key reduce one class of errors but introduce others, suggesting the optimal design may be a layered API with both high-level and low-level paths.
  • Documentation that shows complete, runnable client-server workflows—not just isolated function calls—could reduce trial-and-error assembly and the resulting misconfigurations.
  • Standardizing on NIST's encapsulation/decapsulation terminology would remove naming confusion that costs developers time and leads to key-confusion errors.
  • The absence of testing guidance correlates with untested crypto code; built-in test helpers or checkable error states would raise the chance that developers verify their implementations.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • A direct testable extension: build a 'secure channel in one call' function implementing KEM, KDF, AES, and DSA internally, and run the same task with the same population; the paper predicts misuse rates would drop sharply for non-experts.
  • The 100% missing error-handling figure may partly reflect Python's exception style and the skeleton code's structure, so the same API in a language with explicit status codes could produce different—though not necessarily better—outcomes.
  • Because the study compared only two APIs, the specific rates are less robust than the qualitative pattern; similar cognitive frictions likely appear in other PQC libraries, but confirming this requires a broader multi-API study.
  • The performance trade-off between the two APIs (faster KEM setup vs faster symmetric integration) suggests that PQC API design is a resource-allocation problem; future APIs could offer profiles for different developer expertise levels rather than a single abstraction.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

4 major / 4 minor

Summary. The paper reports a between-subjects usability study of two post-quantum cryptography (PQC) APIs: QuantCrypt, a local Python library, and PQ-Sandbox, an endpoint-based API. Sixteen developers (eight per API) performed four sequential tasks—KEM key establishment, symmetric encryption, DSA-authenticated handshake, and DSA-signed message exchange—while thinking aloud under remote observation. The authors report task completion rates and times, analyze final code for security-relevant flaws, and map qualitative questionnaire responses to an extended Cognitive Dimensions Framework. They claim that PQC API usability has not been systematically studied before, that developers encounter pervasive security-relevant misuses (e.g., 100% omitted KEM error handling and key destruction, several shared-secret leaks), and that no participant completed all four tasks. The paper recommends secure-by-default high-level functions, better documentation, and NIST-aligned terminology.

Significance. The topic is timely and important: PQC migration is proceeding rapidly, and developer-facing API usability is a likely source of deployment failures. The study has real methodological strengths: standardized skeleton code, think-aloud sessions with screen recordings, verbatim participant quotes, dual-coder thematic analysis, and full raw time data in an appendix. If the empirical claims were robust, the paper would be a valuable contribution to usable security and PQC adoption. However, the central quantitative claims are only partially supported. The fixed two-hour session cap confounds the headline completion-rate results, the sample is small and underpowered for the t-tests used, and one of the two compared APIs is a vendor research prototype provided by a co-affiliated company. These issues limit internal and external validity. The qualitative insights about documentation, terminology, abstraction, and developer mental models remain useful and could support a defensible revised paper.

major comments (4)
  1. [§III-D, Table II, Table V] The completion-rate results are confounded by the fixed two-hour session cap. The pilot (§III-D) found average task duration exceeded 90 minutes, yet the main study kept four 15–20 minute tasks plus a briefing and a 20–30 minute questionnaire under a two-hour cap, with an explicit 'do you wish to continue?' prompt. Raw times in Table V imply cumulative T1+T2+T3 times at or above 120 minutes for several participants (e.g., QC P16: 57+54+30=141 minutes) before questionnaire time. Therefore, the 0% Task 4 completion rate—and part of the 50–87.5% rates for Tasks 2 and 3—reflect session length, not API usability. This undermines the strongest evidence-based claim in the abstract and the RQ2 completion-time comparisons, since means are computed on truncated, non-random subsets (T2 N=7 vs 7; T3 N=5 vs 4). Please re-analyze using time-to-task-attempt data, report completion as 'not completed wit
  2. [§IV-B] The inferential statistics are not robust enough for the strength of the claims. The paper reports unpaired t-tests on subsets of 8, 7, and 5/4 participants without a pre-registered analysis, power analysis, or correction for multiple comparisons. The language 'clear and statistically significant' (p=0.0079, p=0.0015) overstates confidence: with N=16 and missing data, the meaningful signal is the descriptive error patterns in Table III, not the p-values. Please re-frame the quantitative comparisons as exploratory and report effect sizes, bootstrapped confidence intervals, or nonparametric tests. The paper's own limitation section (VI) acknowledges the small sample but does not address the missing-data structure introduced by the time cap.
  3. [§III-A, Acknowledgment] The comparison underpinning RQ2 is not a clean 'endpoint-based PQC API versus local library' comparison. PQ-Sandbox is described as a research prototype from ExeQuantum, 'intentionally simplified for experimentation,' and the acknowledgments thank Samuel Tseitkin and ExeQuantum for technical support with the APIs and Sandbox; Tseitkin is also an author. This conflates API architecture with prototype maturity and creates an undisclosed affiliation with one of the two evaluated systems. Results on PQ-Sandbox may reflect prototype quality rather than endpoint-based PQC APIs generally, and the Task 1/Task 2 time differences may be due to design choices of a vendor prototype. Please reframe RQ2 as comparing two specific implementations, disclose the affiliation in the methodology, and temper generalizability claims.
  4. [Abstract, §VII] The paper's scope claims exceed its design. The abstract states that 'the usability of PQC APIs has not been systematically studied' and the conclusion uses ecosystem-level language, but the evidence is a single study of two APIs with 16 participants. Section VI correctly limits 'quantitative generalizability,' yet the framing in the abstract and conclusion still suggests broad conclusions about the entire PQC API ecosystem. Please align the claims with the study design: the paper can legitimately report observed usability barriers and security-relevant mistakes in these two APIs and should not present them as established properties of PQC APIs in general.
minor comments (4)
  1. [Appendix C heading] The appendix heading 'TASKPEFORMANCERAWDATA' should be 'TASK PERFORMANCE RAW DATA.'
  2. [Appendix B] Typographical and grammatical issues: 'you need to runt the server' should be 'run'; 'what you read and work could be captured' is awkward. A light language edit is recommended throughout.
  3. [Table III] The legend is difficult to parse because the same symbols (●, ✗) are used for leak detection and missing handling under different columns. Consider separate sub-headers and explicit column meanings to avoid ambiguity.
  4. [§V-A] There is a grammatical issue in the sentence 'Although time constraints contributed to this behavior, but unclear documentation...'—the 'although' and 'but' are redundant.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity; the study is empirical observation, not a derivation. Author-overlap and self-cited methodology are validity/conflict concerns, not circular steps.

full rationale

This paper is an empirical usability study, not a derivation. The central results—completion rates, completion times, and security-relevant flaw counts in Tables II and III—are measured from 16 participants' behavior against task instructions and NIST SP 800-227 criteria; they are not outputs of fitting a model to the same quantities. No fitted parameter is renamed as a prediction, no uniqueness theorem is imported from the authors' prior work, and no ansatz is smuggled in via self-citation. The self-citations to Wijayarathna and Arachchilage ([24], [50], [51], [52], [53]) supply the Cognitive Dimensions Framework and questionnaire, but that framework is a published analytical lens, not a result that assumes PQC APIs are unusable; the observed failure rates stand independently of it. The author-overlap with ExeQuantum and the fact that PQ-Sandbox is an 'intentionally simplified' research prototype (Sec. III-A) are genuine internal-validity/conflict-of-interest limitations, as is the two-hour session cap that confounds the 0% Task-4 completion rate (Sec. III-D, Table V). The paper itself acknowledges these limits (Sec. VI). These concerns weaken generalizability and causal attribution, but they do not make the empirical observations equivalent to the study's inputs by construction. Therefore no circular step meets the evidentiary bar.

Assumptions & free parameters 2 free parameters · 4 assumptions · 0 invented entities

No new physical or cryptographic entities are introduced. The study's parameters are methodological judgment calls: task durations, CDF dimension mapping, and thematic coding labels. The most significant loaded assumption is that the experimental context — minimal onboarding, no domain training, task-focused sessions — captures the relevant real-world failure mode. Conflict-of-interest note: one API under evaluation belongs to an acknowledged technical supporter of the study.

free parameters (2)
  • Task time thresholds / task duration allotment = 15-20 minutes per task
    The task design assumes each task should take 15-20 minutes, which proved wrong (Task 1 averaged 39-65 minutes and nobody finished Task 4). This is not a fitted parameter in the mathematical sense, but it is a design parameter that shaped the outcome (0% completion on Task 4).
  • CDF dimension selection and mapping = 15 dimensions
    The study uses the Wijayarathna & Arachchilage 15-dimension extension of Clarke's CDF. Selecting which dimensions to report (some 'no problem found') and mapping quotes to themes involves subjective researcher judgment, mitigated by dual coding but not quantified.
assumptions (4)
  • domain assumption PQC APIs will be used by generalist developers without cybersecurity expertise, and that use matters for real-world security.
    The whole study presupposes that developer-facing API usability is a critical bottleneck for PQC adoption. This is well-supported by prior classical crypto-API usability literature, so it is a reasonable domain assumption, not an ad hoc invention.
  • domain assumption Qualitative self-report and think-aloud behavior during a short remote session predicts real-world deployment behavior.
    The paper relies on the standard usability assumption that controlled tasks with think-aloud reveal realistic cognitive barriers. The authors acknowledge in their limitations that this reflects 'a low-support environment rather than real-world operational deployments.'
  • standard math The Cognitive Dimensions Framework provides valid metrics for API usability.
    The paper uses CDF as its analytical lens, citing prior work. This is an established methodology, though its reliability for security-specific feedback depends on the adaptation by Wijayarathna & Arachchilage.
  • domain assumption ML-KEM and ML-DSA are representative PQC primitives and their API exposure is representative of PQC APIs generally.
    The study only evaluates ML-KEM and ML-DSA via two APIs. Other PQC algorithms (e.g., SLH-DSA, stateful hash-based schemes) have different usability profiles, as the paper itself notes when discussing EasySigner in related work.

how reviews work

0 comments
Cite this review

Pith. "Pith review of When Security Meets Usability: An Empirical Investigation of Post-Quantum Cryptography APIs." pith.science (2026). https://pith.science/paper/4R5XCRD7

@misc{pith2026260214539,
  author       = {Pith},
  title        = {Pith review of: When Security Meets Usability: An Empirical Investigation of Post-Quantum Cryptography APIs},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/4R5XCRD7}},
  note         = {Machine review of arXiv:2602.14539}
}
read the original abstract

Advances in quantum computing increasingly threaten the security and privacy of data protected by current cryptosystems, particularly those relying on public-key cryptography. In response, the international cybersecurity community has prioritized the implementation of Post-Quantum Cryptography (PQC), a new cryptographic standard designed to resist quantum attacks while operating on classical computers. The National Institute of Standards and Technology (NIST) has already standardized several PQC algorithms and plans to deprecate classical asymmetric schemes, such as RSA and ECDSA, by 2035. Despite this urgency, PQC adoption remains slow, often due to limited developer expertise. Application Programming Interfaces (APIs) are intended to bridge this gap, yet prior research on classical security APIs demonstrates that poor usability of cryptographic APIs can lead developers to introduce vulnerabilities during implementation of the applications, a risk amplified by the novelty and complexity of PQC. To date, the usability of PQC APIs has not been systematically studied. This research presents an empirical evaluation of the usability of the PQC APIs, observing how developers interact with APIs and documentation during software development tasks. The study identifies cognitive factors that influence the developer's performance when working with PQC primitives with minimal onboarding. The findings highlight opportunities across the PQC ecosystem to improve developer-facing guidance, terminology alignment, and workflow examples to better support non-specialists.

Figures

Figures reproduced from arXiv: 2602.14539 by the authors.

Figure 1
Figure 1. Cognitive Dimensions Framework. introduce implementation flaws in applications when interact￾ing with complex or insufficiently supportive PQC APIs and libraries. To ensure that the findings reflect real-world programming scenarios, we employed a moderated remote usability study design. This approach maximized ecological validity by allow￾ing participants to use their familiar Integrated Development Environments (ID… view at source ↗
Figure 2
Figure 2. Study Procedure Diagram. ineligible individuals were not asked for further details, pro￾tecting privacy and providing a clear rationale for ineligibility. Eligible participants then received a Participant Information and Consent Form via email and, upon agreement, a researcher scheduled the experimental session based on their availability. A Microsoft Teams link confirmed the session. D. The pilot study Before the m… view at source ↗
Figure 4
Figure 4. Mistake on PQ-Sandbox Documentation (Source: [58]). [PITH_FULL_IMAGE:figures/full_fig_p014_4.png] view at source ↗
Figures from the paper (1 more)
Figure 5
Figure 5. Figure 5: Mistake on Quantcrypt Documentation (Source: [59]). [PITH_FULL_IMAGE:figures/full_fig_p014_5.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

61 extracted references · 6 canonical work pages

  1. [1]

    Quantum computing: A taxonomy, systematic review and future directions,

    S. S. Gill, A. Kumar, H. Singh, M. Singh, K. Kaur, M. Usman, and R. Buyya, “Quantum computing: A taxonomy, systematic review and future directions,”Software: Practice and Experience, vol. 52, no. 1, pp. 66–114, 2022. [Online]. Available: https: //onlinelibrary.wiley.com/doi/abs/10.1002/spe.3039

    work page doi:10.1002/spe.3039 2022

  2. [2]

    Algorithms for quantum computation: discrete logarithms and factoring,

    P. Shor, “Algorithms for quantum computation: discrete logarithms and factoring,” inProceedings 35th Annual Symposium on Foundations of Computer Science, 1994, pp. 124–134. 12

    1994

  3. [3]

    Polynomial-time algorithms for prime factorization and discrete logarithms on a quantum computer,

    P. W. Shor, “Polynomial-time algorithms for prime factorization and discrete logarithms on a quantum computer,”SIAM Journal on Computing, vol. 26, no. 5, pp. 1484–1509, 1997. [Online]. Available: https://doi.org/10.1137/S0097539795293172

    doi:10.1137/s0097539795293172 1997

  4. [4]

    Cryptographic attack possibilities over rsa algorithm through classical and quantum computation,

    K. K. Soni and A. Rasool, “Cryptographic attack possibilities over rsa algorithm through classical and quantum computation,” in2018 International Conference on Smart Systems and Inventive Technology (ICSSIT), 2018, pp. 11–15

    2018

  5. [5]

    Quantum-driven big data processing,

    D. Handa, K. K. Nikhil, S. Duvarakanath, and M. K, “Quantum-driven big data processing,” in2024 International Conference on Advances in Modern Age Technologies for Health and Engineering Science (AMATHE), 2024, pp. 1–7

    2024

  6. [6]

    How to factor 2048 bit rsa integers in 8 hours using 20 million noisy qubits,

    C. Gidney and M. Eker ˚a, “How to factor 2048 bit rsa integers in 8 hours using 20 million noisy qubits,”Quantum, vol. 5, p. 433, Apr

  7. [7]

    Optimizing win- dowed arithmetic for quantum attacks against rsa-2048,

    A. Luongo, V . Narasimhachar, and A. Sireesh, “Optimizing win- dowed arithmetic for quantum attacks against rsa-2048,” in2025 62nd ACM/IEEE Design Automation Conference (DAC), 2025, pp. 1–7

  8. [8]

    D. J. Bernstein,Introduction to post-quantum cryptography. Berlin, Heidelberg: Springer Berlin Heidelberg, 2009, ch. 1, pp. 1–14. [Online]. Available: https://doi.org/10.1007/978-3-540-88702-7 1

    work page doi:10.1007/978-3-540-88702-7 2009

Show all 61 references
  1. [9]

    Post- quantum cryptography initiative: Critical infrastructure security,

    Cybersecurity and Infrastructure Security Agency (CISA), “Post- quantum cryptography initiative: Critical infrastructure security,” U.S. Department of Homeland Security, Tech. Rep., 2022. [Online]. Available: https://www.cisa.gov/quantum

    2022

  2. [10]

    Singh,Managing the Quantum Cybersecurity Threat, 1st ed., ser

    H. Singh,Managing the Quantum Cybersecurity Threat, 1st ed., ser. Harvest Now, Decrypt Later. CRC Press, 2024, ch. 9, pp. 142–158. [Online]. Available: https://doi.org/10.1201/9781003475286-9

    2024 doi

  3. [11]

    A pragmatic analysis of pre- and post-quantum cyber secu- rity scenarios,

    A. Ali, “A pragmatic analysis of pre- and post-quantum cyber secu- rity scenarios,” in2021 International Bhurban Conference on Applied Sciences and Technologies (IBCAST), 2021, pp. 686–692

    2021

  4. [12]

    Selected algorithms for post-quantum cryptography,

    National Institute of Standards and Technology, “Selected algorithms for post-quantum cryptography,” 2025, accessed: 2025-04-19. [Online]. Available: https://csrc.nist.gov/Projects/ post-quantum-cryptography/selected-algorithms

    2025

  5. [13]

    Transition to post-quantum cryptography standards,

    D. Moody, A. Regenscheid, R. Perlner, A. Robinson, and D. Cooper, “Transition to post-quantum cryptography standards,” National Institute of Standards and Technology, Tech. Rep., 2024. [Online]. Available: https://nvlpubs.nist.gov/nistpubs/ir/2024/NIST.IR.8547.ipd.pdf

    2024

  6. [14]

    A coordinated implementation roadmap for the transition to post-quantum cryptography, part 1, version 1.1,

    EU PQC Workstream, “A coordinated implementation roadmap for the transition to post-quantum cryptography, part 1, version 1.1,” Online, European Union, Jun. 2025, version 1.1. [Online]. Available: https://digital-strategy.ec.europa.eu/en/library/ coordinated-implementation-roa...

    2025

  7. [15]

    Migrating software systems toward post-quantum cryptography-a systematic literature review,

    C. N ¨ather, D. Herzinger, S.-L. Gazdag, J.-P. Stegh ¨ofer, S. Daum, and D. Loebenberger, “Migrating software systems toward post-quantum cryptography-a systematic literature review,”IEEE Access, vol. 12, pp. 132 107–132 126, 2024

    2024

  8. [16]

    Post-quantum cryptography (pqc) network instrument: Measuring pqc adoption rates and identifying migration pathways,

    J. Sowa, B. Hoang, A. Yeluru, S. Qie, A. Nikolich, R. Iyer, and P. Cao, “Post-quantum cryptography (pqc) network instrument: Measuring pqc adoption rates and identifying migration pathways,” in2024 IEEE Inter- national Conference on Quantum Computing and Engineering (QCE), vol...

    2024

  9. [17]

    Improving software quality in cryptography standardization projects,

    M. J. Kannwischer, P. Schwabe, D. Stebila, and T. Wiggers, “Improving software quality in cryptography standardization projects,” in2022 IEEE European Symposium on Security and Privacy Workshops (EuroS&PW), June 2022, pp. 19–30

    2022

  10. [18]

    Post-quantum key exchange for the internet and the open quantum safe project,

    D. Stebila and M. Mosca, “Post-quantum key exchange for the internet and the open quantum safe project,” inSelected Areas in Cryptography – SAC 2016, R. Avanzi and H. Heys, Eds. Cham: Springer International Publishing, 2017, pp. 14–37

    2016

  11. [20]

    Comparing the usability of cryptographic apis,

    Y . Acar, M. Backes, S. Fahl, S. Garfinkel, D. Kim, M. L. Mazurek, and C. Stransky, “Comparing the usability of cryptographic apis,” in2017 IEEE Symposium on Security and Privacy (SP), 2017, pp. 154–171

    2017

  12. [21]

    An empirical usability analysis of the google authentication api,

    C. Wijayarathna and N. A. G. Arachchilage, “An empirical usability analysis of the google authentication api,” inProceedings of the 23rd International Conference on Evaluation and Assessment in Software Engineering, ser. EASE ’19. New York, NY , USA: Association for Computing ...

    2019

  13. [22]

    Developers are not the enemy!: The need for usable security apis,

    M. Green and M. Smith, “Developers are not the enemy!: The need for usable security apis,”IEEE Security & Privacy, vol. 14, no. 5, pp. 40–46, 2016

    2016

  14. [23]

    “I’m pretty expert and I still screw it up

    J. Schm ¨user, P. Klostermeyer, K. Friedrich, and S. Fahl, “ “I’m pretty expert and I still screw it up”: Qualitative Insights into Experiences and Challenges of Designing and Implementing Cryptographic Library APIs ,” in2025 IEEE Symposium on Security and Privacy (SP). Los Al...

    2025

  15. [24]

    Using cognitive dimensions to evaluate the usability of security apis: An empirical investigation,

    C. Wijayarathna and N. A. G. Arachchilage, “Using cognitive dimensions to evaluate the usability of security apis: An empirical investigation,”Information and Software Technology, vol. 115, pp. 5–19, 2019. [Online]. Available: https://www.sciencedirect.com/science/ article/pii...

    2019

  16. [25]

    Software developers need help too! developing a methodology to analyse cognitive dimension-based feedback on usability,

    C. Wijayarathna, M. Grobler, and N. A. G. Arachchilage, “Software developers need help too! developing a methodology to analyse cognitive dimension-based feedback on usability,”Behaviour & Information Technology, vol. 40, no. 6, pp. 506–527, 2021. [Online]. Available: https://...

    2021

  17. [26]

    Module-Lattice-Based Key-Encapsulation Mechanism Standard,

    National Institute of Standards and Technology, “Module-Lattice-Based Key-Encapsulation Mechanism Standard,” Department of Commerce, Washington, D.C., Federal Information Processing Standards Publication NIST FIPS 203, 2024. [Online]. Available: https://doi.org/10.6028/ NIST.FIPS.203

    2024

  18. [27]

    Design and analysis of practical public-key encryption schemes secure against adaptive chosen ciphertext attack,

    R. Cramer and V . Shoup, “Design and analysis of practical public-key encryption schemes secure against adaptive chosen ciphertext attack,” SIAM Journal on Computing, vol. 33, no. 1, pp. 167–226, 2003. [Online]. Available: https://doi.org/10.1137/S0097539702403773

    2003 doi

  19. [28]

    A proposal for an ISO standard for public key encryption,

    V . Shoup, “A proposal for an ISO standard for public key encryption,” Cryptology ePrint Archive, Paper 2001/112, 2001. [Online]. Available: https://eprint.iacr.org/2001/112

    2001

  20. [29]

    Exploring Post- Quantum cryptography: Review and directions for the transition pro- cess,

    K. Cherkaoui Dekkaki, I. Tasic, and M.-D. Cano, “Exploring Post- Quantum cryptography: Review and directions for the transition pro- cess,”Technologies (Basel), vol. 12, no. 12, p. 241, Nov. 2024

    2024

  21. [30]

    Recommendations for Key-Encapsulation Mechanisms,

    G. Alagic, E. Barker, L. Chen, D. Moody, A. Robinson, H. Silberg, and N. Waller, “Recommendations for Key-Encapsulation Mechanisms,” National Institute of Standards and Technology, Special Publication 800-227, Sep. 2020. [Online]. Available: https://doi.org/10.6028/NIST. SP.80...

    2020 doi

  22. [31]

    Is usability an obstacle for information systems security?

    L. Zapata, A. M. Moreno, and E. Fernandez-Medina, “Is usability an obstacle for information systems security?” inProceedings of the 10th International Workshop on Security in Information Systems - Volume 1: WOSIS, (ICEIS 2013), INSTICC. SciTePress, 2013, pp. 53–65

    2013

  23. [32]

    Usable results from the field of api usability: A systematic mapping and further analysis,

    C. Burns, J. Ferreira, T. D. Hellmann, and F. Maurer, “Usable results from the field of api usability: A systematic mapping and further analysis,” in2012 IEEE Symposium on Visual Languages and Human- Centric Computing (VL/HCC), 2012, pp. 179–182

    2012

  24. [33]

    Api designers in the field: Design practices and challenges for creating usable apis,

    L. Murphy, M. B. Kery, O. Alliyu, A. Macvean, and B. A. Myers, “Api designers in the field: Design practices and challenges for creating usable apis,” in2018 IEEE Symposium on Visual Languages and Human- Centric Computing (VL/HCC), 2018, pp. 249–258

    2018

  25. [34]

    Usability implications of requiring parameters in objects’ constructors,

    J. Stylos and S. Clarke, “Usability implications of requiring parameters in objects’ constructors,” inProceedings of the 29th International Conference on Software Engineering, ser. ICSE ’07. USA: IEEE Computer Society, 2007, p. 529–539. [Online]. Available: https://doi.org/10....

    2007 doi

  26. [35]

    Improving api documentation usability with knowledge pushing,

    U. Dekel and J. D. Herbsleb, “Improving api documentation usability with knowledge pushing,” in2009 IEEE 31st International Conference on Software Engineering, 2009, pp. 320–330

    2009

  27. [36]

    Api usability peer reviews: a method for evaluating the usability of application programming interfaces,

    U. Farooq, L. Welicki, and D. Zirkler, “Api usability peer reviews: a method for evaluating the usability of application programming interfaces,” inProceedings of the SIGCHI Conference on Human Factors in Computing Systems, ser. CHI ’10. New York, NY , USA: Association for Com...

    2010

  28. [37]

    Measuring api usability,

    S. Clarke and Steven, “Measuring api usability,”Dr. Dobb’s Journal, vol. 29, pp. S6–, 05 2004

    2004

  29. [38]

    Improving api usability,

    B. A. Myers and J. Stylos, “Improving api usability,”Commun. ACM, vol. 59, no. 6, p. 62–69, May 2016. [Online]. Available: https://doi.org/10.1145/2896587 13

    2016 doi

  30. [39]

    Trustworthy software: lessons from ‘goto fail’ & heartbleed bugs,

    H. A. Boyes, P. Norris, I. Bryant, and T. Watson, “Trustworthy software: lessons from ‘goto fail’ & heartbleed bugs,” in9th IET International Conference on System Safety and Cyber Security (2014). Institution of Engineering and Technology, 2014

    2014

  31. [40]

    The matter of heartbleed,

    Z. Durumeric, F. Li, J. Kasten, J. Amann, J. Beekman, M. Payer, N. Weaver, D. Adrian, V . Paxson, M. Bailey, and J. A. Halderman, “The matter of heartbleed,” inProceedings of the 2014 Conference on Internet Measurement Conference, ser. IMC ’14. New York, NY , USA: Association ...

    2014

  32. [41]

    An empirical study of cryptographic misuse in android applications,

    M. Egele, D. Brumley, Y . Fratantonio, and C. Kruegel, “An empirical study of cryptographic misuse in android applications,” in Proceedings of the 2013 ACM SIGSAC Conference on Computer & Communications Security, ser. CCS ’13. New York, NY , USA: Association for Computing Mach...

    2013

  33. [42]

    ”jumping through hoops

    S. Nadi, S. Kr ¨uger, M. Mezini, and E. Bodden, “”jumping through hoops”: Why do java developers struggle with cryptography apis?” in 2016 IEEE/ACM 38th International Conference on Software Engineer- ing (ICSE), 2016, pp. 935–946

    2016

  34. [43]

    The most dangerous code in the world: validating ssl certificates in non-browser software,

    M. Georgiev, S. Iyengar, S. Jana, R. Anubhai, D. Boneh, and V . Shmatikov, “The most dangerous code in the world: validating ssl certificates in non-browser software,” inProceedings of the 2012 ACM Conference on Computer and Communications Security, ser. CCS ’12. New York, NY ...

    2012

  35. [44]

    Towards the usability evaluation of security apis,

    P. L. Gorski and L. Lo Iacono, “Towards the usability evaluation of security apis,” inClarke, Furnell (Eds.): Tenth International Symposium on Human Aspects of Information Security & Assurance (HAISA 2016), Frankfurt, Germany, July 19-21, 2016, 2016, pp. 252 – 265. [Online]. A...

    2016

  36. [45]

    You get where you’re looking for: The impact of information sources on code security,

    Y . Acar, M. Backes, S. Fahl, D. Kim, M. L. Mazurek, and C. Stransky, “You get where you’re looking for: The impact of information sources on code security,” in2016 IEEE Symposium on Security and Privacy (SP), 2016, pp. 289–305

    2016

  37. [46]

    Identifying research challenges in post quantum cryptography migration and cryptographic agility,

    D. Ott, C. Peikert, and other workshop participants, “Identifying research challenges in post quantum cryptography migration and cryptographic agility,” 2019. [Online]. Available: https://arxiv.org/abs/1909.07353

    2019 arXiv

  38. [47]

    Prototyping post-quantum and hybrid key exchange and authentication in tls and ssh,

    E. Crockett, C. Paquin, and D. Stebila, “Prototyping post-quantum and hybrid key exchange and authentication in tls and ssh,”IACR Cryptol. ePrint Arch., vol. 2019, p. 858, 2019. [Online]. Available: https://api.semanticscholar.org/CorpusID:198925340

    2019

  39. [48]

    Hybrid key encapsulation mechanisms and authenticated key exchange,

    N. Bindel, J. Brendel, M. Fischlin, B. Goncalves, and D. Stebila, “Hybrid key encapsulation mechanisms and authenticated key exchange,” inPost- Quantum Cryptography, J. Ding and R. Steinwandt, Eds. Cham: Springer International Publishing, 2019, pp. 206–226

    2019

  40. [49]

    Why johnny the developer can’t work with public key certificates,

    M. Ukrop and V . Matyas, “Why johnny the developer can’t work with public key certificates,” inTopics in Cryptology – CT-RSA 2018, N. P. Smart, Ed. Cham: Springer International Publishing, 2018, pp. 45–64

  41. [50]

    Why johnny can’t store passwords securely? a usability evaluation of bouncycastle password hashing,

    C. Wijayarathna and N. A. G. Arachchilage, “Why johnny can’t store passwords securely? a usability evaluation of bouncycastle password hashing,” inProceedings of the 22nd International Conference on Evaluation and Assessment in Software Engineering 2018, ser. EASE ’18. New Yor...

    2018 doi

  42. [51]

    Why johnny can’t develop a secure application? a usability analysis of java secure socket extension api,

    ——, “Why johnny can’t develop a secure application? a usability analysis of java secure socket extension api,”Computers & Security, vol. 80, pp. 54–73, 2019. [Online]. Available: https: //www.sciencedirect.com/science/article/pii/S0167404818304887

    2019

  43. [52]

    A methodology to evaluate the usability of security apis,

    ——, “A methodology to evaluate the usability of security apis,” in 2018 IEEE International Conference on Information and Automation for Sustainability (ICIAfS), 2018, pp. 1–6

    2018

  44. [53]

    A generic cognitive dimensions questionnaire to evaluate the usability of security apis,

    C. Wijayarathna, N. A. G. Arachchilage, and J. Slay, “A generic cognitive dimensions questionnaire to evaluate the usability of security apis,” inHuman Aspects of Information Security, Privacy and Trust: 5th International Conference, HAS 2017, Held as Part of HCI International...

    2017 doi

  45. [54]

    Api usability of stateful signature schemes,

    A. Zeier, A. Wiesmaier, and A. Heinemann, “Api usability of stateful signature schemes,” inAdvances in Information and Computer Security, N. Attrapadung and T. Yagi, Eds. Cham: Springer International Publishing, 2019, pp. 221–240

    2019

  46. [55]

    Chapter 2 - planning the study,

    B. Albert, T. Tullis, and D. Tedesco, “Chapter 2 - planning the study,” inBeyond the Usability Lab, B. Albert, T. Tullis, and D. Tedesco, Eds. Boston: Morgan Kaufmann, 2010, pp. 17–47. [Online]. Available: https: //www.sciencedirect.com/science/article/pii/B9780123748928000028

    2010

  47. [56]

    Van Someren, Y

    M. Van Someren, Y . F. Barnard, and J. A. Sandberg,The Think Aloud Method - A Practical Guide to Modelling CognitiveProcesses. Academic Press, 01 1994

    1994

  48. [57]

    Language choice in introductory programming courses at australasian and uk universities,

    Simon, R. Mason, T. Crick, J. H. Davenport, and E. Murphy, “Language choice in introductory programming courses at australasian and uk universities,” inProceedings of the 49th ACM Technical Symposium on Computer Science Education, ser. SIGCSE ’18. New York, NY , USA: Associati...

    2018

  49. [58]

    Quickstart - exequantum docs,

    Exequantum, “Quickstart - exequantum docs,” https://exequantum. gitbook.io/exequantum-docs/documentations/quickstart, 2025, accessed: November 9, 2025

    2025

  50. [59]

    Quantcrypt wiki,

    M. Aabmets, “Quantcrypt wiki,” https://github.com/aabmets/quantcrypt/ wiki, 2024, accessed: November 9, 2025

    2024

  51. [60]

    A practical guide to controlled experiments of software engineering tools with human participants,

    A. J. Ko, T. D. LaToza, and M. M. Burnett, “A practical guide to controlled experiments of software engineering tools with human participants,”Empir. Softw. Eng., vol. 20, no. 1, pp. 110–141, Feb. 2015

    2015

  52. [61]

    T test calculator — GraphPad QuickCalcs,

    GraphPad Software, LLC, “T test calculator — GraphPad QuickCalcs,” https://www.graphpad.com/quickcalcs/ttest1/, GraphPad Software, LLC, 2025, accessed: October 26, 2025. APPENDIXA EXAMPLE OFMISTAKE ONDOCUMENTATION Fig. 4. Mistake on PQ-Sandbox Documentation (Source: [58]). Fig...

    2025

  53. [2021]

    Available: http://dx.doi.org/10.22331/q-2021-04-15-433

    [Online]. Available: http://dx.doi.org/10.22331/q-2021-04-15-433

    2021 doi

Pith tools

Reviewed August 2, 2026 · model on record in the stance chip above.