Computer NetworksDigital Signatures

Digital Signatures

LevelIntermediate

Duration60 mins

TopicDigital Signatures

5 / 5

Applications

The Invisible Foundation of Digital Trust

Every time you open a web browser, install software, send a secure email, or execute a cryptocurrency transaction, digital signatures are working invisibly on your behalf. They verify that the website you're visiting is genuine, that the software update hasn't been corrupted by malware, that the email truly came from the claimed sender, and that the transaction was authorized by the legitimate owner.

Digital signatures have become so pervasive that modern digital life would be impossible without them. Yet most users never see them, never think about them, and have no idea they're being protected by mathematical proofs of authenticity millions of times each day.

In this final page of our digital signatures module, we explore the practical applications that transform cryptographic theory into real-world security. From the TLS protocol securing billions of connections to the emerging world of verifiable credentials and zero-knowledge proofs, digital signatures are the silent guardians of the digital age.

What You Will Learn

By the end of this page, you will understand how digital signatures secure TLS/HTTPS connections, the code signing ecosystem protecting software distribution, email authentication protocols (DKIM, S/MIME, PGP), blockchain and cryptocurrency transaction authorization, document signing standards for legal validity, API authentication with JWTs, and emerging applications in identity, IoT, and post-quantum security.

TLS/SSL Certificates: Securing the Web

The most visible application of digital signatures is in TLS (Transport Layer Security), the protocol that puts the 'S' in HTTPS. Every secure website presents a certificate—a digitally signed document binding a public key to a domain name.

How TLS Uses Digital Signatures:

1. Certificate Authentication: When you connect to https://bank.com:

The server presents its certificate containing its public key
The certificate is signed by a Certificate Authority (CA)
Your browser verifies the CA's signature using the CA's public key
The CA's certificate may be signed by a higher CA, forming a chain
The chain terminates at a root CA in your browser's trust store

2. Server Proof of Possession: Having a certificate isn't enough—the server must prove it owns the private key:

In TLS 1.2: Server signs the handshake transcript with its private key
In TLS 1.3: Server signs specific handshake messages
This proves the server isn't just replaying someone else's certificate

3. Client Authentication (Optional): For high-security scenarios, clients can also present certificates:

Mutual TLS (mTLS) requires both parties to authenticate
Common in enterprise environments, APIs, and zero-trust architectures
Browser sends client certificate; server verifies client's signature

Scale of TLS: Trillions of TLS connections are established daily. Every connection involves multiple signature verifications (certificate chain) plus signature generation (server proof). This represents the largest deployment of public-key cryptography in history.

Converting Mermaid diagram...

TLS Certificate Types and Validation
Certificate Type	Validation Level	Use Case	Visual Indicator
Domain Validated (DV)	Automated domain control check	Personal sites, blogs	Padlock icon only
Organization Validated (OV)	Business identity verified	Company websites	Padlock + org name on inspection
Extended Validation (EV)	Rigorous identity verification	Banks, high-value sites	Green bar / org name in address bar
Wildcard (*.example.com)	Covers all subdomains	Large organizations	Same as DV/OV/EV base
Multi-domain (SAN)	Multiple domains in one cert	Hosting multiple sites	Same as base type

Certificate Transparency

All publicly-trusted certificates must be logged in Certificate Transparency (CT) logs—publicly auditable append-only logs. This allows domain owners to detect fraudulently issued certificates for their domains. Browsers reject certificates not present in CT logs. This uses Merkle tree signatures to prove inclusion and consistency.

Code Signing: Securing the Software Supply Chain

Code signing uses digital signatures to prove that software comes from a known publisher and hasn't been tampered with since publication. It's a critical defense against malware distribution and supply chain attacks.

How Code Signing Works:

1. Developer Signs Software:

Developer obtains a code signing certificate from a CA
Before distribution, developer signs the executable/package
Signature binds their identity to the specific binary content

2. User/System Verifies:

Operating system or installer verifies signature before execution
Valid signature: software runs (possibly with security prompt)
Invalid/missing signature: warning, blocking, or refusal to run

3. Timestamping:

Code signing includes RFC 3161 timestamps
Timestamps prove signature was created when certificate was valid
Software remains valid even after certificate expires

Platform-Specific Code Signing:

Windows (Authenticode): Signs EXE, DLL, MSI, etc. Kernel-mode drivers require Microsoft signature.
macOS (Gatekeeper): Required for App Store; recommended for all. Notarization adds Apple's verification.
iOS/Android: All apps must be signed. Distribution only through app stores.
Linux (Package Managers): RPM, DEB, and other packages are GPG-signed. Repositories have signing keys.
Container Images: Docker Content Trust, Sigstore for image signing.
JavaScript/npm: Package signing emerging; important after supply chain attacks.

What Code Signing Protects

•Verifies publisher identity
•Detects binary tampering/corruption
•Prevents MITM during download
•Enables software update trust
•Provides accountability for malware

What Code Signing Doesn't Protect

•Doesn't guarantee software is safe
•Malware authors can get certificates
•Doesn't protect signing keys from theft
•Revocation can be slow to propagate
•Social engineering still possible

Supply Chain Attacks

Code signing is only as secure as the signing infrastructure. SolarWinds (2020) and Codecov (2021) demonstrated that attackers can compromise build pipelines to inject malware before signing—producing malware with valid signatures. Signing keys must be protected in HSMs, build systems must be isolated, and reproducible builds provide additional verification.

Email Authentication: Fighting Phishing and Spoofing

Email was designed without authentication—anyone can claim to be anyone in the 'From' field. Digital signatures retrofit authentication onto email through multiple mechanisms:

DKIM (DomainKeys Identified Mail):

DKIM adds domain-level signing to emails:

Sending server generates signature over specified headers + body
Signature is added as a header to the email
Receiving server extracts signature, retrieves public key from DNS
Signature verification proves email came from claimed domain

DKIM uses RSA or Ed25519 signatures. The public key is published as a DNS TXT record, indexed by a 'selector' allowing key rotation.

Example DKIM Signature:

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=selector1;
 h=from:to:subject:date; bh=...bodyHash...;
 b=...signature...

S/MIME and PGP/GPG:

For end-to-end email authentication (and encryption):

S/MIME: Uses X.509 certificates from CAs. Integrated into Outlook, Apple Mail.
PGP/GPG: Uses web of trust. Popular in security community; harder for mainstream.

Both allow:

Signing emails (recipient verifies authenticity)
Encrypting emails (only recipient can read)
Signing + encrypting for both properties

Email Authentication Technologies
Technology	What It Proves	Scope	Adoption
DKIM	Email came from domain's authorized servers	Domain-level	Very high (~80% of email)
SPF	Sending IP authorized by domain (not signature-based)	IP-level	Very high
DMARC	Policy enforcement for DKIM/SPF; reporting	Policy layer	Growing rapidly
S/MIME	Sender identity (individual certificate)	End-to-end	Enterprise; moderate
PGP/GPG	Sender identity (key verified via web of trust)	End-to-end	Security community
ARC	Authentication chain across forwards	Multi-hop	Growing

DMARC Enforcement

DKIM alone doesn't tell receivers what to do with failed checks. DMARC (Domain-based Message Authentication, Reporting, and Conformance) publishes domain policies: 'none' (monitor only), 'quarantine' (spam folder), or 'reject' (drop message). Organizations with DMARC p=reject strongly protect against phishing impersonation.

Blockchain and Cryptocurrency

Blockchain technology represents one of the most innovative applications of digital signatures. Every transaction, every smart contract interaction, every governance vote relies on digital signatures to prove authorization.

Bitcoin Transactions:

Every Bitcoin transaction includes:

Inputs: References to previous transaction outputs (coins to spend)
Outputs: New recipients and amounts
Signatures: ECDSA (secp256k1) signatures proving ownership of input coins

To spend Bitcoin:

User creates transaction specifying recipient and amount
User signs with private key corresponding to the receiving address
Network validates signature before including in blockchain
Without valid signature, transaction is rejected

Ethereum Smart Contracts:

Ethereum extends the model:

Transactions to smart contracts are signed
Smart contracts can verify signatures (ecrecover opcode)
Meta-transactions allow third parties to pay gas fees
Multi-signature wallets require m-of-n signatures

Advanced Signature Schemes in Crypto:

Schnorr Signatures (Bitcoin Taproot): Smaller, enable signature aggregation
BLS Signatures (Ethereum 2.0): Aggregate many validators into one signature
Ring Signatures (Monero): Sign without revealing which key in a set was used
Threshold Signatures: No single party has the full key; requires cooperation

Ethereum Transaction Signing
JavaScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
const { ethers } = require('ethers');
 
// Create a wallet (holds private key)
const wallet = ethers.Wallet.createRandom();
console.log('Address:', wallet.address);
 
// Create a transaction
const transaction = {
    to: '0xRecipientAddress...',
    value: ethers.parseEther('1.0'),
    gasLimit: 21000,
    gasPrice: ethers.parseUnits('10', 'gwei'),
    nonce: 0,
    chainId: 1  // Mainnet
};
 
// Sign the transaction
async function signAndBroadcast() {
    // Sign creates ECDSA signature over RLP-encoded transaction
    const signedTx = await wallet.signTransaction(transaction);
    console.log('Signed Transaction:', signedTx);
    
    // The signature includes v, r, s components
    // Anyone can verify: recover address from signature, compare to 'from'
    
    // Parse to examine components
    const parsed = ethers.Transaction.from(signedTx);
    console.log('Signature r:', parsed.signature.r);
    console.log('Signature s:', parsed.signature.s);
    console.log('Recovered address:', parsed.from);
}
 
// Verify message signature (off-chain)
async function verifyMessage() {
    const message = "Authorize withdrawal of 100 tokens";
    
    // Sign message (personal_sign style)
    const signature = await wallet.signMessage(message);
    console.log('Message Signature:', signature);
    
    // Recover signer address from signature
    const recoveredAddress = ethers.verifyMessage(message, signature);
    console.log('Recovered Signer:', recoveredAddress);
    console.log('Matches wallet:', recoveredAddress === wallet.address);
}

Account Abstraction

Modern blockchain architectures are moving beyond single-key accounts. Account abstraction (ERC-4337) allows custom signature schemes: hardware wallets, social recovery, multiple keys with different permissions, and even email/biometric authentication. The signature verification logic moves from protocol level to smart contract level.

Document Signing: Legal and Business Applications

Digital signatures have legal recognition in most jurisdictions, enabling paperless contracts, agreements, and official documents. Specialized standards ensure long-term validity and legal enforceability.

Legal Framework:

US eSign Act / UETA: Digital signatures have same legal weight as handwritten
EU eIDAS Regulation: Defines electronic signatures, advanced signatures, qualified signatures
Qualified Electronic Signatures (QES): Highest legal tier in EU; requires certified hardware and CAs

Document Signing Standards:

PAdES (PDF Advanced Electronic Signatures):

Standard for signing PDF documents
Embeds signature, certificate, timestamp in PDF
Long-term validation (LTV): includes revocation info for future verification
Widely supported in Adobe Acrobat, DocuSign, etc.

XAdES (XML Advanced Electronic Signatures):

Standard for signing XML documents
Used in government and enterprise XML workflows
Supports countersignatures, endorsements, archival formats

CAdES (CMS Advanced Electronic Signatures):

Standard for signing arbitrary data
Based on CMS (Cryptographic Message Syntax)
Used when the signed data format is not PDF or XML

Commercial Platforms:

DocuSign: Market leader; integrates with business workflows
Adobe Sign: Deep PDF integration; PAdES compliant
HelloSign, SignNow, PandaDoc: Various enterprise features
Open source: LibreSign, Open-PDF-Sign

eIDAS Signature Levels
Level	Requirements	Legal Effect	Use Cases
Simple Electronic Signature (SES)	Any data in electronic form	Valid but easily challenged	Terms acceptance, low-risk documents
Advanced Electronic Signature (AdES)	Uniquely linked to signatory, detects changes	Valid; burden shifts to challenger	Most business contracts
Qualified Electronic Signature (QES)	AdES + qualified certificate + secure device	Equivalent to handwritten	High-value legal documents, EU public sector

Long-Term Archival

Documents may need to be verified decades later. Long-term validation (LTV) embeds all verification material (certificates, revocation info, timestamps) in the document. Archive timestamps can be added periodically as older algorithms weaken, maintaining verifiability indefinitely. This is critical for contracts, real estate records, and regulatory documents.

API Authentication: JWTs and Beyond

Modern web applications and microservices use digital signatures for stateless authentication—verifying user identity without database lookups on every request.

JSON Web Tokens (JWT):

JWTs are the dominant standard for API authentication:

Structure:

header.payload.signature

Header: Algorithm and token type (e.g., {"alg":"RS256","typ":"JWT"})
Payload: Claims about the user (user_id, expiration, permissions)
Signature: Signature over base64url(header) + '.' + base64url(payload)

Signature Algorithms:

HS256: HMAC-SHA256 (symmetric; shared secret)
RS256: RSA-SHA256 (asymmetric; public/private keys)
ES256: ECDSA-P256-SHA256 (asymmetric; smaller signatures)
EdDSA: Ed25519 (modern, recommended for new systems)

Flow:

User authenticates (login)
Server creates JWT with user claims, signs with private key
Client stores token (cookie, localStorage)
Client sends token with each API request
Server verifies signature with public key
If valid and not expired, request is authorized

Advantages:

Stateless: no server-side session storage
Scalable: any server with public key can verify
Portable: token works across microservices
Self-contained: claims embedded in token

JWT Creation and Verification
JavaScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
const jwt = require('jsonwebtoken');
const { generateKeyPairSync } = require('crypto');
 
// Generate RSA key pair (in practice, load from secure storage)
const { publicKey, privateKey } = generateKeyPairSync('rsa', {
    modulusLength: 2048,
    publicKeyEncoding: { type: 'spki', format: 'pem' },
    privateKeyEncoding: { type: 'pkcs8', format: 'pem' }
});
 
// Create a signed JWT (authentication server)
function createToken(userId, permissions) {
    const payload = {
        sub: userId,          // Subject (user ID)
        iat: Math.floor(Date.now() / 1000),  // Issued at
        exp: Math.floor(Date.now() / 1000) + 3600,  // Expires in 1 hour
        permissions: permissions,
        iss: 'auth.example.com'  // Issuer
    };
    
    // Sign with RS256 (RSA-SHA256)
    const token = jwt.sign(payload, privateKey, { algorithm: 'RS256' });
    return token;
}
 
// Verify JWT (any API server with public key)
function verifyToken(token) {
    try {
        // Verify signature and extract claims
        const decoded = jwt.verify(token, publicKey, { 
            algorithms: ['RS256'],
            issuer: 'auth.example.com'
        });
        
        console.log('Token valid for user:', decoded.sub);
        console.log('Permissions:', decoded.permissions);
        return decoded;
        
    } catch (err) {
        if (err.name === 'TokenExpiredError') {
            console.log('Token expired');
        } else if (err.name === 'JsonWebTokenError') {
            console.log('Invalid signature');
        }
        return null;
    }
}
 
// Example usage
const token = createToken('user123', ['read', 'write']);
console.log('Token:', token);
console.log('\nVerification:');
verifyToken(token);

JWT Security Considerations

JWT security pitfalls include: accepting 'alg':'none' (no signature), key confusion (using HS256 key as RS256 public key), insufficient expiration times, storing sensitive data in payload (it's base64, not encrypted), and not validating all claims. Always use established libraries, verify 'alg' matches expected, and set appropriate expiration.

Emerging Applications

Digital signatures continue to find new applications as technology evolves. Several emerging areas push the boundaries of what signatures can accomplish.

Verifiable Credentials:

Digital credentials for education, employment, identity:

Issuer signs credential (diploma, certification, employment record)
Holder stores credential (wallet app)
Verifier checks signature without contacting issuer
Standards: W3C Verifiable Credentials, ISO mDL (mobile driver's license)

Software Bill of Materials (SBOM):

Signed inventory of software components:

Lists all dependencies, versions, sources
Signed by build system or publisher
Enables supply chain auditing and vulnerability tracking
Formats: SPDX, CycloneDX with in-toto attestations

IoT Device Attestation:

Devices proving their identity and integrity:

Device signs attestation with hardware-protected key
Attestation includes firmware version, security state
Server verifies before granting access
Examples: Android SafetyNet, Apple DeviceCheck, TPM attestation

Secure Boot and Measured Boot:

Each boot stage verifies the next:

UEFI firmware verifies bootloader signature
Bootloader verifies kernel signature
Kernel verifies module signatures
Creates chain of trust from hardware root

Cutting-Edge Signature Applications

•Threshold Signatures: No single party holds the full private key; requires cooperation of multiple parties to sign. Used for cryptocurrency custody, enterprise key management.
•Blind Signatures: Signer signs without seeing the message content. Enables anonymous credentials, privacy-preserving voting.
•Ring Signatures: Proves signature from someone in a group without revealing who. Privacy coins (Monero), anonymous authentication.
•Aggregate Signatures: Combine many signatures into one constant-size signature. Blockchain scaling, certificate chains.
•Zero-Knowledge Proofs: Prove knowledge of a signed message without revealing the signature. Privacy-preserving credential verification.
•Post-Quantum Signatures: CRYSTALS-Dilithium, FALCON, SPHINCS+ designed to resist quantum computers. Transitioning now for long-lived documents.

Sigstore: Keyless Signing

Sigstore represents a new paradigm: 'keyless' signing using short-lived certificates tied to identity providers (GitHub, Google). Sign software with your GitHub identity; Sigstore logs the signature in a transparency log. No long-term keys to manage, but full auditability. Increasingly used for open-source software signing.

The Post-Quantum Transition

Quantum computers pose an existential threat to current digital signature schemes. Understanding this transition is essential for anyone designing long-lived security systems.

The Quantum Threat:

Shor's algorithm, running on a sufficiently powerful quantum computer, can:

Factor large numbers efficiently → breaks RSA
Compute discrete logarithms → breaks DSA, ECDSA, EdDSA

All current mainstream signature algorithms would become insecure.

NIST Post-Quantum Standardization:

NIST has standardized post-quantum signature algorithms:

CRYSTALS-Dilithium (ML-DSA): Primary recommendation; based on lattice problems
FALCON: Smaller signatures than Dilithium; complex implementation
SPHINCS+ (SLH-DSA): Hash-based; large signatures but minimal assumptions

Transition Implications:

Signature Sizes Increase: Dilithium signatures are ~2500 bytes vs 64 bytes for Ed25519
Public Key Sizes Increase: Dilithium public keys are ~1300 bytes
Performance Varies: Some PQ algorithms are slower than classical
Hybrid Approaches: Combine classical + PQ for transitional period

Post-Quantum Signature Algorithm Comparison
Algorithm	Type	Public Key Size	Signature Size	Security Level
Ed25519 (reference)	ECC	32 bytes	64 bytes	~128 bits
Dilithium2	Lattice	1,312 bytes	2,420 bytes	~128 bits
Dilithium3	Lattice	1,952 bytes	3,293 bytes	~192 bits
Dilithium5	Lattice	2,592 bytes	4,595 bytes	~256 bits
FALCON-512	Lattice	897 bytes	666 bytes	~128 bits
SPHINCS+-128f	Hash-based	32 bytes	17,088 bytes	~128 bits

Harvest Now, Decrypt Later

Adversaries are collecting encrypted/signed data today to break later when quantum computers exist. For documents with long-term value (contracts, government records, IP), consider post-quantum signatures now. The transition should be urgency-driven: 'migrate by 2030' recommendations exist for sensitive applications.

Summary: Digital Signatures in Practice

We've surveyed the vast landscape of digital signature applications—from the TLS connections that secure every HTTPS request to the emerging post-quantum algorithms that will protect tomorrow's systems. Digital signatures have become so fundamental that modern digital infrastructure simply couldn't exist without them.

Let's consolidate the key applications and their characteristics:

Key Takeaways

•TLS/HTTPS relies on certificate signatures — Every secure web connection verifies certificate chains signed by trusted CAs, plus server proof-of-possession.
•Code signing protects the software supply chain — Signatures verify publisher identity and detect tampering from development through installation.
•Email authentication uses domain signatures — DKIM proves domain origin; S/MIME and PGP provide end-to-end authentication.
•Blockchain transactions require user signatures — Every cryptocurrency transfer, smart contract call, and governance vote is authorized by digital signature.
•Document signing has legal standing — PAdES, XAdES, and commercial platforms enable legally binding digital contracts worldwide.
•API authentication leverages signed tokens — JWTs enable stateless, scalable authentication across distributed systems.
•Emerging applications expand capabilities — Verifiable credentials, IoT attestation, threshold signatures, and privacy-preserving schemes push boundaries.
•Post-quantum transition is underway — New algorithms standardized; organizations must plan migration for quantum-resistant signatures.

Module Complete:

You have now completed a comprehensive journey through digital signatures—from foundational concepts through hash functions, signing algorithms, verification processes, and practical applications. You understand both the mathematical foundations and the real-world systems that depend on them.

This knowledge prepares you for the next module: Certificates and PKI. Digital signatures are powerful, but they require infrastructure to answer the question: Whose public key is this? Certificates bind public keys to identities, and PKI provides the trust framework that makes signatures meaningful across organizations and the global internet.

Module Complete

Congratulations! You now possess deep, practical knowledge of digital signatures—their creation, verification, and deployment across the security ecosystem. From TLS certificates to cryptocurrency wallets to post-quantum cryptography, you understand how mathematical proofs of authenticity enable trust in the digital age.

5 / 5

Loading learning content...

Computer NetworksDigital Signatures

Digital Signatures

LevelIntermediate

Duration60 mins

TopicDigital Signatures

5 / 5

Applications

The Invisible Foundation of Digital Trust

What You Will Learn

TLS/SSL Certificates: Securing the Web

How TLS Uses Digital Signatures:

1. Certificate Authentication: When you connect to https://bank.com:

The server presents its certificate containing its public key
The certificate is signed by a Certificate Authority (CA)
Your browser verifies the CA's signature using the CA's public key
The CA's certificate may be signed by a higher CA, forming a chain
The chain terminates at a root CA in your browser's trust store

2. Server Proof of Possession: Having a certificate isn't enough—the server must prove it owns the private key:

In TLS 1.2: Server signs the handshake transcript with its private key
In TLS 1.3: Server signs specific handshake messages
This proves the server isn't just replaying someone else's certificate

3. Client Authentication (Optional): For high-security scenarios, clients can also present certificates:

Mutual TLS (mTLS) requires both parties to authenticate
Common in enterprise environments, APIs, and zero-trust architectures
Browser sends client certificate; server verifies client's signature

Converting Mermaid diagram...

TLS Certificate Types and Validation
Certificate Type	Validation Level	Use Case	Visual Indicator
Domain Validated (DV)	Automated domain control check	Personal sites, blogs	Padlock icon only
Organization Validated (OV)	Business identity verified	Company websites	Padlock + org name on inspection
Extended Validation (EV)	Rigorous identity verification	Banks, high-value sites	Green bar / org name in address bar
Wildcard (*.example.com)	Covers all subdomains	Large organizations	Same as DV/OV/EV base
Multi-domain (SAN)	Multiple domains in one cert	Hosting multiple sites	Same as base type

Certificate Transparency

Code Signing: Securing the Software Supply Chain

How Code Signing Works:

1. Developer Signs Software:

Developer obtains a code signing certificate from a CA
Before distribution, developer signs the executable/package
Signature binds their identity to the specific binary content

2. User/System Verifies:

Operating system or installer verifies signature before execution
Valid signature: software runs (possibly with security prompt)
Invalid/missing signature: warning, blocking, or refusal to run

3. Timestamping:

Code signing includes RFC 3161 timestamps
Timestamps prove signature was created when certificate was valid
Software remains valid even after certificate expires

Platform-Specific Code Signing:

Windows (Authenticode): Signs EXE, DLL, MSI, etc. Kernel-mode drivers require Microsoft signature.
macOS (Gatekeeper): Required for App Store; recommended for all. Notarization adds Apple's verification.
iOS/Android: All apps must be signed. Distribution only through app stores.
Linux (Package Managers): RPM, DEB, and other packages are GPG-signed. Repositories have signing keys.
Container Images: Docker Content Trust, Sigstore for image signing.
JavaScript/npm: Package signing emerging; important after supply chain attacks.

What Code Signing Protects

•Verifies publisher identity
•Detects binary tampering/corruption
•Prevents MITM during download
•Enables software update trust
•Provides accountability for malware

What Code Signing Doesn't Protect

•Doesn't guarantee software is safe
•Malware authors can get certificates
•Doesn't protect signing keys from theft
•Revocation can be slow to propagate
•Social engineering still possible

Supply Chain Attacks

Email Authentication: Fighting Phishing and Spoofing

Email was designed without authentication—anyone can claim to be anyone in the 'From' field. Digital signatures retrofit authentication onto email through multiple mechanisms:

DKIM (DomainKeys Identified Mail):

DKIM adds domain-level signing to emails:

Sending server generates signature over specified headers + body
Signature is added as a header to the email
Receiving server extracts signature, retrieves public key from DNS
Signature verification proves email came from claimed domain

DKIM uses RSA or Ed25519 signatures. The public key is published as a DNS TXT record, indexed by a 'selector' allowing key rotation.

Example DKIM Signature:

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=selector1;
 h=from:to:subject:date; bh=...bodyHash...;
 b=...signature...

S/MIME and PGP/GPG:

For end-to-end email authentication (and encryption):

S/MIME: Uses X.509 certificates from CAs. Integrated into Outlook, Apple Mail.
PGP/GPG: Uses web of trust. Popular in security community; harder for mainstream.

Both allow:

Signing emails (recipient verifies authenticity)
Encrypting emails (only recipient can read)
Signing + encrypting for both properties

Email Authentication Technologies
Technology	What It Proves	Scope	Adoption
DKIM	Email came from domain's authorized servers	Domain-level	Very high (~80% of email)
SPF	Sending IP authorized by domain (not signature-based)	IP-level	Very high
DMARC	Policy enforcement for DKIM/SPF; reporting	Policy layer	Growing rapidly
S/MIME	Sender identity (individual certificate)	End-to-end	Enterprise; moderate
PGP/GPG	Sender identity (key verified via web of trust)	End-to-end	Security community
ARC	Authentication chain across forwards	Multi-hop	Growing

DMARC Enforcement

Blockchain and Cryptocurrency

Bitcoin Transactions:

Every Bitcoin transaction includes:

Inputs: References to previous transaction outputs (coins to spend)
Outputs: New recipients and amounts
Signatures: ECDSA (secp256k1) signatures proving ownership of input coins

To spend Bitcoin:

User creates transaction specifying recipient and amount
User signs with private key corresponding to the receiving address
Network validates signature before including in blockchain
Without valid signature, transaction is rejected

Ethereum Smart Contracts:

Ethereum extends the model:

Transactions to smart contracts are signed
Smart contracts can verify signatures (ecrecover opcode)
Meta-transactions allow third parties to pay gas fees
Multi-signature wallets require m-of-n signatures

Advanced Signature Schemes in Crypto:

Schnorr Signatures (Bitcoin Taproot): Smaller, enable signature aggregation
BLS Signatures (Ethereum 2.0): Aggregate many validators into one signature
Ring Signatures (Monero): Sign without revealing which key in a set was used
Threshold Signatures: No single party has the full key; requires cooperation

Ethereum Transaction Signing
JavaScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
const { ethers } = require('ethers');
 
// Create a wallet (holds private key)
const wallet = ethers.Wallet.createRandom();
console.log('Address:', wallet.address);
 
// Create a transaction
const transaction = {
    to: '0xRecipientAddress...',
    value: ethers.parseEther('1.0'),
    gasLimit: 21000,
    gasPrice: ethers.parseUnits('10', 'gwei'),
    nonce: 0,
    chainId: 1  // Mainnet
};
 
// Sign the transaction
async function signAndBroadcast() {
    // Sign creates ECDSA signature over RLP-encoded transaction
    const signedTx = await wallet.signTransaction(transaction);
    console.log('Signed Transaction:', signedTx);
    
    // The signature includes v, r, s components
    // Anyone can verify: recover address from signature, compare to 'from'
    
    // Parse to examine components
    const parsed = ethers.Transaction.from(signedTx);
    console.log('Signature r:', parsed.signature.r);
    console.log('Signature s:', parsed.signature.s);
    console.log('Recovered address:', parsed.from);
}
 
// Verify message signature (off-chain)
async function verifyMessage() {
    const message = "Authorize withdrawal of 100 tokens";
    
    // Sign message (personal_sign style)
    const signature = await wallet.signMessage(message);
    console.log('Message Signature:', signature);
    
    // Recover signer address from signature
    const recoveredAddress = ethers.verifyMessage(message, signature);
    console.log('Recovered Signer:', recoveredAddress);
    console.log('Matches wallet:', recoveredAddress === wallet.address);
}

Account Abstraction

Document Signing: Legal and Business Applications

Legal Framework:

US eSign Act / UETA: Digital signatures have same legal weight as handwritten
EU eIDAS Regulation: Defines electronic signatures, advanced signatures, qualified signatures
Qualified Electronic Signatures (QES): Highest legal tier in EU; requires certified hardware and CAs

Document Signing Standards:

PAdES (PDF Advanced Electronic Signatures):

Standard for signing PDF documents
Embeds signature, certificate, timestamp in PDF
Long-term validation (LTV): includes revocation info for future verification
Widely supported in Adobe Acrobat, DocuSign, etc.

XAdES (XML Advanced Electronic Signatures):

Standard for signing XML documents
Used in government and enterprise XML workflows
Supports countersignatures, endorsements, archival formats

CAdES (CMS Advanced Electronic Signatures):

Standard for signing arbitrary data
Based on CMS (Cryptographic Message Syntax)
Used when the signed data format is not PDF or XML

Commercial Platforms:

DocuSign: Market leader; integrates with business workflows
Adobe Sign: Deep PDF integration; PAdES compliant
HelloSign, SignNow, PandaDoc: Various enterprise features
Open source: LibreSign, Open-PDF-Sign

eIDAS Signature Levels
Level	Requirements	Legal Effect	Use Cases
Simple Electronic Signature (SES)	Any data in electronic form	Valid but easily challenged	Terms acceptance, low-risk documents
Advanced Electronic Signature (AdES)	Uniquely linked to signatory, detects changes	Valid; burden shifts to challenger	Most business contracts
Qualified Electronic Signature (QES)	AdES + qualified certificate + secure device	Equivalent to handwritten	High-value legal documents, EU public sector

Long-Term Archival

API Authentication: JWTs and Beyond

Modern web applications and microservices use digital signatures for stateless authentication—verifying user identity without database lookups on every request.

JSON Web Tokens (JWT):

JWTs are the dominant standard for API authentication:

Structure:

header.payload.signature

Header: Algorithm and token type (e.g., {"alg":"RS256","typ":"JWT"})
Payload: Claims about the user (user_id, expiration, permissions)
Signature: Signature over base64url(header) + '.' + base64url(payload)

Signature Algorithms:

HS256: HMAC-SHA256 (symmetric; shared secret)
RS256: RSA-SHA256 (asymmetric; public/private keys)
ES256: ECDSA-P256-SHA256 (asymmetric; smaller signatures)
EdDSA: Ed25519 (modern, recommended for new systems)

Flow:

User authenticates (login)
Server creates JWT with user claims, signs with private key
Client stores token (cookie, localStorage)
Client sends token with each API request
Server verifies signature with public key
If valid and not expired, request is authorized

Advantages:

Stateless: no server-side session storage
Scalable: any server with public key can verify
Portable: token works across microservices
Self-contained: claims embedded in token

JWT Creation and Verification
JavaScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
const jwt = require('jsonwebtoken');
const { generateKeyPairSync } = require('crypto');
 
// Generate RSA key pair (in practice, load from secure storage)
const { publicKey, privateKey } = generateKeyPairSync('rsa', {
    modulusLength: 2048,
    publicKeyEncoding: { type: 'spki', format: 'pem' },
    privateKeyEncoding: { type: 'pkcs8', format: 'pem' }
});
 
// Create a signed JWT (authentication server)
function createToken(userId, permissions) {
    const payload = {
        sub: userId,          // Subject (user ID)
        iat: Math.floor(Date.now() / 1000),  // Issued at
        exp: Math.floor(Date.now() / 1000) + 3600,  // Expires in 1 hour
        permissions: permissions,
        iss: 'auth.example.com'  // Issuer
    };
    
    // Sign with RS256 (RSA-SHA256)
    const token = jwt.sign(payload, privateKey, { algorithm: 'RS256' });
    return token;
}
 
// Verify JWT (any API server with public key)
function verifyToken(token) {
    try {
        // Verify signature and extract claims
        const decoded = jwt.verify(token, publicKey, { 
            algorithms: ['RS256'],
            issuer: 'auth.example.com'
        });
        
        console.log('Token valid for user:', decoded.sub);
        console.log('Permissions:', decoded.permissions);
        return decoded;
        
    } catch (err) {
        if (err.name === 'TokenExpiredError') {
            console.log('Token expired');
        } else if (err.name === 'JsonWebTokenError') {
            console.log('Invalid signature');
        }
        return null;
    }
}
 
// Example usage
const token = createToken('user123', ['read', 'write']);
console.log('Token:', token);
console.log('\nVerification:');
verifyToken(token);

JWT Security Considerations

Emerging Applications

Digital signatures continue to find new applications as technology evolves. Several emerging areas push the boundaries of what signatures can accomplish.

Verifiable Credentials:

Digital credentials for education, employment, identity:

Issuer signs credential (diploma, certification, employment record)
Holder stores credential (wallet app)
Verifier checks signature without contacting issuer
Standards: W3C Verifiable Credentials, ISO mDL (mobile driver's license)

Software Bill of Materials (SBOM):

Signed inventory of software components:

Lists all dependencies, versions, sources
Signed by build system or publisher
Enables supply chain auditing and vulnerability tracking
Formats: SPDX, CycloneDX with in-toto attestations

IoT Device Attestation:

Devices proving their identity and integrity:

Device signs attestation with hardware-protected key
Attestation includes firmware version, security state
Server verifies before granting access
Examples: Android SafetyNet, Apple DeviceCheck, TPM attestation

Secure Boot and Measured Boot:

Each boot stage verifies the next:

UEFI firmware verifies bootloader signature
Bootloader verifies kernel signature
Kernel verifies module signatures
Creates chain of trust from hardware root

Cutting-Edge Signature Applications

•Threshold Signatures: No single party holds the full private key; requires cooperation of multiple parties to sign. Used for cryptocurrency custody, enterprise key management.
•Blind Signatures: Signer signs without seeing the message content. Enables anonymous credentials, privacy-preserving voting.
•Ring Signatures: Proves signature from someone in a group without revealing who. Privacy coins (Monero), anonymous authentication.
•Aggregate Signatures: Combine many signatures into one constant-size signature. Blockchain scaling, certificate chains.
•Zero-Knowledge Proofs: Prove knowledge of a signed message without revealing the signature. Privacy-preserving credential verification.
•Post-Quantum Signatures: CRYSTALS-Dilithium, FALCON, SPHINCS+ designed to resist quantum computers. Transitioning now for long-lived documents.

Sigstore: Keyless Signing

The Post-Quantum Transition

Quantum computers pose an existential threat to current digital signature schemes. Understanding this transition is essential for anyone designing long-lived security systems.

The Quantum Threat:

Shor's algorithm, running on a sufficiently powerful quantum computer, can:

Factor large numbers efficiently → breaks RSA
Compute discrete logarithms → breaks DSA, ECDSA, EdDSA

All current mainstream signature algorithms would become insecure.

NIST Post-Quantum Standardization:

NIST has standardized post-quantum signature algorithms:

CRYSTALS-Dilithium (ML-DSA): Primary recommendation; based on lattice problems
FALCON: Smaller signatures than Dilithium; complex implementation
SPHINCS+ (SLH-DSA): Hash-based; large signatures but minimal assumptions

Transition Implications:

Signature Sizes Increase: Dilithium signatures are ~2500 bytes vs 64 bytes for Ed25519
Public Key Sizes Increase: Dilithium public keys are ~1300 bytes
Performance Varies: Some PQ algorithms are slower than classical
Hybrid Approaches: Combine classical + PQ for transitional period

Post-Quantum Signature Algorithm Comparison
Algorithm	Type	Public Key Size	Signature Size	Security Level
Ed25519 (reference)	ECC	32 bytes	64 bytes	~128 bits
Dilithium2	Lattice	1,312 bytes	2,420 bytes	~128 bits
Dilithium3	Lattice	1,952 bytes	3,293 bytes	~192 bits
Dilithium5	Lattice	2,592 bytes	4,595 bytes	~256 bits
FALCON-512	Lattice	897 bytes	666 bytes	~128 bits
SPHINCS+-128f	Hash-based	32 bytes	17,088 bytes	~128 bits

Harvest Now, Decrypt Later

Summary: Digital Signatures in Practice

Let's consolidate the key applications and their characteristics:

Key Takeaways

•TLS/HTTPS relies on certificate signatures — Every secure web connection verifies certificate chains signed by trusted CAs, plus server proof-of-possession.
•Code signing protects the software supply chain — Signatures verify publisher identity and detect tampering from development through installation.
•Email authentication uses domain signatures — DKIM proves domain origin; S/MIME and PGP provide end-to-end authentication.
•Blockchain transactions require user signatures — Every cryptocurrency transfer, smart contract call, and governance vote is authorized by digital signature.
•Document signing has legal standing — PAdES, XAdES, and commercial platforms enable legally binding digital contracts worldwide.
•API authentication leverages signed tokens — JWTs enable stateless, scalable authentication across distributed systems.
•Emerging applications expand capabilities — Verifiable credentials, IoT attestation, threshold signatures, and privacy-preserving schemes push boundaries.
•Post-quantum transition is underway — New algorithms standardized; organizations must plan migration for quantum-resistant signatures.

Module Complete:

Module Complete

5 / 5