Asymmetric Cryptography and Digital Signatures

Introduction and Context

Blockchain systems must solve two related problems: identifying who is authorised to control an asset and proving that a message has not been altered. Asymmetric cryptography provides the foundation for both. Unlike symmetric cryptography, which uses one shared secret key, asymmetric cryptography uses a mathematically related public key and private key.

A public key may be distributed openly. A private key must remain secret. Ownership in a blockchain is therefore not normally established by a name or account number; it is established by the ability to produce a valid cryptographic signature using the relevant private key.

This chapter explains public–private key pairs, trapdoor functions, elliptic-curve cryptography (ECC), key exchange, digital signatures, verification, major blockchain signature schemes, and common attacks. It also considers operational, ethical, and governance issues involved in managing cryptographic keys.

Learning Objectives

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

• distinguish symmetric and asymmetric cryptography;
• explain public–private key pairs and trapdoor functions;
• describe elliptic-curve key generation and the role of scalar multiplication;
• explain key exchange and digital-signature workflows;
• verify ownership, integrity, and authenticity conceptually;
• compare RSA, ECDSA, EdDSA, Schnorr, and BLS signatures;
• identify common attacks and appropriate mitigations; and
• apply these ideas to a blockchain transaction scenario.

1. Public–Private Key Pairs

An asymmetric cryptosystem consists of algorithms for key generation, encryption or signing, and decryption or verification. Key generation produces a private key and a corresponding public key:

Here, sk is the secret or private key and pk is the public key. The security parameter determines the intended resistance to attack. A secure design makes it computationally infeasible to derive sk from pk.

For encryption, a sender encrypts a message with the recipient’s public key. Only the recipient’s private key should decrypt it. For signatures, the owner signs with the private key, and anyone can verify with the public key.

A signature scheme is commonly represented as:

In these expressions, m is the message and σ is the signature. Verification returns true only when the signature is valid for that message and public key.

A signature provides three important properties:

1. Integrity: alteration of the message normally causes verification to fail.
2. Authentication: the signature demonstrates control of the private key corresponding to the public key.
3. Non-repudiation, in a limited sense: a valid signature can provide evidence that a key holder authorised a message. However, legal non-repudiation depends on jurisdiction, identity binding, evidence, and key-management practices; cryptography alone does not prove the real-world identity of a person.

A blockchain address is often derived from a public key or from a script containing spending conditions. The address is not itself a private key, and possession of an address does not prove ownership. Control is demonstrated by satisfying the blockchain’s spending rule, usually by presenting a valid signature.

2. Trapdoor Functions

A trapdoor function is easy to compute in one direction but difficult to reverse without special secret information called the trapdoor. Public-key cryptography uses this asymmetry.

For example, RSA relies on the practical difficulty of factoring a large composite number. If two large primes are multiplied, computing the product is easy; recovering the primes from the product is believed to be difficult when parameters are properly chosen. The private key contains information that makes inversion efficient.

ECC uses a different hard problem: the elliptic-curve discrete logarithm problem. Given a base point G, a scalar d, and the point Q = dG, computing Q from d and G is efficient, while recovering d from Q is computationally infeasible for a suitably chosen curve and implementation.

These are computational assumptions, not mathematical impossibilities. Advances in algorithms, defective parameter choices, implementation errors, or sufficiently capable quantum computers could change the security situation. A cryptographic system is secure only under stated assumptions and correct implementation.

3. Elliptic-Curve Cryptography

An elliptic curve over a finite field is commonly represented by an equation such as:

Here, a and b define the curve, p is a prime modulus, and x and y are coordinates in the finite field. A valid curve must avoid singularities; one common condition is:

The points on the curve, together with a point at infinity, form an algebraic group. The group operation is called point addition. Repeated addition of a point is scalar multiplication:

Here, G is a publicly specified generator, d is a private scalar, and Q is the public key. The notation dG does not mean ordinary multiplication of coordinate values; it means adding G to itself d times using the curve’s group operation.

ECC achieves strong security with relatively small keys. This reduces storage, bandwidth, and computational cost, which is valuable for blockchain transactions and embedded devices. The benefit is not automatic: a recognised curve, secure random-number generation, validated public keys, and constant-time implementations are required.

Key Generation

A simplified ECC key-generation process is:

1. Select a cryptographically secure random integer d in the valid private-key range.
2. Compute Q = dG.
3. Publish Q or an address derived from it.
4. Protect d using secure storage, backups, and access controls.

The private key must never be generated from a predictable timestamp, password, or weak random source. If two users accidentally use the same private key, they control the same cryptographic identity.

4. Key Exchange

Encryption and signatures should not be confused. A digital signature proves that a private-key holder authorised data; it does not automatically make the data confidential.

A classic key-exchange technique is Diffie–Hellman. Alice chooses a secret value a and publishes A = aG. Bob chooses b and publishes B = bG. Each computes the same shared point:

Thus S_A = S_B. In practice, a key-derivation function converts the shared secret into symmetric encryption and authentication keys. The exchange must be authenticated; otherwise, a man-in-the-middle attacker can establish separate keys with Alice and Bob. Protocols such as authenticated TLS combine key exchange with certificates or signatures for this reason.

Blockchain networks may use key exchange for encrypted peer communication, wallet backup protocols, or second-layer applications. Ordinary transaction signing is generally an authentication and authorisation operation, not a confidential communication mechanism.

5. Digital Signatures in Blockchain Systems

A typical transaction-signing workflow is:

1. Construct a transaction containing inputs, outputs, amounts, fees, and relevant metadata.
2. Serialize it according to the protocol’s exact rules.
3. Hash the authorised transaction representation.
4. Sign the resulting message or digest with the private key.
5. Broadcast the transaction and signature.
6. Nodes reconstruct the signed message and verify the signature using the public key.
7. Nodes also check protocol rules, including balance, sequence number, script conditions, and prevention of replay where applicable.

Hashing is important because a signature scheme signs a fixed-size representation efficiently. A cryptographic hash should provide preimage resistance, second-preimage resistance, and collision resistance. A signature over one transaction representation is not necessarily valid over a differently encoded representation. Therefore, canonical serialization and domain separation are essential.

A valid signature does not by itself prove that a transaction is economically valid. It proves control of a key and authorisation of the signed message. The blockchain’s consensus rules determine whether the transaction is acceptable.

Ownership and Authenticity

In a cryptocurrency system, “ownership” usually means the ability to satisfy a spending condition. For a simple public-key condition, a node checks that:

• the public key matches the expected address or script;
• the signature verifies under that public key; and
• the transaction obeys all ledger and consensus rules.

Authenticity has two layers. Cryptographic authenticity connects a message to a private key. Operational or legal authenticity connects that key to a person, organisation, or device. The second connection requires identity verification, custody records, certificates, or other governance controls.

6. Major Signature Schemes

ECDSA

ECDSA uses a fresh secret nonce for every signature. At a high level, a signer selects nonce k, computes a curve point, and derives signature values from the message hash, private key, and k. The exact equations vary with the curve and standard. The critical engineering requirement is that k must be unpredictable and must not be reused across different messages. If the same nonce is reused, an attacker may derive the private key from the resulting signatures.

Schnorr Signatures

Schnorr signatures are based on a proof of knowledge of a discrete logarithm. Their algebraic structure supports multisignature constructions and signature aggregation more naturally than traditional ECDSA. However, combining signatures without a secure protocol can permit rogue-key attacks. Modern designs use participant commitments, key aggregation rules, and proof-of-possession or related safeguards.

BLS Signatures

BLS signatures use bilinear pairings and can aggregate multiple signatures into one compact value. This is useful where many validators must attest to the same block or message. Aggregation does not remove the need to identify which participants signed, and implementations must address rogue-key attacks, subgroup validation, and proof-of-possession.

7. Common Attacks and Defences

Private-Key Theft

Malware, phishing, exposed backups, cloud compromise, or insider abuse can reveal a private key. Defences include hardware wallets, hardware security modules, encrypted backups, threshold custody, multisignature policies, least privilege, and recovery testing.

Weak Randomness and Nonce Reuse

Predictable private keys or signature nonces can make brute-force recovery practical. Use a well-reviewed cryptographic random-number generator and, where supported, deterministic nonce generation such as standards-based deterministic ECDSA. Deterministic generation must itself be implemented correctly and separated by domain where necessary.

Man-in-the-Middle Attacks

Unauthenticated key exchange allows an attacker to substitute public keys. Use authenticated protocols, certificate validation, trusted fingerprints, or signatures binding keys to identities.

Replay Attacks

A valid transaction copied to another context may be accepted again if the protocol does not distinguish contexts. Chain identifiers, account sequence numbers, transaction counters, and domain-separated signing formats reduce replay risk.

Malleability and Serialization Attacks

If more than one valid encoding represents the same transaction, an attacker may alter the transaction identifier without changing its apparent economic effect. Strict encoding rules, canonical signatures, and protocol-specific malleability fixes are required.

Rogue-Key Attacks

In aggregate or multisignature systems, a participant may submit a specially chosen public key that mathematically cancels another participant’s key. Key aggregation must use a secure coefficient scheme, proof of possession, or an equivalent authenticated construction.

Side-Channel Attacks

Timing, power consumption, electromagnetic emissions, and cache behaviour can reveal secret-dependent information. Constant-time algorithms, blinding, hardened hardware, and careful isolation reduce exposure.

Quantum Threats

Large-scale quantum computers could threaten RSA and elliptic-curve systems through Shor’s algorithm. Hash functions are affected differently, generally requiring larger security margins rather than immediate total failure. Organisations should monitor post-quantum standards, inventory cryptographic dependencies, and plan migration paths without prematurely replacing proven systems.

8. Applied Case: A Small Business Wallet

The following is an illustrative case.

Background

A small online retailer accepts cryptocurrency. Its original practice is to store one private key in a desktop wallet and sign every withdrawal from that device.

Problem

An employee installs malware from a fraudulent software update. The attacker copies the wallet file and later transfers the retailer’s funds. The transaction is correctly signed, so the blockchain treats it as authorised.

Analysis

The cryptographic algorithms did not fail. The failure was key custody. The system equated possession of one software-stored private key with unrestricted operational authority. There was no separation of duties, withdrawal limit, hardware protection, or recovery procedure.

Approach and Solution

The retailer adopts a two-of-three multisignature policy. Three keys are held by separate authorised officers, with two required for a withdrawal. At least two keys are stored on hardware devices. Daily limits and an independent transaction-review process are introduced. Backups are encrypted, geographically separated, and periodically tested. The organisation documents who may approve transactions and how a lost key is replaced.

Outcome

Compromise of one device is no longer sufficient to move funds. The business accepts a small increase in operational complexity in exchange for substantially improved resilience.

Learning Points

Cryptographic strength cannot compensate for poor key management. A signature demonstrates possession of a key, not that the key was used according to organisational policy. Technical controls, governance, user training, and recovery planning must operate together.

9. Professional Practice and Governance

A sound key-management policy should specify key generation, storage, access, backup, rotation or migration, revocation where applicable, incident response, and secure destruction. Private keys should not be copied casually or stored in plaintext. Seed phrases require the same protection as private keys because they can regenerate many keys.

Organisations should maintain an inventory of algorithms, curves, libraries, wallets, and dependencies. They should define approval procedures for address changes, verify software authenticity, and use independent transaction review for high-value transfers. Smart contracts should not assume that all signatures have the same encoding, malleability properties, or verification cost.

Ethically, blockchain operators must communicate that irreversible transactions create unusual consumer risks. Custodians should explain whether customers control keys directly, how assets are recovered, and what happens after suspected compromise. Regulatory requirements vary by jurisdiction but may include anti-money-laundering controls, cybersecurity obligations, custody standards, and data-protection duties. Public-key data may be pseudonymous rather than anonymous, because transaction histories can often be linked through analysis.

Contemporary Developments

Modern blockchain designs increasingly use Schnorr signatures, threshold signatures, aggregate signatures, and account-abstraction mechanisms. These can reduce transaction size, improve privacy, or permit flexible authorisation policies. They also introduce new implementation risks, including aggregation errors, inadequate nonce coordination, subgroup attacks, and complex recovery logic.

Post-quantum migration is an emerging planning issue. Because blockchain data may remain publicly available for many years, an attacker could record public-key information today and attempt to exploit it later. Protocol designers therefore need upgrade mechanisms, key rotation strategies, and realistic assessments of performance, transaction size, and long-term security.

Chapter Summary

Asymmetric cryptography uses mathematically related public and private keys. Public keys can be shared, whereas private keys must be protected. Trapdoor assumptions make authorised operations practical while keeping unauthorised inversion computationally difficult. ECC obtains compact keys from the difficulty of the elliptic-curve discrete logarithm problem.

Key exchange establishes shared secrets but must be authenticated to prevent interception. Digital signatures provide integrity and cryptographic authentication; they do not, by themselves, prove a real-world identity or guarantee that a transaction is valid under consensus rules. Blockchain nodes verify signatures together with scripts, balances, sequence values, serialization rules, and other protocol conditions.

ECDSA is widely deployed but highly sensitive to nonce failures. EdDSA offers deterministic and efficient signing, Schnorr supports elegant multisignature constructions, and BLS supports compact aggregation. Private-key theft, weak randomness, replay, malleability, rogue-key, side-channel, and future quantum attacks require technical and organisational controls. Effective security is therefore a system property involving algorithms, implementations, custody, governance, and recovery.

Key Terms

Public key: The openly distributable part of an asymmetric key pair.

Private key: Secret value used for signing, decryption, or control of cryptographic assets.

Trapdoor function: A function that is easy to compute but difficult to reverse without secret information.

Digital signature: Cryptographic evidence binding a message to a private-key operation.

Verification: The process of checking a signature using a public key and message.

Elliptic-curve cryptography: Public-key cryptography based on algebraic operations on elliptic curves.

Scalar multiplication: Repeated elliptic-curve point addition, written dG.

Generator: A designated elliptic-curve point used to construct public keys.

Discrete logarithm problem: The problem of recovering a secret scalar from a public group element.

Key exchange: A protocol for establishing a shared secret over an exposed channel.

Nonce: A value intended for one-time use in a cryptographic operation.

Replay attack: Reuse of a valid message in an unintended context.

Malleability: The ability to modify a valid representation without invalidating its apparent meaning or validity.

Multisignature: An authorisation rule requiring signatures from multiple keys.

Threshold signature: A signature scheme in which a specified number of participants can jointly authorise an operation.

Schnorr signature: A discrete-logarithm-based signature with useful linear properties.

BLS signature: A pairing-based signature that supports aggregation.

Rogue-key attack: An attack exploiting maliciously selected public keys in key aggregation.

Side-channel attack: Extraction of secrets from implementation-dependent physical or behavioural leakage.

Review Questions

Short Answer Questions

1. What is the difference between a public key and a private key?
2. What does a blockchain node verify when checking a digital signature?
3. Why must a signature nonce normally be unpredictable and non-repeating?
4. How does authenticated key exchange prevent a man-in-the-middle attack?
5. Why does a valid signature not necessarily make a transaction valid?

Long Answer Questions

1. Explain trapdoor functions and compare the assumptions behind RSA and ECC.
2. Describe ECC key generation and explain why recovering the private scalar from the public key is difficult.
3. Compare ECDSA, EdDSA, Schnorr, and BLS signatures in terms of strengths and risks.
4. Explain how replay, malleability, and rogue-key attacks affect blockchain systems.
5. Design a professional key-management policy for a small organisation holding digital assets.

Analytical / Application Questions

1. A company stores one signing key on an internet-connected laptop. Analyse the risks and propose a layered replacement architecture.
2. A blockchain wants compact validator attestations from many participants. Evaluate whether BLS aggregation is suitable and identify the additional controls required.
3. A developer reuses the same ECDSA nonce for two transactions. Explain why this is dangerous and recommend engineering safeguards.

Multiple Choice Questions with Answers

Question 1

Which key is used to create a digital signature?

A. The recipient’s public key

B. The signer’s private key

C. A blockchain address

D. A hash value alone

Correct Answer: B. The signer’s private key

Question 2

In ECC, the public key is commonly computed as which expression?

A. Q = dG

B. Q = G ÷ d

C. Q = d + G using ordinary integer addition

D. Q = hash(d) only

Correct Answer: A. Q = dG

Question 3

What is the main purpose of signature verification?

A. To recover the private key

B. To encrypt the entire blockchain

C. To check that a signature matches a message and public key

D. To generate a new random nonce

Correct Answer: C. To check that a signature matches a message and public key

Question 4

Why is ECDSA nonce reuse dangerous?

A. It makes public keys confidential

B. It can allow recovery of the private key

C. It prevents hashing

D. It changes the elliptic curve

Correct Answer: B. It can allow recovery of the private key

Question 5

What is a principal purpose of authenticated key exchange?

A. Preventing all network congestion

B. Ensuring that exchanged keys are bound to the intended parties

C. Replacing digital signatures with passwords

D. Making private keys public

Correct Answer: B. Ensuring that exchanged keys are bound to the intended parties

Question 6

Which scheme is particularly associated with compact aggregate signatures using pairings?

A. RSA-PSS

B. ECDSA

C. BLS

D. AES

Correct Answer: C. BLS

Question 7

What does a replay attack involve?

A. Breaking a hash by changing its algorithm

B. Reusing a valid message in an unintended context

C. Physically destroying a hardware wallet

D. Generating two public keys from one curve point

Correct Answer: B. Reusing a valid message in an unintended context

Question 8

Which control directly reduces the impact of compromise of one wallet key?

A. Using a shorter password

B. Multisignature authorisation

C. Publishing the seed phrase

D. Disabling transaction review

Correct Answer: B. Multisignature authorisation

Question 9

What does scalar multiplication mean in elliptic-curve cryptography?

A. Ordinary multiplication of x and y coordinates

B. Repeated application of the curve’s point-addition operation

C. Multiplication of two private keys

D. Hashing a point several times

Correct Answer: B. Repeated application of the curve’s point-addition operation

Question 10

Which statement about a valid blockchain signature is correct?

A. It proves a government-certified identity in every case

B. It automatically proves that the transaction obeys consensus rules

C. It demonstrates control of the corresponding private key for the signed message

D. It guarantees that the private key was stored securely

Correct Answer: C. It demonstrates control of the corresponding private key for the signed message