[TOC]
↗ Mathematical Modeling & Abstraction ↗ Models of Computation & Abstract Machines
↗ Cryptographic Protocols Modeling & Verification
↗ AnB (Alice and Bob) Notation & AnBx Languages
Models of communication simplify or represent the process of communication. Most communication models try to describe both verbal and non-verbal communication and often understand it as an exchange of messages. Their function is to give a compact overview of the complex process of communication. This helps researchers formulate hypotheses, apply communication-related concepts to real-world cases, and test predictions. Despite their usefulness, many models are criticized based on the claim that they are too simple because they leave out essential aspects. The components and their interactions are usually presented in the form of a diagram. Some basic components and interactions reappear in many of the models. They include the idea that a sender encodes information in the form of a message and sends it to a receiver through a channel. The receiver needs to decode the message to understand the initial idea and provides some form of feedback. In both cases, noise may interfere and distort the message.
Models of communication are classified depending on their intended applications and on how they conceptualize the process. General models apply to all forms of communication while specialized models restrict themselves to specific forms, like mass communication. Linear transmission models understand communication as a one-way process in which a sender transmits an idea to a receiver. Interaction models include a feedback loop through which the receiver responds after getting the message. Transaction models see sending and responding as simultaneous activities. They hold that meaning is created in this process and does not exist prior to it. Constitutive and constructionist models stress that communication is a basic phenomenon responsible for how people understand and experience reality. Interpersonal models describe communicative exchanges with other people. They contrast with intrapersonal models, which discuss communication with oneself. Models of non-human communication describe communication among other species. Further types include encoding-decoding models, hypodermic models, and relational models.
The problem of communication was already discussed in Ancient Greece but the field of communication studies only developed into a separate research discipline in the middle of the 20th century. All early models were linear transmission models, like Lasswell's model, the Shannon–Weaver model, Gerbner's model, and Berlo's model. For many purposes, they were later replaced by interaction models, like Schramm's model. Beginning in the 1970s, transactional models of communication, like Barnlund's model, were proposed to overcome the limitations of interaction models. They constitute the origin of further developments in the form of constitutive models.
🤖 GPT-5.2 https://chatgpt.com/share/698a3655-f540-800f-939f-c8ce2c90027f
One-sentence summary: Cryptographic models are needed to precisely define security, reason about powerful attackers, find subtle protocol flaws, enable proofs and automation, and make assumptions explicit—something testing and intuition can never guarantee.
We need cryptographic models because security is not something we can “test” exhaustively—it must be reasoned about. Models give us a precise way to define attackers, assumptions, and guarantees, so we can prove (or disprove) security claims.
Here’s the intuition, then the formal reasons.
Intuition: why models are necessary -- Saying “this protocol is secure” without a model is meaningless.
- Secure against whom?
- Secure under what assumptions?
- Secure in which environment? Cryptographic models answer these questions.
Formal reasons:
==To define what security means== Security is not absolute. Examples:
- “The message is secret”
- “The protocol authenticates the server”
- “Keys cannot be stolen” These statements are vague unless we specify:
- What the attacker can do
- What it means to “break” security
Models provide formal definitions For example:
- In the Dolev–Yao model, secrecy means:
- The attacker cannot derive the message term.
- In the computational model, secrecy means:
- No PPT adversary can distinguish the message from random. Without a model, there is no precise notion of security.
==To reason about extremely powerful attackers== Real attackers:
- Control networks
- Replay messages
- Run protocols concurrently
- Adapt based on observations We cannot enumerate all possible attacks.
Models let us assume a maximal attacker
- Dolev–Yao: attacker controls the entire network
- Computational: attacker is any PPT algorithm
If a protocol is secure against these attackers, it is secure against weaker real-world attackers.
==To find subtle protocol flaws before deployment== Many famous protocol failures were logic errors, not broken crypto:
- Needham–Schroeder (authentication flaw)
- TLS renegotiation attack
- Kerberos replay issues These flaws:
- Passed testing
- Used strong cryptography
- Failed under formal analysis
Models expose:
- Replay attacks
- Man-in-the-middle attacks
- Confusion of identities
- Key reuse mistakes Testing alone cannot catch these.
==To enable formal proofs and automation== Models make security machine-checkable. Thanks to models, we can:
- Automatically verify protocols
- Get counterexamples (attacks)
- Prove properties hold for all executions Tools rely on models:
- ProVerif → symbolic (Dolev–Yao–style)
- Tamarin → symbolic + algebraic
- CryptoVerif → computational Without models, automated verification is impossible.
==To separate protocol logic from cryptographic strength== Models help answer different questions: Symbolic models (e.g., Dolev–Yao)
- “Is the protocol logic correct assuming crypto works?” Computational models
- “Does this cryptographic construction resist feasible attacks?”
This separation is crucial:
- A protocol can be logically broken even with perfect crypto
- A cryptosystem can be cryptographically broken even if protocol logic is sound
==To make assumptions explicit== Every security claim depends on assumptions. Models force you to state them clearly:
- Is encryption probabilistic?
- Are keys long-term or ephemeral?
- Can sessions run concurrently?
- Are hashes ideal? This prevents hidden assumptions, which are a major cause of insecurity.
==To reason about composition and real-world use== Protocols rarely run in isolation. Models like Universal Composability (UC) ensure:
- Security still holds when protocols interact
- Security survives concurrent executions
- Components can be safely reused Without models:
- A “secure” protocol can become insecure when combined with others
==Why multiple models exist (not just one)== No single model captures everything:
| Model | Strength | Weakness |
|---|---|---|
| Dolev–Yao | Finds logic flaws, automatable | Ignores crypto weaknesses |
| Computational | Realistic crypto | Hard to automate |
| UC | Strong composability | Very complex |
| Info-theoretic | Absolute guarantees | Often impractical |
We need different models for different questions.
🤖 GPT-5.2 https://chatgpt.com/share/69a6af9d-125c-8010-bb42-788c68a525ca
| Model Family | Example / Framework | Crypto Assumption | Attacker Network Power | Computation Power | Corruption Model | Concurrency | Physical / Leakage | Typical Use |
|---|---|---|---|---|---|---|---|---|
| Symbolic | Dolev–Yao model | Perfect (black-box) | Full control | Term algebra | Usually none | Multi-session (abstract) | None | Protocol logic flaws |
| Symbolic | Strand Spaces | Perfect | Message interception | Symbolic | None | Yes | None | Authentication proofs |
| Symbolic (Algebraic) | DY + XOR / DH | Idealized but algebraic | Full control | Symbolic w/ equations | None | Yes | None | Diffie–Hellman modeling |
| Computational | Bellare–Rogaway (IND-CPA/CCA) | Real crypto | Oracle access | PPT | Static/adaptive | Usually single-session | None | Encryption security |
| Computational | Universal Composability (UC) | Real crypto | Fully adversarial scheduling | PPT | Static / adaptive | Fully concurrent | None | Composable protocols |
| Hybrid | Computationally Sound DY | Real crypto | Full network | PPT | Limited | Multi-session | None | Bridging symbolic & real |
| Info-theoretic | Shannon secrecy | Perfect secrecy | Full | Unbounded | None | Usually single | None | One-time pad theory |
| Distributed Systems | Byzantine model | Crypto optional | Message scheduling | Unbounded / bounded | Arbitrary faulty nodes | Yes | None | Consensus |
| MPC | Semi-honest | Real crypto | Honest protocol execution | PPT | Passive corruption | Yes | None | Privacy computation |
| MPC | Malicious adversary | Real crypto | Arbitrary deviation | PPT | Active corruption | Yes | None | Secure computation |
| Leakage Model | Side-channel model | Real crypto + leakage | Physical access | Varies | N/A | N/A | Timing/power/cache | Hardware security |
| Fault Model | Fault injection | Real crypto | Physical tampering | Varies | N/A | N/A | Faults allowed | Embedded security |
| Post-Quantum | Quantum adversary | Quantum-resistant | Oracle access | Quantum | Static/adaptive | Yes | None | PQC security |
| Rational | Game-theoretic adversary | Crypto optional | Strategic deviation | Utility-maximizing | Strategic | Yes | None | Blockchain, mechanism design |
This unified version includes:
- Crypto abstraction level
- Perfect symbolic
- Real computational
- Ideal functionality (UC)
- Information-theoretic
- Network power
- Passive
- Full Dolev–Yao
- Oracle-based
- Computation bounds
- Symbolic term algebra
- PPT
- Unbounded
- Quantum
- Corruption type
- None
- Passive (semi-honest)
- Malicious
- Adaptive
- Byzantine
- Concurrency model
- Single-session
- Multi-session
- Fully concurrent composability
- Physical realism
- No leakage
- Side-channel
- Fault injection
How to Read This Big Picture Think of adversary models as spanning three orthogonal axes:
- Axis A — Cryptographic Realism
- Symbolic → Computational → Info-theoretic
- Axis B — System Interaction Power
- Passive → Active → Fully adaptive + concurrent
- Axis C — Physical Capabilities
- Network-only → Side-channel → Fault → Quantum
Different research communities emphasize different axes.