Chapter 26 — Cryptography and trust services: methods II
Lesson map
Lesson 26 published. Map, example, EX076.
flowchart TD
N0["Learning outcomes"]
N1["26.1 How signatures work"]
N2["26.2 Applying signatures"]
N3["26.3 ECDSA or Ed25519"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX076"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["26.1 How signatures work"]
N2["26.2 Applying signatures"]
N3["26.3 ECDSA or Ed25519"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX076"]
[Learning outcomes]
|
v
[26.1 How signatures work]
|
v
[26.2 Applying signatures]
|
v
[26.3 ECDSA or Ed25519]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX076]
Learning outcomes
You will (1) explain digital signatures and verification; (2) apply signatures to documents and software; (3) choose between ECDSA and Ed25519.
26.1 How signatures work
A digital signature scheme has three operations: key generation, signing with a private key and verifying with the matching public key. FIPS 186-5 specifies ECDSA and EdDSA, and RFC 8032 specifies Ed25519. Anyone with the public key can verify that the signature matches the exact bytes signed, but only the private-key holder could create it. Priya contrasts this with HMAC, where verifiers share the secret and could create tags themselves. She demonstrates with a library that changing one byte of a signed file makes verification fail, while the original verifies.
26.2 Applying signatures
Tidewell signs two kinds of things. Contracts with publishers are signed as PDF documents with certificates, so either party can verify them years later. Software scripts deployed to branch servers are signed by the IT team, and servers refuse unsigned scripts. Priya explains that signatures prove origin and integrity but rely on protecting private keys and distributing trusted public keys. She recommends keeping the script-signing key in the key service, where signing requires an approved request. Grace approves the change for the next quarter.
26.3 ECDSA or Ed25519
Priya compares the two. ECDSA with P-256 is widely supported and allowed by FIPS 186-5, but requires a fresh secret value per signature, and implementations that reused or leaked it have exposed private keys. Ed25519 derives that value deterministically from the key and message, removing that failure mode, and is fast. Both are in FIPS 186-5. She recommends Ed25519 where supported and ECDSA through vetted libraries where compatibility requires, and notes that post-quantum signatures from FIPS 204 will be needed later. Grace adopts the recommendation.
Worked example
Priya explains signing and verification, applies signatures to contracts and scripts with a key-service signing key, and recommends Ed25519 where supported.
Synthetic case. Tidewell's signing uses are invented; FIPS 186-5, RFC 8032 and FIPS 204 are real.
Errors and limits
Signatures are useless if private keys leak or public keys are not authenticated. Per-signature randomness failures in ECDSA have exposed keys.
Exercises
- EX076 — Three operations. Name the three operations of a signature scheme. Rubric: 3 = key generation, signing, verification;; 2 = two;; 1 = one;; 0 = none.
- EX077 — Script signing. What do branch servers do with scripts, and where is the signing key kept? Rubric: 3 = refuse unsigned scripts; key in key service with approved requests;; 2 = both;; 1 = one;; 0 = none.
- EX078 — Ed25519 advantage. What failure mode does Ed25519 avoid? Rubric: 3 = per-signature secret derived deterministically, avoiding reused/leaked nonces exposing keys;; 2 = nonce;; 1 = vague;; 0 = none.
Synthesis
Digital signatures prove origin and integrity publicly; Ed25519's deterministic design avoids a classic ECDSA failure.
Continue studying — chapter 26 of 40
← Chapter 25 (draft) · Course chapter index · Chapter 27 (draft) →