Data in transit (moving over a network), data in use (being processed in memory/CPU), and data at rest (stored on disk) — each is attacked differently, so each needs its own controls.

* Each state lives somewhere different, so each needs its own control. *

Why it matters: people instinctively protect data at rest (the locked laptop) but forget transit (open Wi-Fi) and use (a process reading plaintext in memory). A complete security design has to cover all three. In use is the trickiest because the data must be decrypted to be computed on.

Tip: Remember the trio Transit – Use – Rest. Encryption mostly solves transit and rest; "in use" is still an open research area.

Go deeper:

• Data at rest / in transit / in use (Wikipedia) — the three states and why each is defended differently.

A light disturbance flips a bit or two; a heavy one mangles whole chunks — and your integrity check has to be strong enough to catch both.

When Alice sends a file to Bob, noise on the line can corrupt it:

• Leichte Störung — a few bits flip. A simple checksum is usually enough to notice.
• Starke Störung — large parts are garbled. You need a method whose output changes drastically even for small input changes, so corruption can't slip through.

The core idea of integrity: Bob needs a way to tell "is what I received exactly what Alice sent?" He computes a check value over the received data and compares it to the one Alice attached. If they differ, the data changed.

Tip: Integrity ≠ confidentiality. We're not hiding the data here, just detecting whether it was altered.

Go deeper:

• Checksum (Wikipedia) — how a small check value flags accidental corruption in transmission or storage.