Cryptography Basics¶
Cryptography is a tool for protecting data, verifying identity, and binding keys to identities. It is powerful, but easy to misuse. The safest approach is usually: use well-reviewed libraries, choose standard constructions, and avoid inventing your own protocols.
This cheat sheet is defensive and educational. It explains concepts and safe use, not how to break or weaponize cryptography.
The Main Goals¶
| Goal | What it means |
|---|---|
| Confidentiality | Only authorized parties can read the data |
| Integrity | The data has not been altered unexpectedly |
| Authentication | You have assurance about the source or identity |
| Non-repudiation | An action can be associated with an actor in a way that is hard to deny |
Different constructions help with different goals. A hash helps integrity. Encryption helps confidentiality. Signatures help authentication and non-repudiation.
Hash Functions¶
A cryptographic hash turns an arbitrary input into a fixed-size output designed to be:
- Deterministic
- One-way
- Resistant to collisions and preimage attacks (in a good hash)
Good uses: - Verifying file integrity - Commitment schemes - Building message authentication codes - Storing password verifiers in a hashed form with appropriate strengthening
Bad uses: - Using a fast hash alone for passwords - Assuming a hash is encryption - Relying on "secret by obscurity" instead of a real construction
Common modern choices for general integrity include SHA-256 and similar. For password verification, use a dedicated password hashing function, not a plain hash.
Password hashing¶
Passwords need more than a hash. They need a slow, salted, work-factor-protected password hashing function.
Good practice: - Use a purpose-built password hasher. - Use a unique salt per password. - Tune work factors for the environment. - Compare stored verifiers, not raw passwords.
Bad practice: - Storing passwords in plaintext. - Using a single fast hash like SHA-256 without strengthening. - Reusing salts. - Rolling your own password storage.
Symmetric Encryption¶
Symmetric encryption uses the same secret key for encryption and decryption.
It is efficient and widely used for bulk data protection.
Key ideas: - Use an authenticated encryption mode when you need both confidentiality and integrity. - Use a unique nonce or IV where required. - Do not reuse keys and nonces in the wrong way for the same key. - Protect the key as carefully as the data.
A common mistake is to encrypt data but not protect its integrity, then trust the decrypted output. If an attacker can modify ciphertext, the decrypted result may be corrupted or abused depending on the scheme.
Practical rules¶
- Use standard authenticated encryption constructions from a reputable library.
- Do not design your own mode.
- Never hardcode keys in source code.
- Do not store keys next to the data they protect without a real access-control reason.
- Rotate keys when exposure is suspected or when policy requires it.
Asymmetric Encryption¶
Asymmetric cryptography uses a key pair: one key is private, the other is public.
Common uses: - Encrypting to a public key, decrypting with the private key - Key exchange - Digital signatures - Supporting TLS and other protocols
Important concept: the public key can be shared, but the private key must stay private. If the private key is compromised, the security properties that depend on it can collapse.
Asymmetric operations are usually slower than symmetric ones, so they are often used for key establishment and signing rather than encrypting large volumes of data directly.
Digital Signatures¶
A digital signature is a cryptographic proof that a message or object was signed by the holder of a private key, and that it has not been altered since signing.
Uses: - Verifying software or artifacts - Signing configurations, models, datasets, or pipeline outputs - Authenticating messages in protocols - Supporting certificates and trust chains
Key points: - Sign what you mean to sign. - Verify signatures before trusting signed content. - Protect private signing keys. - Do not treat a signature as a guarantee of goodness; it is a guarantee of origin and integrity, not of safety or correctness.
For AI and data pipelines, signatures are especially useful for things like model artifacts, dataset versions, and deployment configurations.
HMAC¶
A keyed-hash message authentication code combines a hash function with a secret key to provide integrity and authenticity for a message.
Use it when you need to verify that a message came from someone who knows the shared key and has not been tampered with.
Important: - Use the HMAC construction, not "hash with a secret appended" improvisation. - Keep the key secret. - Do not use the same key for unrelated purposes without understanding the implications. - HMAC is not the same as encryption.
Public Key Infrastructure and Certificates¶
A certificate binds a public key to an identity and is signed by a certificate authority or another trust anchor.
Why certificates matter: - They help a client or server decide whether a public key belongs to the party it thinks it is talking to. - They support TLS and other trust-on-the-network workflows.
Practical points: - Validate certificates appropriately. - Check expiration. - Keep private keys for certificates secure. - Understand the trust chain. - Do not skip validation "to make testing easier" and then leave it that way.
Key Management¶
Key management is where many systems succeed or fail.
Good practices: - Generate keys with a suitable source of randomness. - Store keys securely and separately from the data when possible. - Control access to keys. - Rotate keys according to policy. - Revoke or replace keys if compromise is suspected. - Backup keys carefully, with the same security as the keys themselves. - Track versions and avoid accidental key reuse across purposes.
Bad practices: - Hardcoding keys in code or config. - Checking keys into version control. - Sharing one key across many unrelated services. - Leaving expired or unused keys lying around without review. - Assuming a key is safe because it is in a file no one looks at.
Randomness¶
Cryptography depends on unpredictability.
- Use a cryptographically secure random source for keys, tokens, nonces, salts, and similar values.
- Do not use predictable seeds.
- Do not assume everyday randomness is sufficient for security-sensitive purposes.
- Test and configure environments so the right random source is available.
A weak random source can undermine keys, tokens, sessions, and more.
Common Constructions and What They Are For¶
| Construction | Typical purpose |
|---|---|
| Hash | Integrity check, fingerprinting, commitment, input to other constructions |
| Password hash | Secure password verification |
| Symmetric encryption | Bulk confidentiality, often with authentication |
| HMAC | Integrity and authenticity with a shared key |
| Asymmetric encryption | Encrypting to a public key or key exchange |
| Digital signature | Origin verification and integrity for signed objects |
| Certificates | Binding public keys to identities with trusted signatures |
Each tool has a job. Using the wrong tool for the job is one of the most common crypto mistakes.
What Cryptography Does Not Do¶
- It does not fix bad access control.
- It does not make unsafe code safe.
- It does not prevent social engineering.
- It does not protect data after it is decrypted for use.
- It does not solve key management for you.
- It does not make a bad design secure just because encryption is involved.
Encryption is one layer. If the surrounding system is weak, encryption alone will not save it.
A Simple Decision Flow¶
- What am I protecting? Confidentiality, integrity, authentication, or all three?
- Who needs to verify or decrypt? One party, many parties, a shared secret, or a key pair?
- Where is the key material stored and controlled?
- Am I using a standard library and construction?
- Is there a safer, higher-level API that already does what I need?
If the answer to 4 is "no," pause and reconsider. Most applications should not build crypto from primitive operations unless they have a very good reason and strong review.
Pitfalls to Avoid¶
- Using encryption without authentication when you need both.
- Reusing keys across different purposes without understanding the effect.
- Hardcoding or committing secrets.
- Using deprecated algorithms or modes because they are familiar.
- Building password storage from generic hashes.
- Skipping signature verification because "it came from inside."
- Assuming randomness is secure without checking.
- Treating crypto as a substitute for access control or secure design.
Related Cheat Sheets¶
- cybersecurity-fundamentals — the broader security mindset
- network-security-basics — TLS and certificates in context
- owasp-basics — where crypto failures show up in web applications
- linux-security — protecting keys and secrets on a server
- python-testing — test crypto-adjacent logic carefully
- fastapi — TLS, auth, and validation in a common Python service
Official and Practical References¶
- Use the documentation for the cryptographic library you actually use.
- Prefer high-level APIs that handle nonce/IV, authentication, and formatting for you.
- Consult current guidance for password hashing, key sizes, and algorithm choices, because recommendations change over time.
- When in doubt, choose a small number of well-supported, modern primitives and avoid custom designs.
If a construction sounds clever and unusual, that is usually a reason to be cautious, not excited.
Last Updated¶
2026-09-06 — Initial version.