Security is in high demand these days. Any hacker will tell you that they don’t touch cryptographic schemes to break them, they simply look for misuses of them. And who’s not afraid of hackers today? It means that there are lots of misuses and a need for control and maintenance.
Instead of spending time with safety, i.e. inherent dangers for their products, application developers have to deal with security, i.e. intelligent attacks on their products. Developers map their features to cryptographic schemes and started using them, then cryptographers came aboard to help them.
Concepts like confidentiality, authentication, data integrity, authorization, privacy, non-repudiation, etc. are common and they’ve become sine qua non features. Cryptography is the major tool used to achieve them, though others are available, e.g., multi-party computation, HSMs, TEE, etc., for it is meant to hide information, completely or partially, as the first half of its name says.
What is the solution?
The best solution for developers is to separate the application from the cryptographic selection and implementation and leave it to cryptographers. An example is the HSMs, which physically separates cryptography from the application.
In a good cryptographic process, the use of the cryptographic schemes is materialized with an API+ provider architecture. The API has to be a real abstraction of the cryptographic schemes, not only of their implementations. The API has to release the application from deciding what cryptography to use. At this level, we’ll see API Hash(message, length, hash) and nothing more. The function API Hash() gets the provider and retrieves the hash function registered with that provider. Developers use the API and the cryptographic library, and the cryptographers build and deploy providers. The application becomes ’agile’ and oblivious of the schemes and implementations.
However, developers and cryptographers can look at the same object and have different views. For instance, when looking at ECDSA SHA256 SECP256R1, developers will see that it is ECDSA signature scheme using the hash SHA256 and the curve SECP256R1, whereas the cryptographers will see the same plus an PRNG which they want to know about and a source of entropy for seeding the PRNG which they want to know about too. The mentioned architecture removes one view and keeps the other. There is a common ground, but crossing it is not straightforward.
Takeaways
Security changes are happening more often than before—the post-quantum season is approaching. The tsunami of SHA2 drowning SHA1is still in our memory. Applications recovered, but with enormous effort. We don’t want this to happen again. Keeping stable common ground is essential and ‘agility’ is the word nowadays.
A good process for application developers is to keep using API provided by the cryptographic library and let the implementation decide how/when/what/why to be changed by cryptographers.
