Cryptographic Lessons in Trust blogCryptography forms the basis of much of our digital infrastructure and the services built around that infrastructure. Whether it be about accessing mobile phone networks, our online or ATM accessed bank accounts, paying for something online, or the task of passing through automated passport control devices at airports —  the list of how we authenticate without thought is quite literally endless. However, in this day and age of heightened security, why do we inherently put trust in these services?

There are many reasons as to why we inherently trust these services – and the most common is that we trust the provider to protect us and our assets without questioning what authentication methods are actually being used or if cryptography is part of the security equation.  Cryptography enables us to prove that someone is who they say they are, by engaging in an identification protocol to prove that an entity actually holds a given secret.

Additionally, cryptography enables us to secure communication from eavesdroppers. It enables us to verify a web site via a digital certificate, to verify a passport using a digital signature, or to verify a bank card using a challenge-response mechanism.

With that in mind, how do we trust cryptography in the first place without a true understanding of what it is? Everything seems to rest on the trust of this one part of the technology stack.

Well, there are various ways we ensure trust is guaranteed in cryptographic operations. Among others:

  1. Trust in the algorithm: Cryptographic algorithms are only deployed in major systems after they have gone through a stringent process of research, analysis, and validation. The most famous examples of this type of process are the NIST competitions for developing AES and SHA-3, as well as the ongoing effort in developing post-quantum public key algorithms also being run by NIST. Standards bodies, such as NIST, IETF, ISO etc. give companies confidence that algorithms have been sufficiently analyzed before they are deployed. One should never trust algorithms being pushed by companies which have not been analyzed in the public community.
  2. Trust in the implementation: There is an often-mentioned mantra when cryptographers give advice to industry and that is “Do not roll your own crypto.” In other words, you should always use software from reputable sources. If it is open source software, it should be software which has been examined by many experts, and which is in an active patch lifecycle. Cryptographic software can have many problems which reduce trust. For example, good code will be written to be constant time, to leak no information via side-channels (if implemented on a remote device). For mission critical services companies use software which has gone through a strict validation process, for example the NIST FIPS validation process or Common Criteria.
  3. Trust in the key: By having publicly analyzed algorithms and publicly analyzed code we end up with only having to place trust in the key. Which is exactly what the most famous of Kerckhoffs’s Principles (stated in 1883) states; namely that the security should rest solely on the secrecy of the secret key.

There are many ways to secure cryptographic keys so that only valid users have access to the keys. Examples include secure storage on devices such as USB keys and smart cards. For large corporate instantiations one may rely on Hardware Security Modules (HSMs) or use the modern techniques of multi-party computation (MPC) to split the key into different geographic locations.

In summary, if you adopt cryptographic best practices of using well-studied algorithms, and well-studied software libraries, then you can trust most digital services since they are based on trusted cryptography. Here, the root of that trust is the secure control of cryptographic keys. Thus, security and trust of complex systems is reduced to the simpler problem of security and trust of cryptographic keys.