Cryptography & Blockchain Security

Chapter 2
Mathematical Foundations and Cryptographic Models

Advance Diploma in Blockchain
Cryptography & Blockchain Security   •   Advance Diploma

Mathematical Foundations and Cryptographic Models

Introduction and Context

Cryptography is the mathematical discipline used to protect information and communications in the presence of adversaries. Blockchain systems depend on cryptography for public-key identities, digital signatures, hash-linked data structures, consensus mechanisms, address generation, and transaction integrity. However, cryptographic mechanisms are not secure merely because they use sophisticated mathematics. Their security depends on precisely defined assumptions, correctly implemented algorithms, appropriate parameter sizes, and a clear model of what an attacker can compute or observe.

This chapter develops the mathematical foundations required to analyse blockchain security. It introduces modular arithmetic, prime numbers, greatest common divisors, finite fields, elliptic curves, entropy, and computational-hardness assumptions. It then distinguishes three important security viewpoints: information-theoretic security, computational security, and provable security.

The central principle is that cryptography transforms mathematical problems into security mechanisms. For example, a blockchain may publish a public key while relying on the practical difficulty of recovering its private key. A hash function may be publicly computable while relying on the difficulty of finding a collision. A digital signature may be easy to verify while being computationally infeasible to forge without secret information.

Learning Objectives

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

  1. Apply modular arithmetic and the Euclidean algorithm to cryptographic calculations.
  2. Explain the roles of prime numbers, coprimality, inverses, and Euler’s theorem.
  3. Describe finite fields and distinguish prime fields from binary extension fields.
  4. Explain elliptic-curve groups and their relevance to blockchain public-key cryptography.
  5. Calculate and interpret entropy in cryptographic key generation.
  6. Explain computational-hardness assumptions, including factoring and discrete logarithms.
  7. Distinguish information-theoretic, computational, and provable security.
  8. Evaluate cryptographic choices in a practical blockchain scenario.

1. Mathematical Language for Cryptography

Cryptographic mathematics commonly uses sets, functions, groups, rings, and fields. A set is a collection of objects. A binary operation combines two elements of a set and produces another element. Algebraic structures become useful in cryptography because they support repeatable operations, inverses, and precisely defined computational problems.

A group is a set G with an operation satisfying closure, associativity, an identity element, and inverses. If the operation is also commutative, the group is abelian. Many cryptographic constructions use finite abelian groups because their elements can be represented and manipulated efficiently while certain inverse problems remain difficult.

A ring supports addition and multiplication, while a field is a ring in which every non-zero element has a multiplicative inverse. Finite fields are particularly important because all operations remain within a finite, precisely defined set.

Cryptographic notation often distinguishes:

  • Plaintext: the original message.
  • Ciphertext: the transformed message.
  • Key: secret or public information controlling a cryptographic operation.
  • Encryption: transformation from plaintext to ciphertext.
  • Decryption: recovery of plaintext from ciphertext.
  • Hash function: a deterministic function mapping arbitrary input to a fixed-length output.
  • Adversary: an entity attempting to violate confidentiality, integrity, authenticity, or availability.

2. Modular Arithmetic

Modular arithmetic studies numbers with respect to a modulus. Two integers a and b are congruent modulo n when they have the same remainder after division by n:

a ≡ b (mod n) ⇔ n | (a − b)

Here, n is a positive integer and n | (a − b) means that n divides a − b exactly. The expression a mod n denotes the remainder in the range 0 through n − 1.

For example, 29 mod 7 = 1 because 29 = 4 × 7 + 1. Therefore, 29 ≡ 1 (mod 7). Congruence is preserved under addition, subtraction, and multiplication:

(a + b) mod n = ((a mod n) + (b mod n)) mod n
(ab) mod n = ((a mod n)(b mod n)) mod n

These rules allow large computations to be reduced at every step. This is essential in public-key cryptography, where exponents and intermediate values may be extremely large.

Worked Example 1: Modular Exponentiation

Calculate 3⁵ mod 7.

3² = 9 ≡ 2 (mod 7)

3⁴ ≡ 2² = 4 (mod 7)

3⁵ ≡ 3⁴ × 3 ≡ 4 × 3 = 12 ≡ 5 (mod 7)

Therefore, 3⁵ mod 7 = 5. In real cryptographic systems, repeated squaring performs this calculation efficiently even when the exponent contains hundreds or thousands of bits.

Multiplicative Inverses

A number a has a multiplicative inverse modulo n if there exists an integer x such that:

ax ≡ 1 (mod n)

The inverse exists if and only if gcd(a, n) = 1; that is, a and n are relatively prime. The inverse is written a⁻¹ mod n.

For example, the inverse of 3 modulo 7 is 5 because 3 × 5 = 15 ≡ 1 (mod 7). By contrast, 2 has no inverse modulo 6 because gcd(2, 6) = 2 rather than 1.

The Euclidean Algorithm

The greatest common divisor of two integers can be found using repeated division:

gcd(a, b) = gcd(b, a mod b)

until the remainder is zero.

To calculate gcd(252, 105):

252 = 2 × 105 + 42

105 = 2 × 42 + 21

42 = 2 × 21 + 0

Therefore, gcd(252, 105) = 21.

The extended Euclidean algorithm also finds integers x and y satisfying Bézout’s identity:

ax + by = gcd(a, b)

When gcd(a, n) = 1, the coefficient x, reduced modulo n, is the modular inverse of a. This algorithm is used in RSA key generation, signature systems, and finite-field calculations.

Euler’s Totient Function and Euler’s Theorem

Euler’s totient function φ(n) counts the positive integers less than or equal to n that are relatively prime to n. If p is prime, then:

φ(p) = p − 1

If p and q are distinct primes:

φ(pq) = (p − 1)(q − 1)

For gcd(a, n) = 1, Euler’s theorem states:

aφ(n) ≡ 1 (mod n)

This theorem explains part of the mathematical structure behind RSA. It does not, by itself, guarantee RSA security; security also depends on key generation, padding, implementation, and the assumed difficulty of factoring a large composite number.

Worked Example 2: Finding an Inverse

Find the inverse of 7 modulo 26.

Using the Euclidean algorithm:

26 = 3 × 7 + 5

7 = 1 × 5 + 2

5 = 2 × 2 + 1

Back-substitution gives:

1 = 5 − 2 × 2

1 = 5 − 2(7 − 5) = 3 × 5 − 2 × 7

1 = 3(26 − 3 × 7) − 2 × 7 = 3 × 26 − 11 × 7

Thus −11 × 7 ≡ 1 (mod 26), so 7⁻¹ ≡ 15 (mod 26). Verification: 7 × 15 = 105 ≡ 1 (mod 26).

3. Prime Numbers and Cryptographic Structure

A prime number is an integer greater than 1 with exactly two positive divisors: 1 and itself. Every integer greater than 1 has a unique factorisation into primes, apart from the ordering of factors. This is the fundamental theorem of arithmetic.

Prime numbers are important because they generate useful algebraic structures and support hard computational problems. RSA uses a modulus formed by multiplying two large primes. Finite-field systems often use a prime modulus p. Elliptic-curve systems may be defined over a field with a prime number of elements.

The security of a cryptosystem does not arise from the secrecy of the prime numbers in every design. In RSA, the modulus is public, but its factorisation is intended to be difficult. In elliptic-curve cryptography, the public parameters and public key are visible, while recovering the private scalar from the public point is intended to be difficult.

Primality testing determines whether a number is prime. Modern systems use efficient probabilistic tests, such as Miller–Rabin, followed where necessary by stronger verification. A probabilistic primality test may have a controllable error probability; it is not the same as randomly guessing whether a number is prime.

Probability of Random Prime Selection

For large integers near x, the prime number theorem suggests that the probability that a randomly selected integer is prime is approximately:

P(prime near x) ≈ 1 / ln(x)

Here ln(x) is the natural logarithm. This is an approximation for density, not a guarantee for any individual integer. Cryptographic libraries therefore generate candidates and test them rather than assuming that a selected number is prime.

4. Finite Fields

A finite field is a field containing a finite number of elements. The number of elements must be a prime power q = pᵐ, where p is prime and m is a positive integer. A finite field is commonly denoted GF(q) or 𝔽q.

Prime Fields

The simplest finite field is 𝔽p, whose elements are the integers 0, 1, …, p − 1 with addition and multiplication performed modulo p. When p is prime, every non-zero element has a multiplicative inverse.

For example, in 𝔽₅:

  • 3 + 4 = 7 ≡ 2 (mod 5)
  • 2 × 4 = 8 ≡ 3 (mod 5)
  • 2⁻¹ = 3 because 2 × 3 = 6 ≡ 1 (mod 5)

Extension Fields

Fields such as 𝔽₂ᵐ contain 2ᵐ elements. Their elements are represented as polynomials with coefficients in 𝔽₂, where addition is equivalent to bitwise XOR. Multiplication is polynomial multiplication followed by reduction using an irreducible polynomial.

Binary fields have historically been used in some elliptic-curve systems and error-correcting applications. Contemporary blockchain systems commonly use prime-field elliptic curves, but the distinction remains important when analysing cryptographic standards and legacy systems.

A polynomial is irreducible over a field if it cannot be expressed as the product of two lower-degree non-constant polynomials over that field. Irreducibility plays a role analogous to primality: it allows construction of a field rather than merely a ring with zero divisors.

5. Elliptic-Curve Groups

An elliptic curve over a prime field 𝔽p can be written in short Weierstrass form as:

y² ≡ x³ + ax + b (mod p)

where a, b ∈ 𝔽p. To define a suitable non-singular curve, the discriminant condition must hold:

4a³ + 27b² ≠ 0 (mod p)

The curve consists of all field points (x, y) satisfying the equation, together with a special identity element called the point at infinity, commonly written O.

Points on a suitable elliptic curve form an abelian group under a geometrically defined addition operation. The identity is O, and the inverse of P = (x, y) is −P = (x, −y mod p).

For distinct points P = (x₁, y₁) and Q = (x₂, y₂), where x₁ ≠ x₂, the slope is:

λ ≡ (y₂ − y₁)(x₂ − x₁)⁻¹ (mod p)

The resulting point R = P + Q has coordinates:

x₃ ≡ λ² − x₁ − x₂ (mod p)
y₃ ≡ λ(x₁ − x₃) − y₁ (mod p)

For point doubling, P = Q, the slope becomes:

λ ≡ (3x₁² + a)(2y₁)⁻¹ (mod p)

These formulas apply when the required modular inverses exist and the curve is non-singular. Special cases, such as adding a point to its inverse or doubling a point with y-coordinate zero, must be handled according to the group law.

Scalar Multiplication

Scalar multiplication repeatedly adds a point to itself:

kP = P + P + ⋯ + P

with k positive additions conceptually, although efficient double-and-add algorithms reduce the number of operations to approximately O(log k). In elliptic-curve cryptography, a private key is a scalar k and the public key is Q = kG, where G is a publicly specified generator point.

The forward operation is efficient. The reverse problem—recovering k from G and Q—is the elliptic-curve discrete logarithm problem (ECDLP). Security depends on the absence of an efficient general algorithm for solving ECDLP on the selected curve and group.

Worked Example 3: Point Addition in a Small Field

Consider the curve y² ≡ x³ + 2x + 2 (mod 17), and points P = (5, 1) and Q = (6, 3). First verify that they lie on the curve:

For P: 1² = 1, while 5³ + 2(5) + 2 = 137 ≡ 1 (mod 17).

For Q: 3² = 9, while 6³ + 2(6) + 2 = 230 ≡ 9 (mod 17).

The slope is:

λ ≡ (3 − 1)(6 − 5)⁻¹ ≡ 2 × 1⁻¹ ≡ 2 (mod 17)

Then:

x₃ ≡ 2² − 5 − 6 = −7 ≡ 10 (mod 17)

y₃ ≡ 2(5 − 10) − 1 = −11 ≡ 6 (mod 17)

Therefore, P + Q = (10, 6). This small example demonstrates the arithmetic; real cryptographic curves use much larger fields and carefully standardised parameters.

6. Entropy and Randomness

Entropy measures uncertainty. In cryptography, high-quality entropy is required for private keys, nonces, salts, initialisation values, and random primes. A cryptographic algorithm can be mathematically sound yet insecure if its secret values are predictable.

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

H(X) = −∑ᵢ p(xᵢ) log₂ p(xᵢ)

The unit is bits when the logarithm is base 2. If X is uniformly distributed over N outcomes, then:

H(X) = log₂ N

For a uniformly random b-bit value, the ideal entropy is b bits. This statement assumes every one of the 2ᵇ values is equally likely and generated independently enough for the intended security model.

Entropy is not the same as the length of a string. A 256-character password selected from a predictable list may have far less entropy than a shorter value generated uniformly by a secure random-number generator.

Example: Dice-Based Entropy

A fair six-sided die produces:

H = log₂ 6 ≈ 2.585 bits

A sequence of n independent rolls has approximately 2.585n bits of entropy. Independence matters: if later rolls are predictable from earlier rolls, the actual entropy is lower.

Cryptographic operating systems use entropy sources such as hardware randomness, timing variation, and device events, but these sources must be collected and conditioned carefully. Developers should use a cryptographically secure pseudorandom number generator (CSPRNG), not a general-purpose pseudo-random function designed for simulation.

7. Computational-Hardness Assumptions

A computational-hardness assumption states that a problem is feasible to solve in one direction but infeasible to reverse or exploit within the available resources. “Infeasible” is contextual: it depends on time, memory, hardware, parallelism, energy, and the expected value of an attack.

Important assumptions include:

  • Integer factorisation assumption: factoring a large composite integer is computationally difficult for suitably selected parameters.
  • Discrete logarithm assumption: given g and h = gˣ in a group, recovering x is difficult.
  • Elliptic-curve discrete logarithm assumption: given G and Q = kG, recovering k is difficult for a suitable elliptic-curve group.
  • Collision-resistance assumption: finding x ≠ y such that H(x) = H(y) is computationally difficult for a suitable hash function.
  • Preimage-resistance assumption: given y = H(x), finding an input mapping to y is computationally difficult.

These assumptions are not mathematical proofs that no attack exists. They are carefully evaluated beliefs supported by cryptanalysis, reductions, security margins, and the absence of known efficient algorithms.

Security Levels and Generic Attacks

If a key space contains 2ᵏ equally likely possibilities and the best generic attack tests candidates, exhaustive search requires approximately 2ᵏ trials in the worst case and about 2ᵏ⁻¹ trials on average. A key with k bits of ideal entropy therefore offers approximately k bits of brute-force security against this attack model.

Hash collision attacks have a generic birthday-bound cost of approximately 2ⁿᐟ² evaluations for an n-bit hash output. This is why collision security is commonly described as roughly half the output length, while preimage security is ideally closer to n bits. These are idealised estimates and can be weakened by structural attacks or poor implementation.

8. Cryptographic Security Models

Security claims must identify what is being protected, what the adversary can do, and what probability or resource limit is acceptable.

Comparison of cryptographic security models Information-theoretic Computational Provable Secure even with unlimited computational power Example: one-time pad Secure against feasible adversaries under assumptions Example: ECDLP-based keys Reduction from attacking a scheme to a hard problem Example: security theorem Security claims require explicit assumptions and adversary models
Comparison of information-theoretic, computational, and provable security models
Figure: Comparison of information-theoretic, computational, and provable security models

Figure: Three complementary ways of expressing cryptographic security.

Information-Theoretic Security

A system has information-theoretic security when security holds even against an adversary with unlimited computational power. The classic example is the one-time pad. If the key is truly random, at least as long as the message, used only once, and kept secret, the ciphertext reveals no information about the plaintext in the ideal model.

For a message M and ciphertext C, perfect secrecy can be expressed as:

P(M = m | C = c) = P(M = m)

for all messages m and ciphertexts c with positive probability. The one-time pad achieves this only under strict conditions. Key reuse destroys the guarantee, and secure key distribution may be impractical at blockchain scale.

Computational Security

Computational security assumes that adversaries have bounded resources. A cryptosystem is computationally secure if the probability of successful attack is negligible relative to the permitted computational resources and security parameters.

Computational security is the practical basis of most blockchain cryptography. Digital signatures, public-key encryption, and hash functions are not secure against an infinitely powerful adversary. They are designed so that currently feasible attacks are economically and technically impractical.

Provable Security

Provable security usually means that an attack on a construction can be transformed into an attack on an underlying assumption. A typical reduction states: if an adversary can break scheme S with non-negligible probability, then a simulator can solve problem P with related probability and manageable computational overhead. If P is believed hard, S is supported by the reduction.

A proof is meaningful only when its assumptions, security definition, parameter regime, and reduction are appropriate. A proof may cover confidentiality but not side-channel leakage, implementation errors, weak randomness, poor key storage, or an unsuitable protocol composition. “Provably secure” therefore does not mean universally secure.

9. Cryptographic Models Used in Blockchain

Blockchain systems combine several security goals:

  • Integrity: unauthorised changes to confirmed data should be detectable.
  • Authenticity: a transaction should be attributable to possession of the relevant signing key.
  • Non-repudiation in a technical sense: a valid signature provides evidence that the corresponding private key produced it, although legal non-repudiation requires broader evidential and jurisdictional analysis.
  • Availability: users should be able to submit and verify transactions.
  • Confidentiality: information should be hidden where the protocol promises privacy; many public blockchains do not provide transaction confidentiality by default.

A blockchain hash pointer does not prove that data are true; it proves that a later record depends computationally on an earlier digest. A digital signature does not prove that a person acted freely or that an asset exists; it proves possession or use of a key under the signature model. Correct interpretation prevents overclaiming.

Public-key blockchain systems typically use a key-generation algorithm, a signing algorithm, and a verification algorithm. A secure signature scheme aims to satisfy existential unforgeability under chosen-message attack (EUF-CMA): even after obtaining signatures on messages selected by the adversary, the adversary should not be able to produce a valid signature on a new message.

Hash-based constructions require domain separation, unambiguous encoding, secure parameter choices, and careful treatment of length-extension or malleability issues where relevant. Protocol designers should use standardised constructions rather than inventing combinations of primitives.

10. Applied Case: Choosing Keys for a Blockchain Wallet

Background

This illustrative case concerns a software team developing a custodial wallet for a blockchain that uses elliptic-curve digital signatures. The wallet will generate keys on servers, sign transactions, and maintain audit records.

Problem

An initial prototype uses a general-purpose pseudo-random generator seeded with the current time. The team also proposes storing private keys in application logs temporarily to simplify debugging. These choices create risks even if the underlying elliptic-curve mathematics is sound.

Analysis

A time-based seed has low and potentially guessable entropy. If an attacker can estimate the creation time, the effective search space may be dramatically smaller than the nominal private-key size. Logging private keys creates a second exposure path through log aggregation, backups, monitoring tools, and employee access.

The relevant security model is computational security: the attacker is assumed to have bounded but substantial resources. The desired security claim depends on a secure key-generation process, protection of private keys, correct signature implementation, and resistance to operational compromise.

Approach and Solution

The team replaces the generator with an operating-system CSPRNG, validates that the generated scalar lies in the permitted range, and uses a vetted cryptographic library. Private keys are generated inside a hardware security module where possible, or encrypted under separately managed keys. Debugging uses synthetic test keys, never production secrets. Transaction signing is separated from general application services, and access is logged without recording secret material.

The team also defines a threat model covering malicious insiders, compromised application servers, replay attempts, unavailable signing services, and future cryptanalytic advances. Key rotation and recovery procedures are tested before deployment.

Outcome

The mathematical primitive remains unchanged, but the effective security of the system improves because the implementation now satisfies the assumptions on which the primitive depends. The organisation also gains auditable controls and a practical incident-response procedure.

Learning Points

  1. Cryptographic strength is limited by the weakest component, including randomness and key storage.
  2. Nominal key length does not compensate for predictable generation.
  3. Security claims must specify the adversary and operational assumptions.
  4. Hardware protection, access control, logging discipline, and recovery planning are part of blockchain security.
  5. A security proof for a signature algorithm does not prove that a wallet deployment is secure.

11. Limitations, Governance, and Contemporary Developments

Mathematical security models simplify reality. They may not capture side-channel attacks based on timing, power consumption, electromagnetic leakage, cache behaviour, fault injection, or induced errors. They may also ignore social engineering, lost credentials, insider abuse, vulnerable dependencies, and governance failures.

Blockchain organisations should maintain cryptographic agility: the capacity to replace algorithms, parameters, and key formats without unacceptable disruption. This is important because new cryptanalysis, hardware advances, and quantum computing may change security estimates. Large-scale quantum computers would threaten widely used public-key systems through Shor’s algorithm for factoring and discrete logarithms. Grover’s algorithm would provide a quadratic speed-up for generic search, affecting symmetric keys and hash preimage estimates; increasing parameter sizes can partly mitigate this effect.

Post-quantum cryptography studies schemes intended to resist known quantum attacks. Lattice-based, hash-based, code-based, and multivariate approaches are among the principal families, although each introduces different assumptions, key sizes, performance characteristics, and implementation risks. Migration should be planned before a cryptographically relevant quantum computer exists because public keys and signed data may be collected now for future decryption or forgery attempts.

Governance should include approved algorithms, minimum parameters, secure randomness requirements, key lifecycle controls, independent review, incident response, and deprecation procedures. Compliance requirements vary by jurisdiction and sector, but sound governance consistently requires documented assumptions and evidence that implementations conform to approved standards.

Best Practices

  • Use established, peer-reviewed cryptographic libraries and protocols.
  • Never design a new primitive or ad hoc cryptographic combination for production without specialist review.
  • Generate secrets with a CSPRNG and test the entire entropy path.
  • Record key-generation, storage, rotation, revocation, and destruction procedures.
  • Separate public identifiers from private key material.
  • Use constant-time implementations where secret-dependent timing could leak information.
  • Validate curve parameters, subgroup membership, and input encodings as required by the protocol.
  • Treat nonces as critical secrets in signature schemes that require unique or unpredictable nonces.
  • State the security model and assumptions for every important security claim.
  • Plan for algorithm migration and post-quantum transition.

Chapter Summary

Modular arithmetic provides the operational language for many cryptographic algorithms. Congruence, modular inverses, the Euclidean algorithm, Euler’s totient function, and Euler’s theorem explain essential properties of public-key systems. Prime numbers support finite fields and difficult factorisation problems, while finite fields provide closed arithmetic environments for cryptographic operations.

Elliptic curves create finite abelian groups in which scalar multiplication is efficient but reversing the operation is intended to be difficult. This asymmetry supports blockchain public keys and digital signatures. Entropy measures uncertainty and is fundamental to secure key generation; a long but predictable value is not a secure secret.

Cryptographic security may be information-theoretic, computational, or provable. Information-theoretic security remains valid against unlimited computation but often requires impractical resources. Computational security is based on bounded adversaries and hardness assumptions. Provable security connects attacks on a construction to attacks on an assumed-hard problem, but its scope is limited by the proof and its assumptions.

Blockchain security depends not only on mathematical primitives but also on randomness, implementation, key management, protocol composition, governance, and migration planning. Sound engineering therefore requires both mathematical understanding and disciplined operational controls.

Key Terms

Modular arithmetic: Arithmetic in which numbers are considered with respect to a fixed modulus.

Congruence: A relation indicating that two integers have the same remainder modulo a specified modulus.

Greatest common divisor: The largest positive integer dividing two or more integers.

Modular inverse: A value that multiplies with another value to produce 1 modulo n.

Euler’s totient function: The number of positive integers up to n that are relatively prime to n.

Prime number: An integer greater than 1 with exactly two positive divisors.

Finite field: A field containing a finite number of elements.

Prime field: A finite field with p elements, where p is prime.

Irreducible polynomial: A polynomial that cannot be factored into lower-degree non-constant polynomials over a specified field.

Elliptic curve: A non-singular algebraic curve used to construct a finite abelian group.

Scalar multiplication: Repeated addition of an elliptic-curve point by an integer scalar.

Discrete logarithm problem: The problem of recovering an exponent from a group exponentiation or scalar multiplication.

Entropy: A measure of uncertainty in a random variable.

CSPRNG: A cryptographically secure pseudorandom number generator.

Computational-hardness assumption: A belief that a specified problem cannot be solved efficiently with available resources.

Information-theoretic security: Security that holds even against an adversary with unlimited computation.

Computational security: Security defined against adversaries with bounded computational resources.

Provable security: Security supported by a reduction from breaking a scheme to solving an assumed-hard problem.

Cryptographic agility: The ability to replace cryptographic algorithms or parameters safely as requirements change.

Threat model: A structured description of assets, adversaries, capabilities, assumptions, and security goals.

Review Questions

Short Answer Questions

  1. What condition is necessary and sufficient for a modular inverse of a modulo n to exist?
  2. Why are prime numbers important in finite-field cryptography?
  3. What does entropy measure in the context of cryptographic key generation?
  4. Define the elliptic-curve discrete logarithm problem.
  5. What is the principal difference between computational and information-theoretic security?

Long Answer Questions

  1. Explain the Euclidean and extended Euclidean algorithms and show how the latter can be used to find a modular inverse.
  2. Describe the construction and properties of a finite field 𝔽p.
  3. Explain elliptic-curve point addition, point doubling, and scalar multiplication, including the role of modular inverses.
  4. Compare information-theoretic, computational, and provable security, including one advantage and one limitation of each.
  5. Discuss why secure randomness and key management are necessary even when a blockchain uses a mathematically strong signature algorithm.

Analytical / Application Questions

  1. A wallet generates private keys using a time-seeded pseudorandom generator. Analyse the security failure using entropy and computational-hardness concepts, and propose a corrected design.
  2. A blockchain team claims that a digital signature proves the real-world identity and intention of the signer. Evaluate this claim and distinguish mathematical authenticity from legal or organisational attribution.
  3. Design a threat model for migrating a blockchain from an elliptic-curve signature system to a post-quantum signature system. Identify assumptions, assets, attack capabilities, transition risks, and governance controls.

Multiple Choice Questions with Answers

Question 1

What is the value of 3⁵ mod 7?

A. 2

B. 3

C. 5

D. 6

Correct Answer: C. 5

Question 2

A modular inverse of a modulo n exists exactly when:

A. a is larger than n

B. gcd(a, n) = 1

C. n is even

D. a and n are both composite

Correct Answer: B. gcd(a, n) = 1

Question 3

Which algorithm can find both gcd(a, b) and coefficients satisfying Bézout’s identity?

A. Extended Euclidean algorithm

B. Miller–Rabin test

C. Double-and-add algorithm

D. Birthday algorithm

Correct Answer: A. Extended Euclidean algorithm

Question 4

How many elements does the prime field 𝔽₁₇ contain?

A. 16

B. 17

C. 18

D. 34

Correct Answer: B. 17

Question 5

In elliptic-curve cryptography, a public key is commonly computed as:

A. Q = G + k

B. Q = kG

C. Q = Gᵏ using ordinary integer exponentiation

D. Q = k⁻¹G for every scheme

Correct Answer: B. Q = kG

Question 6

What is the ideal Shannon entropy of a uniformly random 256-bit value?

A. 128 bits

B. ริ่ม 256 bits

C. 512 bits

D. 64 bits

Correct Answer: B. ริ่ม 256 bits

Question 7

Which statement best describes information-theoretic security?

A. It depends only on current processor speed

B. It remains secure against an adversary with unlimited computational power under its stated conditions

C. It is always obtained from a security reduction

D. It requires a public blockchain

Correct Answer: B. It remains secure against an adversary with unlimited computational power under its stated conditions

Question 8

For an n-bit hash output, the generic birthday-bound cost of finding a collision is approximately:

A. 2ⁿ evaluations

B. n² evaluations

C. 2ⁿᐟ² evaluations

D. log₂ n evaluations

Correct Answer: C. 2ⁿᐟ² evaluations

Question 9

Which problem is directly associated with recovering a private scalar k from Q = kG?

A. Integer factorisation

B. Elliptic-curve discrete logarithm problem

C. Sorting

D. Polynomial interpolation only

Correct Answer: B. Elliptic-curve discrete logarithm problem

Question 10

Why does a security proof not automatically guarantee that a deployed wallet is secure?

A. Proofs cannot use mathematics

B. The proof may not cover randomness, key storage, side channels, or implementation errors

C. Wallets do not use keys

D. Security proofs apply only to information-theoretic systems

Correct Answer: B. The proof may not cover randomness, key storage, side channels, or implementation errors

Cryptography & Blockchain Security
Chapter 2 of 14