Addressing the Risks of Misusing Crypto Librariesby@cryptosovereignty

Addressing the Risks of Misusing Crypto Libraries

tldt arrow

Too Long; Didn't Read

Crypto libraries often face misuse due to insecure block modes, non-random seeds, and other vulnerabilities. Understanding these common errors is crucial for developers to enhance application security and avoid potential threats.
featured image - Addressing the Risks of Misusing Crypto Libraries
Crypto Sovereignty Through Technology, Math & Luck HackerNoon profile picture


(1) Anna-Katharina Wickert, Technische Universität Darmstadt, Darmstadt, Germany ([email protected]);

(2) Lars Baumgärtner, Technische Universität Darmstadt, Darmstadt, Germany ([email protected]);

(3) Florian Breitfelder, Technische Universität Darmstadt, Darmstadt, Germany ([email protected]);

(4) Mira Mezini, Technische Universität Darmstadt, Darmstadt, Germany ([email protected]).

Abstract and 1 Introduction

2 Background

3 Design and Implementation of Licma and 3.1 Design

3.2 Implementation

4 Methodology and 4.1 Searching and Downloading Python Apps

4.2 Comparison with Previous Studies

5 Evaluation and 5.1 GitHub Python Projects

5.2 MicroPython

6 Comparison with previous studies

7 Threats to Validity

8 Related Work

9 Conclusion, Acknowledgments, and References


Crypto libraries enable developers to use crypto primitives, like symmetric key encryption or password-based encryption (PBE), in their application. However, studies have shown that developers struggle to use those APIs correctly and securely. For example, Krüger et al. [8] show that 95 % of the Android applications using crypto have at least one crypto misuse. In the remainder of the paper, we define a crypto misuse, in short misuse, as a usage of a crypto library which is a formally correct use of the API, e.g., not causing a crash, but is unsafe. In this paper, we focus on six commonly discussed crypto misuses [4, 13] which we will introduce next.

For AES encryption, a block mode is used to combine several blocks for encryption and decryption. However, some block modes are considered insecure by experts. Rule 1 (§1) and rule 2 (§2) cover two insecure usages of block modes. §1 prohibits the usage of ECB which is deterministic and not secure. §2 focus on a nonrandom initialization vector (IV) for the block mode CBC. Due to the predictability of the IV, the usage of CBC is deterministic and not secure. Further, a key protects confidential information. Thus, rule 3 (§3) states that the key should be confidential and not a static one hard-coded in the source.

For PBE, a salt and the number of iterations harden the password against dictionary attacks. Rule 4 (§4) highlights that a non-random salt reduces the security of the crypto primitive to using no salt, which is considered insecure. Rule 5 (§5) concentrates on the fact that several iterations are required to harden the crypto primitive against attacks. Thus, Egele et al. [4] suggest the minimum recommended value of 1,000 iterations as defined in the PBE standard PKCS#5.

A seed can ensure that the output of a random number generator is non-deterministic. Rule 6 (§6) covers that static seeds lead to deterministic outputs. Common Java [4] and C/C++ [13] libraries expect a seed, while the analyzed Python APIs avoid this by design.

This paper is available on arxiv under CC BY 4.0 DEED license.