Cryptographic Protocol Engineering, Key Agreement and State Machines — DedSec Project
Cryptographic Protocol Engineering, Key Agreement and State Machines Strong primitives can still produce an insecure protocol if identities, transcript binding, nonces, key separation…
Strong primitives can still produce an insecure protocol if identities, transcript binding, nonces, key separation, error handling, or state transitions are wrong. This module teaches how to reason about cryptographic protocols as authenticated state machines.
Learning objectives
By the end of this module you should be able to:
- Explain Security goals and connect it to a concrete trust boundary or security invariant.
- Explain Key agreement and connect it to a concrete trust boundary or security invariant.
- Explain Transcript binding and connect it to a concrete trust boundary or security invariant.
- Explain Nonces and sequence numbers and connect it to a concrete trust boundary or security invariant.
- Explain Key derivation and connect it to a concrete trust boundary or security invariant.
- Explain Algorithm agility and connect it to a concrete trust boundary or security invariant.
Deep concepts
1. Security goals
Write goals before algorithms: confidentiality, integrity, peer authentication, forward secrecy, replay resistance, channel binding, deniability, key confirmation, or post-compromise properties. Different protocols need different combinations.
2. Key agreement
Key exchange establishes shared secret material but does not automatically authenticate peers. Authentication must bind identities/credentials to the transcript and agreed parameters.
3. Transcript binding
Security-critical negotiation should be included in authenticated transcript data so an intermediary cannot alter algorithms, identities, roles, or context without detection.
4. Nonces and sequence numbers
Fresh unpredictable nonces or monotonic sequence state prevent reuse/replay depending on the construction. Define uniqueness requirements precisely; “random-looking” is not the same as guaranteed unique.
5. Key derivation
Use a KDF to derive independent keys for different directions and purposes. Domain separation prevents one key/context from being accidentally reused for encryption, authentication, export, or another protocol.
6. Algorithm agility
Negotiation can enable migration but also creates downgrade risk. The protocol must authenticate the negotiation and have policy for removing obsolete algorithms.
7. Error handling
Different errors, timing, retry behavior, and partial state can leak information. Protocols should define failure states, cleanup, retry limits, and whether an error is safe to reveal.
8. Formal and empirical validation
Threat modeling, test vectors, interoperability tests, negative tests, state-machine fuzzing, and formal methods can complement code review. Cryptographic protocol design should be independently reviewed rather than invented casually.
Authorized exercises
Exercise 1 — Design a toy authenticated message protocol on paper and identify where identities, roles, nonces, sequence numbers, and transcript data are bound
Design a toy authenticated message protocol on paper and identify where identities, roles, nonces, sequence numbers, and transcript data are bound.
Exercise 2 — Create negative test cases for replay, reordered messages, algorithm downgrade, expired credentials, and duplicate session identifiers
Create negative test cases for replay, reordered messages, algorithm downgrade, expired credentials, and duplicate session identifiers.
Exercise 3 — Compare “encrypted transport” with “end-to-end authenticated message” and list which intermediaries can still read or modify data in each model
Compare “encrypted transport” with “end-to-end authenticated message” and list which intermediaries can still read or modify data in each model.
Knowledge checks
- Explain the most important trust boundary in Cryptographic Protocol Engineering, Key Agreement and State Machines without naming a security tool.
- Give one example where cryptographic or authentication success still does not imply authorization success.
- Describe one stale-state or replay condition relevant to this module.
- Identify one telemetry source that can support a strong conclusion and one blind spot it still leaves.
- Explain how you would turn a discovered weakness into a regression test rather than a one-time finding.