1 Cryptography Foundations and Security Goals
Learn how cryptographic mechanisms support distinct security goals, how threat models guide their selection, and how to use keys, primitives, and libraries safely.
Cryptography and its security goals
Cryptography uses mathematical algorithms and keys to protect information and verify claims about it. Its value depends not only on selecting a sound algorithm, but also on matching the mechanism to a security goal, making realistic assumptions about attackers, and using cryptographic software correctly.
The goals are related but distinct. Encryption alone does not necessarily detect tampering; a digital signature does not conceal a message; and a does not prove who created the data. Choose objectives according to the information and system being protected.
Build a
A describes what needs protection, from whom, and under what assumptions. It helps determine whether a cryptographic control addresses the actual risk. Identify the following:
Assets: Examples include customer records, account credentials, signing keys, and service .
Adversaries and capabilities: Consider someone who steals a laptop, reads network traffic, submits malicious requests, or gains access to a database. State what the attacker can observe, alter, or control.
Trust boundaries and exposures: Identify where data is stored or transmitted, which services can access it, and where secrets or keys are handled.
Security goals and constraints: Specify what must remain confidential or detectably unchanged, who must be authenticated, and any performance or recovery requirements.
Assumptions and residual risk: Record protections supplied by operating systems, cloud services, or other components, along with what remains unprotected.
For example, encrypting a web application's database may reduce harm if an attacker obtains a database backup but not the decryption key. It may not protect documents if the attacker compromises the running application, which can access both the data and the keys. If a user can also change stored documents, encryption must be paired with protection. This example shows why the model must include key location and application behavior, not just the cipher. Risk assessment also examines threat sources and events, vulnerabilities, assumptions, and potential impacts.
Core cryptographic terms
Plaintext and ciphertext are the readable input and the transformed output of encryption, respectively. A key is secret or private cryptographic material that controls an operation. A public key may be shared, while its corresponding private key must be protected. Different keys serve different purposes, such as encryption, signing, or key establishment.
A is a fixed-length digest computed from data. A secure is designed to make it impractical to find an input matching a chosen digest or two inputs with the same digest. Hashing is not encryption: it does not use a decryption key to recover the original data.
A is a non-secret, usually unique value added when hashing a password. It makes identical passwords produce different stored results and frustrates precomputed lookup attacks, but it does not make a weak password strong.
A is used by some encryption schemes. It usually need not be secret, but it must meet the algorithm's requirements; often, it must never be reused with the same key. An is a short value produced by authenticated encryption or a MAC. Verification should fail if protected data or associated metadata has been altered.
A is a digitally signed document that binds a public key to an identity or name under an issuing authority's rules. It is not the private key and does not, by itself, prove that a particular person controls that key at the moment of use.
Use cryptographic libraries safely
Use a maintained, well-reviewed library and its high-level APIs rather than writing algorithms, protocols, padding, or random-number generators yourself. Choose a standard construction that directly fits the task. For ordinary data encryption, , such as a library-supported AES-GCM or ChaCha20-Poly1305 API, provides and tamper detection together.
Handle failures as failures. Do not use plaintext from a message whose did not verify. Follow the library's rules for key and nonce generation, storage, and reuse. For AEAD, never reuse a nonce with the same key where the construction forbids it; violating this requirement can seriously undermine security. Treat nonce requirements as part of the design, not as an implementation detail to guess.
Choose primitives and manage keys
Use the primitive suited to the task. Store passwords with a password-hashing function, not general-purpose encryption or a fast ordinary . Use a MAC or digital signature when authenticity or tamper detection is required. When relying on public keys, validate certificates and names.
Generate keys with a cryptographically secure random generator. Keep keys separate from the protected data when practical, restrict access to them, and plan how to rotate, back up, and retire them. Keep cryptographic dependencies updated, check return values and verification results, and avoid exposing secrets through logs, source control, or error messages.
Standard algorithms cannot compensate for stolen keys, incorrect validation, weak access controls, or a compromised endpoint. Cryptographic controls should therefore be chosen from a clear : no single primitive provides , , , and all at once.