九思札记 · 探索区块链 · AI

2.1 和 2.2 深入剖析了哈希函数的数学安全属性与两种核心实现。本节将视角从"单一原语"提升到"密码学体系"层面，系统澄清对称加密与非对称加密的角色分工——尤其是区块链语境下"非对称密码学"的真实含义：它不是加密消息，而是数字签名。

2.3.1 对称加密（Symmetric Encryption）

核心思想：一把钥匙开一把锁

\text{Enc}_k(m) = c, \quad \text{Dec}_k(c) = m

加密和解密使用同一个密钥 $k$ 。发送方和接收方必须在通信前以某种安全方式共享 $k$ 。它的核心性质可以用信息论的一个基本问题来理解：如何用一个短密钥保护任意长度的消息？

流密码：XOR 的巧妙使用

最简单的流密码思想非常优雅：

c_i = m_i \oplus \text{keystream}_i

其中 $\text{keystream}$ 是密钥 $k$ 通过一个伪随机数生成器（PRNG） 扩展得到的伪随机序列。只要 keystream 的长度与消息相同，就可以逐位异或。

安全性假设：密钥流对攻击者必须是"真正的随机"——即即使敌手拥有大量 $(m, c)$ 对，也无法预测下一个 keystream 位。满足这一性质的 PRNG 称为密码学安全伪随机数生成器（CSPRNG）。

AES 与分组模式（CTR 模式）

AES（Advanced Encryption Standard）是 2001 年由 NIST 标准化的对称分组密码，分组大小为 128 位（16 字节），支持 128/192/256 位密钥。

为什么需要"模式"？

AES 一次只能加密 128 位。如果消息超过 128 位，需要将其切分为多个 128 位的块。如何处理这些块之间的关系，就是分组模式的核心问题。

CTR 模式（计数器模式） 是最直观的一种：

c_i = m_i \oplus E_k(\text{nonce} \parallel i)

将每个块序号 $i$ 和一个不可重复的随机初始化向量（nonce/IV）组合，用 $E_k$ 加密，得到该块的密钥流，再与明文异或。

typescript

/**
 * AES-256-CTR 简化原理演示（不含真实 AES S-Box 细节）
 * 展示：对称加密 = CSPRNG 生成的密钥流与明文异或
 */
class SimpleSymmetricDemo {
  // 简化的密钥流生成器（教学用，非安全实现）
  // 真实 AES 使用 Rijndael S-Box + 10-14 轮字节替换/行移位/列混合/轮密钥加
  private key: number;
  private nonce: number;

  constructor(key: number, nonce: number) {
    this.key = key;
    this.nonce = nonce;
  }

  // 为第 i 个块生成 128-bit 伪随机
  private generateBlock(counter: number): Uint8Array {
    // 简化的伪随机：基于 LCG 的 128-bit 输出（教学性质）
    const seed = this.key + this.nonce * 0x9e3779b9 + counter * 0xc6ef3720;
    const block = new Uint8Array(16);
    for (let i = 0; i < 16; i++) {
      let val = ((seed * (i + 1) * 0x85ebca6b) >>> 0);
      block[i] = (val ^ (val >>> 7) ^ (val << 3)) & 0xFF;
    }
    return block;
  }

  encrypt(plaintext: Uint8Array): Uint8Array {
    const ciphertext = new Uint8Array(plaintext.length);
    for (let i = 0; i < plaintext.length; i += 16) {
      const block = this.generateBlock(i / 16);
      for (let j = 0; j < 16 && i + j < plaintext.length; j++) {
        ciphertext[i + j] = plaintext[i + j] ^ block[j];
      }
    }
    return ciphertext;
  }

  decrypt(ciphertext: Uint8Array): Uint8Array {
    // CTR 模式下解密 = 再加密一次（异或的自反性：x XOR k = y, y XOR k = x）
    return this.encrypt(ciphertext);
  }
}

// --- 演示 ---
const key = 0xAABBCCDD;
const nonce = 0x12345678;
const demo = new SimpleSymmetricDemo(key, nonce);
const text = new TextEncoder().encode("Hello World!!!12"); // 16 字节

const enc = demo.encrypt(text);
console.log("密文:", Array.from(enc).map(b => b.toString(16).padStart(2, '0')).join(' '));

const dec = demo.decrypt(enc);
console.log("解密:", new TextDecoder().decode(dec));

对称加密在区块链中的角色

场景	用途	密钥管理问题
钱包文件加密	加密私钥存储文件，防止设备失窃后密钥泄露	用户密码作为密钥派生源
P2P 网络层加密	节点间通信使用 TLS（底层用对称加密）	通过非对称密码学（TLS 握手）先建立共享密钥
状态存储加密	联盟链中部分加密状态仅对授权方可见	通过联盟密钥管理方案（如门限加密）分配

2.3.2 非对称加密：公钥与私钥

核心数学思想：单向函数与陷门

非对称密码学的本质是陷门单向函数（Trapdoor One-way Function）——一个函数正向计算容易，但逆向计算极难，除非拥有特定的"陷门信息"。

RSA： $f(x) = x^e \mod N$ ，其中 $N = pq$ ， $e$ 为公钥。逆向需知道 $p$ 或 $q$ （即私钥 $d$ ）。安全性基于大整数质因数分解难题。
ECC： $f(d) = d \times G = P$ 。正向是标量乘法（容易），逆向是离散对数（极难）。

消息加密场景

直观来说，非对称加密用于：

Bob 生成密钥对，公开公钥 $PK$ ，保密私钥 $SK$ 。
Alice 用 $PK$ 加密消息 $m$ 得到 $c$ 。
Bob 用 $SK$ 解密 $c$ 恢复 $m$ 。

但在区块链协议中，这个场景几乎不使用。原因如下：

2.3.3 关键澄清：区块链中的"非对称密码学"本质是数字签名

这是区块链密码学中最常被误解的一点。

为什么区块链不需要消息加密？

交易数据需要公开验证：如果交易被加密，如何验证它是否有效？
共识节点需要验证余额：如果账户余额是密文，节点无法执行共识规则。
区块链的透明度是设计意图：正是因为所有人都可以验证规则是否被遵循，去中心化才成立。

数字签名的核心角色

区块链中的非对称密码学只做一件事：证明"某个操作被私钥持有者授权"。

text

┌─────────────┐     私钥签名      ┌─────────────┐
│  你的私钥    │ ──→ 签名(r, s) ──→│  广播到网络  │
│ (d)         │                 │             │
└─────────────┘                 └──────┬──────┘
                                     │
                                     ▼
                              任何人可用你的公钥验证签名

类比理解

现实类比	对称加密	非对称加密（数字签名）
物理世界	保险箱密码	手写笔迹 + 公证
核心属性	"知道密码就能打开"	"只有你能写出这个笔迹"
区块链场景	钱包文件保护	资产转让授权
密钥泄露后果	敌人能解密过去和未来的消息	敌人能伪造授权，转移你的资产

为什么强调这个区分？ 初学者常问"既然有公钥和私钥，为什么不直接用公钥加密交易保护隐私？"答案是：加密后无法验证，而区块链的验证需求大于保密需求。隐私保护在区块链中通过其他方式实现（如环签名、零知识证明），而非简单加密。

2.3.4 两种加密体系的对比总结

维度	对称加密	非对称加密（数字签名）
密钥数量	1 个（共享密钥）	密钥对（公钥 + 私钥）
主要用途	数据保密（存储、传输）	身份认证与授权（签名/验签）
性能	快（硬件可达 GB/s 级别）	慢（比对称慢 100–1000 倍）
密钥长度（128-bit 安全）	128 位（AES-128）	3072 位（RSA）或 256 位（ECC）
密钥分发问题	需要安全通道共享密钥	公钥可公开分发，私钥永远保密
区块链角色	钱包文件加密、TLS	交易签名、地址生成
核心安全假设	密钥保密性	数学难题（分解/离散对数/椭圆曲线离散对数）

graph LR
    subgraph 对称加密场景
        A[明文] -- "共享密钥 K 加密" --> B[密文]
        B -- "共享密钥 K 解密" --> C[明文]
    end
    subgraph 非对称签名场景_区块链
        D[消息哈希] -- "私钥签名" --> E[签名值 r,s]
        E -- "公钥验证" --> F[验证通过/失败]
        D -."实际交易数据".-G[全网公开广播]
    end

核心认知

对称加密是"保密工具"，非对称数字签名是"授权工具"。区块链的核心问题不是"谁可以读？"（因为数据公开），而是"谁可以花？"（需要签名授权）。

两种体系常常协同工作。TLS 握手阶段用非对称密码学交换共享密钥，后续通信用对称加密保护——这结合了两者的优点：非对称解决了"如何安全分发密钥"的问题，对称解决了"高性能加密"的问题。

混淆"加密"与"签名"会让理解后续章节变得困难。当你看比特币 P2PKH 脚本或以太坊交易结构时，看到的不是"加密操作"，而是"签名验证操作"。

下一预告：2.4 节将深入椭圆曲线密码学（ECC）中最著名的曲线 secp256k1，用 TypeScript 从零实现点加法、倍点运算和标量乘法，让读者理解为什么 $P = d \times G$ 是"容易计算但极难逆转"的。

本页目录