Seven themes on what directly protects data in each state: what are primitive and whose problem each solves, how data is protected on disk, network and during processing, how keys are managed and what changes with post-quantity standards.
Data Life Cycle
There is no point encrypting the disk if the same data travels over the network without TLS, and there is no point in TLS if the backup is lying open. Protection is planned for all three conditions, not one.
This is a control that transfers risk from data to keys. If the key is stored next to encrypted data, the risk is not reduced, only shifted.
Confidentiality (nobody else reads), integrity (nobody changes unnoticed), authenticity (known who sent). Encryption itself gives only the first.
The cryptographic code itself is written. Algorithms are public and checked; vulnerabilities arise in implementation: the weak random source, the re-used noncirculation (in a single number, which should not be used twice) or the time of leakage (after how long the check takes place, you can guess the mystery).
Building blocks
The priority is the basic block of cryptography - one operation with one task. No block delivers everything: encryption hides content, but does not prove who sent it; signature proves sender, but content does not hide. That's why they put them together in systems.
Choose a way and go through the steps. The middle bar shows what the attacker, who listens to the net, sees on the way.
Both agree on one common key K. This is the weak point: how to transfer it if the channel is not yet secure?
Alise encrypts a message with key K. The result is an incomprehensible code.
The attacker sees in the network: x7#Qp9... an incomprehensible chiff
The code goes on the net. The attacker sees it, but without K can't read it.
Bob decodes with the same key K.
Therefore, the common key is transferred by asymmetric cryptography - the next example.
Bob makes a pair of keys. Private S doesn't give anyone.
The attacker sees in the network: public key P - it's no secret
Bob sends Alice his public key. The attacker sees it, but it can only be locked, not unlocked.
Alise encrypts a message with Bob's public key P.
The attacker sees in the network: k2!Vz8... - a chiff that can only be unlocked by S
The code goes on the net. The attacker has P, but P cannot turn this chiff off.
Bob deciphers with his private key S - it's just for him.
Asymmetric is slow, so it safely transmits K, and the data goes with the fast symmetrical - it starts TLS.
The publisher calculates the fileprint and publishes it on his website.
The attacker sees in the network: the file - and can replace it with his
The file goes over the network or through a mirror server. The attacker can replace it.
The user himself calculates the printout of the received file.
If the attacker changed the file, the print would be completely different. But the imprint must come from a reliable source - otherwise the attacker replaces it.
The attacker sees in the network: nothing - the connection is encrypted (TLS)
On registration, the user sends the password through an encrypted connection.
The password is not stored by the server. It only stores salt and results obtained with deliberately slow function.
The attacker sees in the network: nothing - the connection is encrypted
When the user applies, he sends the password again.
The server repeats the calculation and compares. Match - password correct.
Each guess costs ~0.1 s, and due to salt the same passwords look different - billion guesses become years.
Both sides previously have one common key K.
The sender calculates the check code from the message and key.
The attacker sees in the network: the news openly and the code - the content of the MAC is not hidden
The message goes with the code. The attacker can change '10 €' to '1000 €', but without K the correct code cannot be created.
The recipient himself calculates the code and compares. If the message is changed, the codes do not match and the message is rejected.
The publisher creates a pair of keys. Public P is published (e.g. on a certificate), private S is kept in a secure place.
The publisher signs the file with his private key S.
The attacker sees in the network: file and signature - both no secret
File goes with signature. The signature does not hide content - it proves origin.
Everyone checks with the publisher's public key P. Valid - the file has not been changed and it was signed by the S holder.
Unlike the MAC check can anyone, but only sign the private key holder.
One common key: with the same lock and unlock.
Text common key Encryption same key Text
AES-256-GCM, ChaCha20-Poly1305Key pair: public may know everyone, private only recipient. With public lock, unlock can only with private.
Text public Encryption private beneficiary Text
X25519, RSA-3072, ECDH P-256Converts data of any size into a short "fingerprint." Back data cannot be derived from it, and the smallest change gives a completely different footprint.
File, any size SHA-256 64-character imprint
SHA-256, SHA-3, BLAKE2Special, consciously slow mixing function for passwords. Add salt (salt) - an incidental value that is different for each password - and the cost of working factors that determine how slowly it works.
Password salt Argon2id, slow Value to be stored
Argon2id, scrypt, bcryptBoth sides have one common key. The sender adds a check code to the data, the recipient calculates it again and compares - if the data is changed, the code does not match.
Data common key Data + code same key match/non-match
HMAC-SHA256 (AES-GCM included in encryption)Signed with a private key, checked by public. It shall be demonstrated that the data have not been changed and that they have been signed directly by the private key holder.
Document signatory private Document + signature signatory public valid/ invalid
Ed25519, ECDSA, RSA-PSSIt works at TLS: asymmetrically negotiates a common key, the digital signature on the server certificate proves that the server is the right one, and the symmetrical (AEAD) encryption of data and at the same time checking that it has not been changed.
AES-256-GCM or ChaCha20-Poly1305 - they encrypt and check at the same time that data have not been changedArgon2id or bcrypt - they add salt and work factor themselves (see side by side)secrets module Python - its numbers cannot be predictedcryptography, not own written codeAES-ECB - each block is encrypted separately, so the same data gives the same encryption and the data pattern remains visibleMD5, SHA-1 - can deliberately create two different files with the same mixing value (clash), so the integrity check and signature with them are not reliablerandom module secrets - from some of its numbers can be calculated nextData on disk and database
Why two levels: key rotation means to decrypt only DEK, not all data. One million records remain in place, one small value changes.
Protects against stolen equipment. When the system is running, the data is open - therefore it does not protect against entering the server.
Encrypt specific fields (personal data, health data). Also protects against the DB administrator, but the encrypted fields can no longer be searched and sorted.
The most frequently forgotten place. The copy shall be the same data without access control. The copies of this site are encrypted by age and stored outside the server.
Network data
Forward secret (PFS) means that the private key of a later stolen server does not decrypt the previously recorded traffic - each session has its own temporary key. It is commonly called a future mystery, but the industry uses the original term.
As a browser and server, a common key is agreed without anyone sending it over the network.
The attacker sees in the network: site name (SNI) and client key part - it is not a secret
The browser greets the server, names supported chiffs and immediately sends its short-term key section.
The server calculates the common key (ECDHE) from both parts of the keys. It never goes on the net.
Network attacker sees: ServerHello exposed; certificate and everything else is already encrypted
The server responds with its own part, certificate and signature, which proves that it has the private key of the certificate.
The browser makes sure you talk to the right server and calculates the same common key.
The attacker sees in the network: only encrypted data and their volume
One round-back cycle, and the data already goes encrypted with the common key.
This is called forward secret: the recorded traffic remains secure even if the server is later hacked.
Metadata: with which server speaks, how much and how often. Content is closed, there is no fact of communication.
TLS ends at the server. If the data behind it goes between microservices, only the first step is protected - therefore mTLS internal network.
Normal certificate confirms domain control, not that the owner is honest. The phishing page also has a valid lock.
The Challenge
The state of use is the only one where there is no universal solution. Fairly for most systems: minimizing and tokenisation solves most, and only then is it worth looking at the enclaves.
The value of the Reliable Performance Environment (TEE) is the Remote Attestation: the enclave can prove which code works directly in it. Without it, the enclave is just another black box.
The enclave transfers trust from the cloud maintainer to the processor manufacturer. It is a change, not an elimination - and against side channel attacks (reading of secrets after processor time, cache or consumption) they have been vulnerable.
This site uses the simplest layer: card data never gets to the server (payments are processed by the payment service provider) so they do not need to be protected in the state of use.
Where cryptography in practice falls
An identified leak of mystery means rotation, not deletion of history. What has once been public must be regarded as known.
The same key for encryption and signing weakens both. Separate keys also mean that a single compromise does not open everything.
No man knows the root key completely. It is divided into parts and renewal requires a number of people - protection from one weak point.
System in which the cryptographic algorithm can be changed without overwrite. It became a practical requirement precisely because of the post-quantum cryptography (PQC) transition.
Standard landscape
FIPS 203 (ML-KEM, key encapsulation), FIPS 204 (ML-DSA, signatures) and FIPS 205 (SLH-DSA, interface-based signatures) were approved by NIST on 13 August 2024. In 2025, NIST was selected as a backup by KEM for HQC. NIST IR 8547 (project) foresees an ageing of RSA and ECC from 2030 and a ban from 2035.
FIPS 197 (AES), FIPS 180-4 (SHA-2), FIPS 202 (SHA-3), FIPS 186-5 (signatures). The transition periods are set by the NIST SP 800-131A.
NIST SP 800-175B (as to use), SP 800-57 (keys), ISO/IEC 19790 (module requirements), OWASP USAS 5.0 V11 (testable requirements for development).
Article 21 (2) (h) of the NIS2 requires a cryptographic policy. eIDAS regulates trust services and qualified e-signatures in the EU.
All signs used in the guide in one place.