Developing your own cryptographic solutions (advanced)¶

Challenges of developing your own solutions¶

In this module, algorithms have been discussed in a versatile but fairly abstract manner. Some details have also been revealed, and hopefully enough implementation-related information has been presented that the reader will not yet feel tempted to independently implement cryptography for any real system, even via a crypto API. Apparently many try, and some well-known approaches to achieving “secure” cryptography are the “meat grinder”, “large keys”, and “friendly analysis”. The kitchen analogy refers to designs that may use known components, but in any case apply “enough” modules and rounds to ensure that bits are thoroughly mixed. Similarly, a large key space at least prevents brute-force attacks, but like the grinder it also degrades performance. Friendly analysis means that an algorithm or protocol is not subjected to scrutiny by the scientific or technical community, so vulnerabilities remain hidden. Submitting a contribution to cryptographic conferences or similar venues would, however, be a waste of time for both the author and reviewers, as achieving improvements or creating something new is highly unlikely without training in cryptology and familiarity with recent research developments.

Addressing the challenges¶

The learning objective of this module has been to understand cryptography, so what is the point if, by further developing one’s skills, one could not also proceed to implement cryptographic solutions? There would certainly be demand for that. If you have read this far, the answer to that question has likely already become clear. Instead, let us consider how to avoid unnecessary and insecure in-house solutions.

First, the core algorithms are currently sufficiently secure for the foreseeable future, and crypto APIs provide good implementations of them. These points have already been noted above. Where can expertise be obtained when cryptography must nevertheless be implemented in a company’s product?

If in-house knowledge is limited, a professional with demonstrated expertise should be hired. A lower level of commitment can be achieved by consulting companies that provide such services. Their reputation should also be assessed in advance, for example through references from previous clients.

If the company already employs a cryptologist, they can further develop their expertise through publications, provided these are of sufficient quality. The cryptography section of StackExchange is extensive, but it can be difficult to distinguish reliable advice there. Wikipedia contains a large amount of material on cryptography and can serve as a useful resource for further study after this course, before moving on to more advanced courses. Even with academic publications, source criticism should be applied.

Large companies should establish a team of cryptographic professionals who participate in implementation and at least review all cryptography-related aspects of the company’s products.

A company may also obtain cryptography as a service, following the same principle as software-as-a-service solutions. While software solutions are widely available as SaaS cloud services, a more recent concept is CaaS, Cryptography as a Service. This can be particularly important in implementing key management. It may also be significantly more secure than what a small company could achieve on its own, especially if a provider-managed HSM is used.

Making cryptography invisible to the user¶

In the design of information systems, it should be ensured that users do not need to choose cryptographic parameters—particularly whether to encrypt a connection or whether to accept a connection to a server whose certificate is invalid. Handling such cases sometimes appears to require accepting weaker security, but in such situations, the tool used (e.g. a web browser or messaging application) should prevent the handling of sensitive data. This is not yet common in consumer applications, but it could represent a compromise compared to blocking the connection entirely. Email filtering already provides an example, although the distinction is made between “spam–ham” (i.e. junk is removed) rather than between “ham–caviar” (i.e. valuable data would not be sent unencrypted). In companies, DLP applications are already used to automatically restrict the movement of sensitive data. The key idea is that cryptographic protection should be the default in all situations, and users should not need to verify that it is active. Only deviations would be visible, and if allowed, the user would effectively be “turning off the lights” while being aware that they are proceeding in the dark.