Cryptography competitions often contribute to the development and standardization of new cryptography. They help select primitives and algorithms that solve specific cryptographic problems securely and efficiently from a list of candidate submissions. Over the last decades, several competitions held by NIST and other research and regulatory organizations resulted in standards for, e.g., symmetric and asymmetric encryption, hashing, digital signatures, and, most recently, quantum secure cryptography. However, while these competitions fostered much technical research on the submitted schemes, little is currently known about the human aspects of cryptography competition processes, how they shape the competition results, and their perceived impact on cryptography security.

Transparent reporting of research is a crucial aspect of good scientific practice and contributes to trustworthy science. Transparency helps to understand research processes, assess the validity of research contributions, and facilitates replication of studies and reported results. In the face of reproducibility crises in other fields, the security and privacy (SP) research community in general and the usable privacy and security (UPS) community in particular lack clear standards for transparent research reporting. To gain insights into current research transparency practices and associated challenges and obstacles in the UPS community, we report findings from 24 semi-structured interviews with UPS researchers. We find that researchers value research transparency and already apply several transparency reporting practices. However, an implicit community standard without incentives that outweigh challenges and drawbacks appears to prevent further advances in research transparency. Based on our findings, we conclude with recommendations for transparency practices and guidance for publication venues to better incentivize research transparency (e.g., adapting artifact evaluation to typical UPS artifacts like study materials) and to alleviate constraints that hinder transparency (e.g., removing page limits on appendices). We hope our findings can spur community discussion and effort to improve research quality through more transparent research reporting.

Cryptographic libraries are a vital security component of software systems, yet their misuse has caused several incidents. Prior work has established that misuse of cryptographic libraries is common, and developers struggle to use their APIs correctly. However, it is currently unknown how the design and implementation decisions that shape cryptographic library APIs are made. To investigate these decisions and associated challenges in the design and implementation process of cryptographic library APIs, we conducted 21 semi-structured interviews with experienced developers of cryptographic libraries and used thematic analysis to identify overarching topics and challenges they encountered. We find that design decisions span a spectrum of abstraction levels and are heavily influenced by cryptographic standards, other libraries, legacy code, and developers' intuitions. Developers are challenged by the optimal level of abstraction for cryptographic APIs to balance security, usability, and flexibility. They lack systematic knowledge on defining usability and achieving such balance. Consequently, developers rely on usability self-tests, personal experiences, and opinions. Based on our findings, we make detailed recommendations to tailor future research toward better empirically validated support of cryptographic library API design and implementation decisions. Further, we advocate for integrating research-based usability guidance into cryptographic standardization to foster community discussion early on and better support secure, usable, and flexible cryptographic library APIs.

The Russian Invasion of Ukraine in 2022 resulted in a rapidly changing cyber threat environment globally and incentivized the sharing of security and privacy advice on social media. Previous research found a strong impact of online security advice on end-user behavior.

Open source components are ubiquitous in companies’ setups, processes, and software. Utilizing these external components as building blocks enables companies to leverage the benefits of open source software, allowing them to focus their efforts on features and faster delivery instead of writing their own components. But by introducing these components into their software stack, companies inherit unique security challenges and attack surfaces: including code from potentially unvetted contributors and obligations to assess and mitigate the impact of vulnerabilities in external components.In 25 in-depth, semi-structured interviews with software developers, architects, and engineers from industry projects, we investigate their projects’ processes, decisions, and considerations in the context of external open source code. We find that open source components play an important role in many of our participants’ projects, that most projects have some form of company policy or at least best practice for including external code, and that many developers wish for more developer-hours, dedicated teams, or tools to better audit included components. Based on our findings, we discuss implications for company stakeholders and the open source software ecosystem. Overall, we appeal to companies to not treat the open source ecosystem as a free (software) supply chain and instead to contribute towards the health and security of the overall software ecosystem they benefit from and are part of.