A cryptographic protocol combines cryptographic mechanisms into a practical exchange that protects information or systems against adversaries. It can provide confidentiality, authentication, or integrity, depending on the problem and design. section 1.1
Choose a protocol by starting with the threat and the service required:
- Encrypt unprotected traffic with TLS or Noise. section 16.1
- Authenticate servers with a public key infrastructure and certificate-authority signatures. section 16.1
- Distribute a secret with a threshold scheme so one compromised secret does not compromise the whole system. section 16.1
- Prefer established, scrutinized protocols over exotic designs; complexity creates opportunities for vulnerabilities. section 16.1
From an exposed connection to a conservative choice
Suppose traffic is unencrypted. The practical response is not to invent a new algorithm, but to identify the required protection and select an existing protocol such as TLS or Noise. If servers also need mutual trust, add an established authentication arrangement rather than casually composing primitives. section 16.1 section 1.8
Figure 1.16 The ideal life cycle for a cryptographic algorithm starts when cryptographers instantiate a concept in a white paper. For example, AES is an instantiation of the concept of symmetric encryption (there are many more symmetric encryption algorithms out there). A construction can then be standardized: everybody agrees to implement it a certain way to maximize interoperability. Then support is created by implementing the standard in different languages.
Follow the lifecycle from a cryptographic concept, to an instantiated construction such as AES, to standardization and implementations that improve interoperability. section 1.7
