EC-Council CBP cheat sheet

A hash function maps any input to a fixed-length digest; blockchain security relies on preimage resistance (cannot invert a digest), second-preimage resistance, and collision resistance (infeasible to find two inputs with the same digest).

Avalanche effect: changing one input bit should change roughly half the output bits; SHA-256 outputs 256 bits and Bitcoin uses double SHA-256 (SHA-256 applied twice) for block hashing and address derivation steps.

Merkle tree: leaves are transaction hashes, each parent is the hash of its two children; the root commits to all transactions, and a Merkle proof verifies inclusion in O(log n) hashes without revealing the whole block.

Asymmetric keys: a private key signs, the public key verifies; ECDSA over secp256k1 is used by Bitcoin and Ethereum. The public key is derived from the private key, never the reverse, and address = hash of the public key.

Digital signature properties: authentication (proves key holder), integrity (message unchanged), non-repudiation (signer cannot deny); signatures do NOT provide confidentiality, so encryption is a separate operation.

Symmetric vs asymmetric: AES is fast and used for bulk data; RSA/ECC handle key exchange and signatures. Hybrid schemes encrypt a symmetric session key with the recipient's public key.

Hash vs MAC vs signature: a bare hash gives integrity only against accidental change; an HMAC adds a shared secret for authenticity; a digital signature adds non-repudiation because only the private key holder can produce it.

Nonce and proof of work: miners vary a nonce until the block hash is below a target; difficulty adjusts to keep block time stable (Bitcoin targets ~10 minutes, retargeting every 2016 blocks).

Key management failure modes: reused ECDSA nonces leak the private key, lost keys mean lost funds (no recovery), and exposed seed phrases compromise every derived key in an HD wallet.

Block anatomy: header holds previous block hash, Merkle root, timestamp, nonce, and difficulty; the body holds transactions. Changing any past block invalidates all later hashes, which is why tampering is detectable.

Forks: a soft fork tightens rules and stays backward compatible; a hard fork loosens or changes rules and splits the chain unless all nodes upgrade.

Consensus families: PoW (work-based, probabilistic finality), PoS (stake-weighted, economic slashing), and BFT variants such as PBFT/Tendermint (voting, deterministic finality, tolerates f faulty nodes out of 3f+1).

Permissionless vs permissioned: public chains allow anonymous participation; consortium chains restrict membership and are typical for enterprise use where privacy and throughput matter.

Layer 2 scaling: rollups (optimistic with fraud proofs, zk with validity proofs), state channels, and sidechains move execution off Layer 1 while inheriting or borrowing its security to different degrees.

Ethereum specifics: accounts (EOA vs contract), gas measures computation, and gas cost = gas used x gas price. Smart contracts are immutable once deployed unless a proxy/upgrade pattern is used.

UTXO vs account model: Bitcoin tracks unspent outputs that are consumed and recreated; Ethereum tracks balances and nonces, which simplifies state but complicates parallel execution.

Interoperability mechanisms: bridges lock assets on one chain and mint representations on another; cross-chain risk concentrates in the bridge contract and its validators, not in either base chain.

Node types: full nodes validate all rules and store full state; light clients verify headers and request proofs; archive nodes retain historical state for queries and forensics.

The 51% attack: an entity controlling majority of hash power can double-spend and reorg recent blocks but cannot forge signatures, steal coins, or rewrite deeply buried history cheaply.

Smart contract risk classes: reentrancy (external call before state update), integer overflow/underflow (pre-0.8 Solidity), access-control gaps, unchecked external calls, and oracle manipulation.

Reentrancy mitigation rule: follow checks-effects-interactions and use reentrancy guards; update balances before transferring value, and prefer pull-over-push payment patterns.

Oracle risk: on-chain prices sourced from a single DEX are manipulable via flash loans; use time-weighted average prices and multiple independent feeds.

Wallet and key risk: hot wallets are online and convenient but exposed; cold/air-gapped storage reduces remote compromise; multi-signature requires m-of-n approvals and removes single points of failure.

Phishing and approval abuse: malicious token approvals let attackers drain funds later; risk control is periodic review and revocation of allowances, plus address verification before transfer.

Audit and assurance: static analysis, fuzzing, formal verification, and independent audits reduce but do not eliminate risk; bug bounties and timelocks add defense in depth.

Regulatory and compliance risk: KYC/AML obligations, travel-rule data sharing, and sanctions screening apply to exchanges and custodians; privacy coins and mixers raise heightened scrutiny.

Incident response for chains: because transactions are irreversible, response focuses on pausing contracts, blacklisting addresses, notifying exchanges, and preserving on-chain evidence for forensics.

Fit test: blockchain suits multi-party processes lacking a trusted intermediary, with shared write access, auditability needs, and low transaction volume; it is a poor fit for single-owner, high-volume, private data stores.

Supply chain: provenance and tamper-evident records work well, but on-chain data is only as trustworthy as the off-chain input, so oracle and sensor integrity are the binding constraint.

Trade finance and letters of credit: smart contracts can automate document checks and release payment on verified milestones, cutting settlement time from days to hours among consortium members.

Identity: self-sovereign identity uses decentralized identifiers and verifiable credentials; the holder controls the wallet and presents only selective disclosures rather than full documents.

Tokenization: asset-backed tokens require legal enforceability of the off-chain claim, custody arrangements, and clear redemption rights; the token is not the asset itself.

Payments and CBDCs: stablecoins reduce volatility for settlement; retail CBDCs raise privacy and programmability policy questions distinct from wholesale interbank settlement.

Healthcare and records: consent management and audit trails are strong use cases; storing raw personal health data on a public ledger conflicts with privacy regulation, so hashes or pointers are used.

Energy and carbon markets: peer-to-peer trading and renewable-energy certificates benefit from tokenized, auditable attributes, with metering-data integrity as the key control.

Business case evaluation: compare against a conventional shared database; blockchain's premium is justified only when disintermediation, tamper evidence, or multi-party trust outweigh latency, cost, and governance overhead.

A hash function maps any input to a fixed-length digest; blockchain security relies on preimage resistance (cannot invert a digest), second-preimage resistance, and collision resistance (infeasible to find two inputs with the same digest).

Avalanche effect: changing one input bit should change roughly half the output bits; SHA-256 outputs 256 bits and Bitcoin uses double SHA-256 (SHA-256 applied twice) for block hashing and address derivation steps.

Merkle tree: leaves are transaction hashes, each parent is the hash of its two children; the root commits to all transactions, and a Merkle proof verifies inclusion in O(log n) hashes without revealing the whole block.

Asymmetric keys: a private key signs, the public key verifies; ECDSA over secp256k1 is used by Bitcoin and Ethereum. The public key is derived from the private key, never the reverse, and address = hash of the public key.

Digital signature properties: authentication (proves key holder), integrity (message unchanged), non-repudiation (signer cannot deny); signatures do NOT provide confidentiality, so encryption is a separate operation.

Symmetric vs asymmetric: AES is fast and used for bulk data; RSA/ECC handle key exchange and signatures. Hybrid schemes encrypt a symmetric session key with the recipient's public key.

Hash vs MAC vs signature: a bare hash gives integrity only against accidental change; an HMAC adds a shared secret for authenticity; a digital signature adds non-repudiation because only the private key holder can produce it.

Nonce and proof of work: miners vary a nonce until the block hash is below a target; difficulty adjusts to keep block time stable (Bitcoin targets ~10 minutes, retargeting every 2016 blocks).

Key management failure modes: reused ECDSA nonces leak the private key, lost keys mean lost funds (no recovery), and exposed seed phrases compromise every derived key in an HD wallet.

Block anatomy: header holds previous block hash, Merkle root, timestamp, nonce, and difficulty; the body holds transactions. Changing any past block invalidates all later hashes, which is why tampering is detectable.

Forks: a soft fork tightens rules and stays backward compatible; a hard fork loosens or changes rules and splits the chain unless all nodes upgrade.

Consensus families: PoW (work-based, probabilistic finality), PoS (stake-weighted, economic slashing), and BFT variants such as PBFT/Tendermint (voting, deterministic finality, tolerates f faulty nodes out of 3f+1).

Permissionless vs permissioned: public chains allow anonymous participation; consortium chains restrict membership and are typical for enterprise use where privacy and throughput matter.

Layer 2 scaling: rollups (optimistic with fraud proofs, zk with validity proofs), state channels, and sidechains move execution off Layer 1 while inheriting or borrowing its security to different degrees.

Ethereum specifics: accounts (EOA vs contract), gas measures computation, and gas cost = gas used x gas price. Smart contracts are immutable once deployed unless a proxy/upgrade pattern is used.

UTXO vs account model: Bitcoin tracks unspent outputs that are consumed and recreated; Ethereum tracks balances and nonces, which simplifies state but complicates parallel execution.

Interoperability mechanisms: bridges lock assets on one chain and mint representations on another; cross-chain risk concentrates in the bridge contract and its validators, not in either base chain.

Node types: full nodes validate all rules and store full state; light clients verify headers and request proofs; archive nodes retain historical state for queries and forensics.

The 51% attack: an entity controlling majority of hash power can double-spend and reorg recent blocks but cannot forge signatures, steal coins, or rewrite deeply buried history cheaply.

Smart contract risk classes: reentrancy (external call before state update), integer overflow/underflow (pre-0.8 Solidity), access-control gaps, unchecked external calls, and oracle manipulation.

Reentrancy mitigation rule: follow checks-effects-interactions and use reentrancy guards; update balances before transferring value, and prefer pull-over-push payment patterns.

Oracle risk: on-chain prices sourced from a single DEX are manipulable via flash loans; use time-weighted average prices and multiple independent feeds.

Wallet and key risk: hot wallets are online and convenient but exposed; cold/air-gapped storage reduces remote compromise; multi-signature requires m-of-n approvals and removes single points of failure.

Phishing and approval abuse: malicious token approvals let attackers drain funds later; risk control is periodic review and revocation of allowances, plus address verification before transfer.

Audit and assurance: static analysis, fuzzing, formal verification, and independent audits reduce but do not eliminate risk; bug bounties and timelocks add defense in depth.

Regulatory and compliance risk: KYC/AML obligations, travel-rule data sharing, and sanctions screening apply to exchanges and custodians; privacy coins and mixers raise heightened scrutiny.

Incident response for chains: because transactions are irreversible, response focuses on pausing contracts, blacklisting addresses, notifying exchanges, and preserving on-chain evidence for forensics.

Fit test: blockchain suits multi-party processes lacking a trusted intermediary, with shared write access, auditability needs, and low transaction volume; it is a poor fit for single-owner, high-volume, private data stores.

Supply chain: provenance and tamper-evident records work well, but on-chain data is only as trustworthy as the off-chain input, so oracle and sensor integrity are the binding constraint.

Trade finance and letters of credit: smart contracts can automate document checks and release payment on verified milestones, cutting settlement time from days to hours among consortium members.

Identity: self-sovereign identity uses decentralized identifiers and verifiable credentials; the holder controls the wallet and presents only selective disclosures rather than full documents.

Tokenization: asset-backed tokens require legal enforceability of the off-chain claim, custody arrangements, and clear redemption rights; the token is not the asset itself.

Payments and CBDCs: stablecoins reduce volatility for settlement; retail CBDCs raise privacy and programmability policy questions distinct from wholesale interbank settlement.

Healthcare and records: consent management and audit trails are strong use cases; storing raw personal health data on a public ledger conflicts with privacy regulation, so hashes or pointers are used.

Energy and carbon markets: peer-to-peer trading and renewable-energy certificates benefit from tokenized, auditable attributes, with metering-data integrity as the key control.

Business case evaluation: compare against a conventional shared database; blockchain's premium is justified only when disintermediation, tamper evidence, or multi-party trust outweigh latency, cost, and governance overhead.