3 ms·
Yes, the sources are difficult to read at best. The documentation for the public APIs is not much better either. For example, the suggestion at this page: http
by jschwartzi 11y ago
Yes, the sources are difficult to read at best. The documentation for the public APIs is not much better either.
For example, the suggestion at this page: https://www.openssl.org/docs/crypto/sha.html https://www.openssl.org/docs/crypto/sha.html to use the higher-level EVP_ functions was difficult to actually adhere to, given that the EVP_ functions themselves don't actually explain how to generate a message digest given some input data. I wasted half a day once trying to understand how those functions worked once before giving up and just using the digest functions directly. It's still not clear to me why the EVP functions provide a significant advantage, or even how I would use them to accomplish the use cases outlined in the digest functions.
I suspect that not understanding the OpenSSL APIs is a common problem, and possibly an underlying cause of a lot of crypto implementation errors.
- viraptor 11y ago> It's still not clear to me why the EVP functions provide a significant advantage In case of EVP_... your code is not hardcoding the hash type. You can provide the hash by its name in the config file without any code changes in the app. When using hash contexts directly, you're stuck with what you implement.
- jschwartzi 11y agoThat's what I figured when I implemented it. In my application I'm fine hardcoding the hash type because if we have to change hashes away from SHA-2 we have to update all of the equipment in the field anyway, so we might as well update the software at the same time. E: It also helps that the code with the hardcoded hash type is much easier to understand than the equivalent EVP code.