Cryptographic Concepts and Security Assumptions

Introduction

Cryptography is the discipline of protecting information and communication through mathematical techniques. In blockchain systems, it supports digital signatures, wallet security, transaction integrity, address generation, consensus mechanisms, and hash-linked data structures. However, cryptography does not provide unlimited protection. It operates within assumptions about algorithms, keys, randomness, computational resources, software, users, and the surrounding system.

A sound understanding of these assumptions is essential for anyone working with blockchain. A cryptographic algorithm may be mathematically secure while an application remains vulnerable because a private key was exposed, a random-number generator failed, or a user was deceived into signing a malicious transaction. This chapter introduces the principal concepts required to reason correctly about cryptographic protection and its limits.

Learning Objectives

By the end of this chapter, you should be able to:

• distinguish plaintext, ciphertext, keys, encryption, decryption, hashing, encoding, and obfuscation;
• explain entropy, randomness, and the role of secure random-number generation;
• describe computational hardness and security parameters;
• apply Kerckhoffs’s principle to cryptographic system design;
• distinguish confidentiality, integrity, authentication, and non-repudiation;
• recognize important limitations and failure modes of cryptographic protection;
• evaluate a practical blockchain security scenario using appropriate assumptions and controls.

1. The Basic Cryptographic Model

A cryptographic system transforms information according to an algorithm and one or more keys. The original readable information is called plaintext. After transformation, it becomes ciphertext, which is intended to be unintelligible to an unauthorized observer.

For a symmetric encryption scheme, encryption and decryption can be represented as:

Here, P is plaintext, C is ciphertext, K is a secret key, Enc is the encryption algorithm, and Dec is the decryption algorithm. Correctness requires that decryption recover the original plaintext when the correct key and valid ciphertext are used:

This equation expresses correctness, not security. An algorithm can decrypt correctly and still be insecure if an attacker can recover the plaintext or key efficiently.

Symmetric and asymmetric cryptography

In symmetric cryptography, the same secret key, or closely related secret keys, is used for encryption and decryption. Advanced Encryption Standard (AES) is a common example. Symmetric encryption is generally efficient and suitable for protecting large amounts of data, but the communicating parties must establish the secret key securely.

In asymmetric cryptography, each participant has a key pair:

• a public key, which may be distributed openly; and
• a private key, which must be kept secret.

Public-key systems support encryption, key establishment, and digital signatures. In a signature system, a signer uses a private key to create a signature, while anyone with the corresponding public key can verify it. Blockchain systems commonly use asymmetric cryptography for transaction authorization rather than encrypting all ledger data.

Security services

Cryptographic mechanisms can support several distinct security properties:

These properties should not be confused. A hash can detect a change but does not conceal data. Encryption can conceal data but, without authentication, may not detect malicious modification. A digital signature authenticates a statement associated with a key, but it does not prove that a real-world person controlled the key unless identity management connects the key to that person.

2. Encoding, Encryption, Hashing, and Obfuscation

Several transformations are often incorrectly described as encryption. Their purposes and security properties differ fundamentally.

Encoding

Encoding converts data into another representation so that it can be stored, transmitted, or interpreted consistently. Examples include Base64, hexadecimal, and UTF-8. Encoding normally uses no secret and is reversible by anyone who knows the format. Base64 therefore provides no confidentiality.

For example, the text “ABC” can be represented in Base64 as “QUJD”. Anyone can decode it. Encoding is useful for compatibility, not secrecy.

Encryption

Encryption is a keyed transformation intended to provide confidentiality. A secure encryption scheme should prevent an attacker who sees ciphertext from learning useful information about the plaintext, except what is necessarily revealed by allowed metadata such as message length.

Modern encryption should normally provide authenticated encryption, which combines confidentiality with integrity and authenticity of the ciphertext. An authenticated-encryption scheme may be represented as:

Here, N is a nonce or unique public value, P is plaintext, A is associated data that is authenticated but not encrypted, C is ciphertext, and T is an authentication tag. The nonce requirement depends on the algorithm; for many widely used modes, nonce reuse with the same key can seriously compromise security.

Hashing

A cryptographic hash function maps an input of arbitrary length to a fixed-length output:

Here, M is the message, H is the hash function, and h is the digest. A secure cryptographic hash is designed to provide properties such as:

• preimage resistance: given a digest h, finding a message M such that H(M) = h should be computationally infeasible;
• second-preimage resistance: given a message M₁, finding a different message M₂ with the same digest should be infeasible;
• collision resistance: finding any two distinct messages with the same digest should be infeasible.

Hashing is not encryption. A hash is generally not reversible, and a hash value does not contain a secret by itself. Password systems should use password-specific, deliberately slow functions with salts rather than simply applying a fast general-purpose hash.

For an ideal hash with an n-bit output, a generic preimage search requires approximately 2ⁿ trials, while a generic collision search requires approximately 2^n/2 trials. The collision estimate follows from the birthday phenomenon and is an approximate work factor, not an exact runtime guarantee.

Obfuscation

Obfuscation makes code, data, or logic more difficult to understand. It may rename variables, rearrange code, or conceal implementation details. Obfuscation can increase the effort required for casual analysis, but it is not a substitute for encryption or access control. If an attacker can obtain the obfuscated material and execute or inspect it, obfuscation may eventually be reversed.

3. Keys and Key Management

A key is information that controls a cryptographic operation. The security of a well-designed cryptosystem should depend primarily on the secrecy and quality of the key, not on hiding the algorithm.

Key management includes generation, distribution, storage, use, rotation, backup, recovery, revocation, and destruction. In blockchain, a private key is often the practical authority to authorize transactions. Losing the key may mean losing control permanently; exposing it may allow an attacker to transfer assets.

Important distinctions include:

• key length: the number of bits in the key representation;
• effective security: the attack effort required against the best known method;
• key quality: whether the key was generated uniformly and unpredictably;
• key scope: the assets, accounts, or operations controlled by the key;
• key lifecycle: how the key is created, used, stored, rotated, and retired.

A long key generated predictably may be weaker than a shorter key generated uniformly from a sufficiently large random space. Similarly, storing a private key in an exposed browser extension or plaintext configuration file defeats the mathematical strength of the underlying algorithm.

4. Entropy and Randomness

In cryptography, entropy describes uncertainty. Informally, a secret has high entropy when an attacker has many plausible possibilities and no efficient way to rank one possibility overwhelmingly above the others.

For a discrete random variable X with possible outcomes x and probabilities p(x), Shannon entropy is:

The result is measured in bits. The formula describes average uncertainty, not necessarily the security of a cryptographic key. For a uniformly distributed variable with N possible outcomes:

Thus, a uniformly selected value from 256 possibilities has 8 bits of entropy. A biased process with the same number of possible outputs has less entropy.

Cryptographic systems require unpredictability, not merely variation. A password such as “correct horse battery staple” may contain many characters but have less effective security than a shorter secret generated uniformly by a secure random-number generator, depending on how attackers model human choices.

Random-number generators

A true random-number generator obtains randomness from a physical process. A pseudorandom number generator expands a short internal state into a longer sequence. A cryptographically secure pseudorandom number generator (CSPRNG) is designed so that, without its internal state or seed, predicting future outputs or reconstructing past outputs is computationally infeasible under stated assumptions.

The seed of a CSPRNG must itself contain adequate entropy and must be protected. Common failures include:

• seeding from the current time;
• using predictable device identifiers;
• reusing a seed across devices;
• exposing internal generator state;
• generating two supposedly unique nonces with the same key.

In digital signatures, poor randomness can reveal or enable recovery of a private key. Consequently, standards may use deterministic nonce generation derived from the message and private key, or carefully designed random generation with health checks.

5. Computational Hardness and Security Parameters

Cryptography rarely claims that an attack is impossible. It claims that the attack is infeasible for an adversary with a specified class of resources.

A problem is considered computationally hard when no efficient algorithm is known for solving it at the required scale, even though a solution may be easy to verify. Examples used in cryptography include integer factorization, discrete logarithms, and finding preimages or collisions in suitable hash functions. The security of a particular scheme depends on the best known attacks, implementation details, and assumptions about computing technology.

A security parameter, commonly denoted by λ, expresses the intended security level. Informally, an attack requiring about 2^λ operations is associated with approximately λ bits of generic security. This is a simplified interpretation: different attack types, algorithms, and cost models may produce different effective security levels.

For an ideal n-bit hash, a generic collision attack has an approximate work factor of 2^n/2. Therefore, a 256-bit hash has approximately 128-bit collision security against generic attacks, while its preimage security is approximately 256 bits. These values assume an idealized hash and ignore implementation weaknesses, advances in cryptanalysis, and resource constraints.

Threat models

Security claims are meaningful only relative to a threat model. A threat model specifies:

• the attacker’s goals, such as reading data, altering messages, stealing assets, or disrupting service;
• the attacker’s capabilities, such as observing traffic, submitting chosen messages, controlling a device, or compromising a server;
• the attacker’s resources, including computation, storage, network access, and time;
• the assets and trust boundaries being protected;
• the assumptions that are accepted as valid.

A system designed against a passive eavesdropper may fail against an attacker who can alter messages. A wallet secure against remote malware may fail when a user signs a transaction on a compromised screen.

6. Kerckhoffs’s Principle

Kerckhoffs’s principle states that a cryptosystem should remain secure even if everything about the system, except the key, is public. The algorithm should not depend on secrecy of design or implementation details.

This principle has several consequences:

1. Algorithms should be publicly specified and subject to independent analysis.
2. Keys should be generated and protected separately from public algorithms.
3. Security should not rely on undocumented “secret constants” or hidden formats.
4. Open review improves the likelihood that weaknesses will be discovered before deployment.
5. Replacing keys should be easier than replacing an entire cryptographic algorithm.

Kerckhoffs’s principle is often contrasted with security through obscurity, in which secrecy of design is treated as a primary defense. Obscurity can provide supplementary friction, but it is fragile: reverse engineering, leaked documentation, or insider access can expose the design. A system that fails as soon as its algorithm becomes known has an inadequate security foundation.

The principle does not require every implementation detail to be published immediately, nor does it prohibit confidential operational information. It states that secrecy of the key should carry the central cryptographic burden.

7. What Cryptography Cannot Guarantee

Cryptography protects specific properties under specific assumptions. It cannot automatically solve every security problem.

Endpoint compromise

If malware reads plaintext before encryption or after decryption, secure encryption does not help. Similarly, a private key copied by malware can be used to create valid signatures. Hardware security modules, hardware wallets, secure enclaves, and transaction confirmation displays can reduce some risks, but they do not eliminate all endpoint threats.

Weak authentication and social engineering

A user may be persuaded to reveal a seed phrase or sign an unintended transaction. The resulting transaction may be cryptographically valid. Cryptography can prove control of a key; it cannot determine whether the person controlling the key was deceived.

Metadata leakage

Encryption may conceal content while revealing timing, message size, communication partners, network location, or transaction amounts. Traffic analysis can exploit this metadata. Privacy therefore requires careful protocol, network, and application design.

Availability and recovery

Encryption does not guarantee that a service remains available. Denial-of-service attacks, lost keys, corrupted backups, software defects, and natural disasters require operational controls. Key recovery mechanisms also introduce additional trust and attack surfaces.

Implementation errors

A secure algorithm can be undermined by buffer overflows, incorrect nonce handling, weak randomness, side-channel leakage, unsafe APIs, or faulty certificate validation. Security engineering therefore includes code review, testing, formal analysis where appropriate, patching, monitoring, and incident response.

Quantum computing and changing assumptions

Large-scale fault-tolerant quantum computers could threaten widely used public-key schemes based on integer factorization and discrete logarithms. Symmetric cryptography and hash functions are affected differently, and the practical impact depends on the algorithm and implementation. Organizations with long-lived confidential data should consider migration planning and post-quantum cryptography. This is a risk-management issue, not evidence that current cryptography is universally broken.

8. Cryptography in Blockchain Systems

Blockchain platforms use several cryptographic components together.

Hash-linked data

A block may contain a reference to the hash of a previous block. If a past block changes, its hash changes and the link no longer matches. This provides tamper evidence, but it does not by itself prevent an attacker from rewriting history. Consensus rules, economic incentives, validator assumptions, and network control determine whether an altered history is accepted.

Digital signatures

A transaction is accepted only when it contains a valid signature corresponding to an authorized public key. The signature provides evidence that the holder of the private key approved the transaction. It does not prove that the key holder understood the transaction or that the transaction was beneficial.

Merkle structures

A Merkle tree summarizes many records using hashes. Pairwise hashes are repeatedly combined until a root hash is produced. A Merkle proof allows a participant to demonstrate that a record belongs to a committed set without transmitting the complete set. The security depends on collision and second-preimage resistance, as well as correct tree construction and domain separation.

Address and identity assumptions

A blockchain address is generally an identifier derived from a public key or script, not necessarily a legal identity. Control of an address does not automatically identify a human or organization. Compliance, customer identification, and sanctions obligations therefore require systems beyond the cryptographic ledger.

9. Applied Case: Loss of Funds from Predictable Wallet Keys

This is an illustrative case.

Background

A small blockchain service creates wallets for customers. To simplify development, its software generates a private key by taking the current system time in seconds, applying a standard hash function, and using the digest as the key.

Problem

An attacker observes several public addresses and estimates when the wallets were created. Because the possible creation times are limited, the attacker tests candidate timestamps, derives the corresponding keys, and identifies wallets whose public addresses match. The attacker then signs transactions transferring funds away.

Analysis

The hash function itself may be strong. The failure is key generation. If the seed is selected from only N plausible timestamps, the attacker’s search space is approximately N, not the full space suggested by the hash output. Hashing a low-entropy input does not create entropy.

If the attacker must test 86,400 possible timestamps for one day, the worst-case search is 86,400 trials and the average search is approximately 43,200 trials when candidates are equally likely. The computation is trivial for modern equipment. The resulting private keys are therefore predictable despite having a long hexadecimal representation.

Approach and solution

The service should:

1. generate keys using an operating-system CSPRNG or a properly evaluated hardware source;
2. use established wallet standards for hierarchical key derivation;
3. protect seeds with encryption, access controls, and hardware-backed storage where appropriate;
4. test randomness and key uniqueness;
5. conduct code review and independent security assessment;
6. migrate funds from previously generated wallets and assume compromised keys are permanently unsafe;
7. provide secure backup and recovery procedures without exposing seed phrases to operators.

Outcome

After replacing predictable key generation and rotating affected wallets, newly created wallets no longer depend on timestamps. The organization also improves monitoring and incident response. The case demonstrates that cryptographic strength is a system property: a strong hash cannot compensate for a predictable secret.

Learning points

• Entropy must exist before a cryptographic transformation is applied.
• Key generation is as important as algorithm selection.
• A valid signature does not indicate that the key was generated securely.
• Security claims must be evaluated against a realistic threat model.
• Operational controls and cryptographic controls must work together.

10. Professional Best Practices

A diploma-level practitioner should adopt the following principles:

• use well-reviewed, current cryptographic libraries rather than implementing primitives independently;
• select algorithms and parameters recommended by recognized standards bodies;
• use authenticated encryption for new applications unless a justified alternative exists;
• use CSPRNGs for keys, salts, and nonces, and obey algorithm-specific nonce rules;
• never treat encoding or obfuscation as confidentiality;
• separate keys by purpose and limit their privileges;
• protect private keys with least privilege, hardware protection, and audited recovery procedures;
• document the threat model and security assumptions;
• plan for key rotation, compromise, revocation, backup, and secure destruction;
• validate inputs and handle cryptographic errors safely;
• monitor dependencies and prepare for algorithm migration, including post-quantum developments;
• test the complete system, including user interfaces and operational processes.

11. Ethical, Governance, and Regulatory Considerations

Cryptographic security has social and organizational consequences. Poor key management can cause irreversible financial loss. Strong encryption can protect privacy, personal safety, trade secrets, and democratic participation, but organizations may also face lawful access, data protection, retention, and incident-reporting obligations.

Professionals should avoid overstating security claims. Statements such as “unbreakable” are generally inappropriate because security depends on assumptions and implementation. Documentation should identify what is protected, from whom, for how long, and under what conditions. Organizations should also consider accessibility and recovery: a system that is secure but unusable may encourage unsafe workarounds.

Privacy-preserving technologies should be assessed for both legitimate benefits and possible misuse. Governance should address authorization, auditability, responsible disclosure, separation of duties, and clear accountability for key custody.

Chapter Summary

Cryptography transforms information to provide security properties under explicit assumptions. Plaintext is transformed into ciphertext by encryption using a key, while hashing produces a fixed-length digest intended for integrity and verification rather than confidentiality. Encoding changes representation without secrecy, and obfuscation increases difficulty of analysis without providing dependable cryptographic protection.

Security depends on high-quality keys, adequate entropy, unpredictable randomness, appropriate security parameters, and realistic threat models. Computational hardness means that attacks are infeasible within an assumed resource model, not logically impossible. Kerckhoffs’s principle requires cryptosystems to remain secure when algorithms are public and keys remain secret.

In blockchain, hashes, digital signatures, and Merkle structures support integrity, authorization, and efficient verification. Nevertheless, cryptography cannot repair compromised endpoints, deceptive interfaces, weak recovery procedures, predictable randomness, or failures of availability. Professional security therefore combines sound algorithms with secure implementation, key management, governance, monitoring, and user-aware operational controls.

Key Terms

Plaintext: Original readable data before cryptographic transformation.

Ciphertext: Transformed data intended to conceal plaintext from unauthorized parties.

Key: Secret or public information controlling a cryptographic operation.

Symmetric cryptography: Cryptography using a shared secret key for related encryption and decryption operations.

Asymmetric cryptography: Cryptography based on mathematically related public and private keys.

Encryption: A keyed transformation intended primarily to provide confidentiality.

Decryption: The process of recovering plaintext from ciphertext using the appropriate key.

Hash function: A function mapping arbitrary-length input to a fixed-length digest.

Preimage resistance: Difficulty of finding an input that produces a specified hash output.

Collision resistance: Difficulty of finding two different inputs with the same hash output.

Encoding: Conversion of data into another representation without providing secrecy.

Obfuscation: Making code or data harder to understand without dependable cryptographic confidentiality.

Entropy: A measure of uncertainty or unpredictability in a random variable or secret.

CSPRNG: A cryptographically secure pseudorandom number generator.

Security parameter: A value representing the intended computational security level.

Computational hardness: The practical infeasibility of solving a problem with available resources.

Threat model: A structured description of attacker goals, capabilities, resources, and assumptions.

Kerckhoffs’s principle: The principle that security should depend on secret keys, not secret algorithms.

Nonce: A value intended for limited or single use in a cryptographic operation.

Digital signature: A private-key-generated value that can be verified using a corresponding public key.

Review Questions

5 Short Answer Questions

1. What is the difference between plaintext and ciphertext?
2. Why is Base64 not an encryption method?
3. State two important properties of a cryptographic hash function.
4. What does Kerckhoffs’s principle require?
5. Why is a CSPRNG important in blockchain wallet generation?

5 Long Answer Questions

1. Compare symmetric and asymmetric cryptography, including their strengths, limitations, and blockchain applications.
2. Explain entropy and distinguish high entropy from merely having a large-looking key representation.
3. Describe computational hardness, security parameters, and the role of threat models in evaluating cryptographic security.
4. Explain why encryption alone may not provide integrity or authenticity, and discuss authenticated encryption.
5. Discuss at least five ways in which implementation or operational failures can undermine a secure cryptographic algorithm.

3 Analytical / Application Questions

1. A wallet application hashes the user’s birth date and uses the result as a private key. Analyze the security failure and recommend a replacement design.
2. A company encrypts customer records but leaves file names, timestamps, and employee identifiers visible. What information may still leak, and what additional controls could reduce the risk?
3. A blockchain transaction has a valid digital signature, but the user was tricked by a malicious interface into signing it. Explain what the signature proves, what it does not prove, and how wallet and governance design could reduce this risk.

Multiple Choice Questions with Answers

Question 1

Which statement best describes plaintext?

A. Data after encryption

B. The original readable information before cryptographic transformation

C. A fixed-length hash digest

D. A public verification key

Correct Answer: B. The original readable information before cryptographic transformation

Question 2

What is the primary purpose of encoding such as Base64?

A. To provide confidentiality

B. To generate cryptographic keys

C. To represent data in a compatible transmission format

D. To prevent hash collisions

Correct Answer: C. To represent data in a compatible transmission format

Question 3

Which property makes it difficult to find two different messages with the same hash output?

A. Collision resistance

B. Nonce uniqueness

C. Key rotation

D. Encoding reversibility

Correct Answer: A. Collision resistance

Question 4

For an ideal n-bit hash function, the approximate generic work factor for finding a collision is:

A. 2^n operations

B. n operations

C. 2n operations

D. 2^(n/2) operations

Correct Answer: D. 2^(n/2) operations

Question 5

What is the central idea of Kerckhoffs’s principle?

A. The algorithm must remain secret forever

B. Security should depend on the secrecy of the key rather than the algorithm

C. All keys should be publicly published

D. Obfuscation is stronger than encryption

Correct Answer: B. Security should depend on the secrecy of the key rather than the algorithm

Question 6

Which item is most directly intended to provide unpredictable cryptographic output?

A. A CSPRNG

B. A Base64 encoder

C. A code obfuscator

D. A file-compression utility

Correct Answer: A. A CSPRNG

Question 7

What does a digital signature primarily demonstrate?

A. That the signed content is confidential

B. That the content was compressed efficiently

C. That a corresponding private key authorized the signature, assuming the key is controlled securely

D. That the signer cannot have been deceived

Correct Answer: C. That a corresponding private key authorized the signature, assuming the key is controlled securely

Question 8

A system hashes a timestamp and uses the result as a private key. What is the principal weakness?

A. The hash output is too short by definition

B. The timestamp may have low and predictable entropy

C. Hash functions always reveal their inputs

D. Public keys cannot be derived from hashes

Correct Answer: B. The timestamp may have low and predictable entropy

Question 9

Which security property is not normally guaranteed by encryption alone?

A. Confidentiality

B. Integrity against modification

C. Concealment of plaintext

D. Protection from unauthorized reading

Correct Answer: B. Integrity against modification

Question 10

What does a threat model specify?

A. Only the programming language used by an application

B. Only the size of a cryptographic key

C. Attacker goals, capabilities, resources, and relevant assumptions

D. The visual design of a wallet interface

Correct Answer: C. Attacker goals, capabilities, resources, and relevant assumptions