On OpenSSL's EVP API
Ropponen, Miko (2020)
Ropponen, Miko
2020
Tieto- ja sähkötekniikan kandidaattiohjelma - Degree Programme in Computing and Electrical Engineering, BSc (Tech)
Informaatioteknologian ja viestinnän tiedekunta - Faculty of Information Technology and Communication Sciences
This publication is copyrighted. You may download, display and print it for Your own personal use. Commercial use is prohibited.
Hyväksymispäivämäärä
2020-05-24
Julkaisun pysyvä osoite on
https://urn.fi/URN:NBN:fi:tuni-202004294634
https://urn.fi/URN:NBN:fi:tuni-202004294634
Tiivistelmä
This paper examines OpenSSL’s EVP API, focusing on its usability and how to perform cryptographic operations using it. The usability of cryptographic APIs is an interesting topic, as usability problems will often lead to security problems as well, due to incorrect use of the API. Incorrect usage of security APIs has already led to significant data breaches. Yet, sometimes the security of even a non-security API might require trade-offs in its usability, leading to a contradiction of interests in API design, especially so for security APIs such as EVP.
Other cryptographic library APIs are also evaluated on their usability, namely NaCl, Libsodium and Nettle. The four APIs mentioned in this abstract are then compared to each other, not to find the “best” one out of them on any scale, but rather to analyse their similarities and differences. The usability evaluation relies on documentation available for these APIs. The analysis is done by evaluating the APIs based on Jacob Nielsen’s “heuristic evaluation” guidelines for analysing the usability of general user interfaces, mapped to API usability assessment by Brad A. Myers and Jeffrey Stylos, with some further mapping done in this paper to take into account the security nature of the APIs assessed.
Comparison of the usability of the APIs found that all of the APIs satisfy the assessment guidelines rather well, with only minor problems found. Considering the cryptographic nature of the APIs, an argument for many of these guideline contradictions could be made. A big difference could be found in the flexibility of the APIs, that is, the amount of features the API provides. These features include the available cryptographic primitives to perform operations with. A part of this difference could be explained by the level of abstraction the API provides, and also by their different design strategies, where some of the libraries (NaCl and Libsodium) argue that it is better to simply provide the most secure cryptographic primitive. Nettle and EVP take a different approach, providing a wide range of different cryptographic primitives, allowing the libraries to be used in a wider range of contexts. Similarities include the usage of sane defaults in all of the APIs, made evident by the fact that the default usage for each of the APIs works without much set-up of options etc. Another similarity is the fact that due to the libraries being written in C-programming language, the parameter lists for the methods available tend to grow rather large, which goes against one of the evaluation guidelines. This is mainly caused by the fact that the length of the input and output have to be passed along with the actual input and output, which would not be a problem in a higher-level programming language such as C++. This alone is not really an argument for writing the APIs in C++, though.
Further examination of EVP’s public-facing API is also done This paper does not go into the specific technical implementation details of EVP. Rather, this paper goes over how to perform the core cryptographic operations of asymmetric encryption, symmetric encryption and message digests using EVP. Despite the fact that EVP is written in C, which does not support object-oriented programming, the library internals are driven by function pointers, making some of the details of EVP resemble objects, such as the context- and method-structures used to perform the operations.
.
Other cryptographic library APIs are also evaluated on their usability, namely NaCl, Libsodium and Nettle. The four APIs mentioned in this abstract are then compared to each other, not to find the “best” one out of them on any scale, but rather to analyse their similarities and differences. The usability evaluation relies on documentation available for these APIs. The analysis is done by evaluating the APIs based on Jacob Nielsen’s “heuristic evaluation” guidelines for analysing the usability of general user interfaces, mapped to API usability assessment by Brad A. Myers and Jeffrey Stylos, with some further mapping done in this paper to take into account the security nature of the APIs assessed.
Comparison of the usability of the APIs found that all of the APIs satisfy the assessment guidelines rather well, with only minor problems found. Considering the cryptographic nature of the APIs, an argument for many of these guideline contradictions could be made. A big difference could be found in the flexibility of the APIs, that is, the amount of features the API provides. These features include the available cryptographic primitives to perform operations with. A part of this difference could be explained by the level of abstraction the API provides, and also by their different design strategies, where some of the libraries (NaCl and Libsodium) argue that it is better to simply provide the most secure cryptographic primitive. Nettle and EVP take a different approach, providing a wide range of different cryptographic primitives, allowing the libraries to be used in a wider range of contexts. Similarities include the usage of sane defaults in all of the APIs, made evident by the fact that the default usage for each of the APIs works without much set-up of options etc. Another similarity is the fact that due to the libraries being written in C-programming language, the parameter lists for the methods available tend to grow rather large, which goes against one of the evaluation guidelines. This is mainly caused by the fact that the length of the input and output have to be passed along with the actual input and output, which would not be a problem in a higher-level programming language such as C++. This alone is not really an argument for writing the APIs in C++, though.
Further examination of EVP’s public-facing API is also done This paper does not go into the specific technical implementation details of EVP. Rather, this paper goes over how to perform the core cryptographic operations of asymmetric encryption, symmetric encryption and message digests using EVP. Despite the fact that EVP is written in C, which does not support object-oriented programming, the library internals are driven by function pointers, making some of the details of EVP resemble objects, such as the context- and method-structures used to perform the operations.
.
Kokoelmat
- Kandidaatintutkielmat [8780]