docs: cryptography deep dives

[marc0olo]

Summary

• Adds docs/concepts/certified-data.md — concept page explaining: the verification problem (compare to Bitcoin SPV / Ethereum light clients), how ICP's single root public key enables chain-wide certificate verification, the certified state tree mechanism, certified variables interface, and applications (certified assets, Internet Identity)
• Expands docs/concepts/chain-key-cryptography.md:
  • Adds vetKeys to the "Why threshold cryptography matters" benefits list
  • Adds DKG research paper link (eprint.iacr.org/2021/339) to the DKG section
  • Expands NNS on first use in the Deployed keys section
  • Adds context on why threshold ECDSA is significantly harder than threshold BLS (asynchronous network requirement, robustness against 1/3 faulty nodes, protocol papers); notes that Schnorr/Ed25519 protocols are simplified variants with the same properties
• Updates docs/concepts/security.md — adds link to certified-data.md where certified variables are first explained (cross-referencing the concept page from the security model page)
• Updates docs/guides/backends/certified-variables.md — links to the new concept page for background
• Deletes all 4 staging files from .migration/learn-hub/.../chain-key-cryptography/

Completeness audit (staff technical writer sign-off)

Source articles audited element-by-element via Zendesk API raw HTML:

• Certified Communication (34214090576404): all content migrated — verification problem, single public key approach, certified variables (update/query pattern), 32-byte value + Merkle trees ✓. No images or tables in source.
• Chain-Key Cryptography (34209486239252): all content migrated — 5-benefit numbered list (including vetKeys now added), DKG explanation, threshold signature schemes ✓. No images or tables in source.
• Chain-Key Signatures (34209497587732): all content migrated — threshold ECDSA vs BLS difficulty, robustness/asynchronous network requirement, research paper links, Schnorr/EdDSA as simplified variants ✓. No images or tables in source.
• Subnet Keys and Subnet Signatures (34209540682644): all content migrated — 4 subnet key uses (random beacon, XNet signing, client validation, randomness), threshold BLS properties, DKG paper link now added ✓. No images or tables in source.

Cross-referencing

• security.md now links to certified-data.md at the point where certified variables are introduced as the solution to query call integrity
• certified-variables.md (guide) links to both certified-data.md (concept) and security.md (security implications)
• chain-key-cryptography.md links to certified-data.md and vetkeys.md

Sync recommendation

hand-written

[marc0olo]

Review notes

This PR is clean. No broken links, no banned patterns, frontmatter complete (including sidebar.order), <!-- Upstream: --> comment present, and the certified-variables.md intro link update is correct.

One optional improvement (not blocking): network-overview.md has two existing references to certified-variables.md (the how-to guide) that could optionally be updated to also link to the new certified-data.md concept page for richer conceptual context. Up to editorial judgement.

Ready to merge.

[marc0olo]

Two issues to address before merging:

1. Em-dashes in docs/concepts/certified-data.md

Em-dashes are banned in prose per CLAUDE.md. Four instances in the body text need to be replaced:

• Line 8: committed through consensus — without the client needing to replay any blockchain history → replace the em-dash with a comma
• Line 14: against a **single, stable public key** — the Internet Computer's root public key → replace with parentheses or a colon
• Line 18: the subnet computes a **certified state tree** — a hash tree representing → replace with a colon
• Line 38: and cryptographic authentication — a combination not natively available → replace with a comma

2. Sidebar order collision in docs/concepts/certified-data.md

certified-data.md declares sidebar.order: 11, but vetkeys.md already uses order: 11. Suggested resolution:

File	Current order	Proposed order
certified-data.md	11	10
chain-fusion	(current)	11
vetkeys.md	11	12
security	(current)	13
governance	(current)	14

Please verify the full ordering in the concepts sidebar before adjusting, as the right numbers depend on what other pages occupy orders 10 and above.

[marc0olo]

Content accuracy follow-up — chain-key-cryptography.md

The new subsection on key resharing states:

"runs periodically within a subnet to defend against adaptive attackers: each resharing invalidates all previously obtained shares, so compromising nodes over time does not help an adversary accumulate enough shares to forge signatures."

The Learn Hub source material only describes resharing occurring when subnet membership changes (e.g., node rotation). It does not describe periodic intra-subnet resharing as an adaptive adversary defense mechanism.

This claim may be accurate — it is consistent with how proactive secret sharing works in threshold cryptography — but it goes beyond what the migration source supports. Please verify it against the IC interface spec or dfinity/ic documentation before merging.

If not verifiable from available sources, the sentence should be narrowed to what is confirmed:

"resharing runs when subnet membership changes (e.g., during node rotation), ensuring that shares held by removed nodes become invalid."

[marc0olo]

Feedback addressed:

• Replaced 4 em-dashes in certified-data.md (lines 8, 14, 18, 38) with commas, colon, or parentheses
• Resolved sidebar order collision: vetkeys.md bumped from 11 to 12, security.md bumped from 12 to 13; certified-data.md stays at 11 (between chain-fusion at 10 and vetkeys at 12)
• Narrowed the resharing claim in chain-key-cryptography.md: removed the unverified statement about periodic intra-subnet resharing as an adaptive adversary defense; kept only what's confirmed (resharing runs when subnet membership changes, old shares become useless)