AES ECB模式与ZeroPadding：OpenSSL遗留代码的深度解析与安全升级指南

1. 项目概述：一个看似过时却依然坚挺的技术组合

如果你在C语言项目中处理过加密，尤其是用过OpenSSL库，大概率见过或者自己写过类似 AES_ecb_encrypt 配合手动补零（ZeroPadding）的代码。这组合在今天看来，几乎成了“反面教材”的代名词：教科书和无数安全文章都在告诫我们，ECB模式不安全，ZeroPadding也不够健壮。但一个有趣的现象是，当你去翻看GitHub上大量的遗留项目、嵌入式设备代码，甚至是某些开源库的示例或内部工具时，这个组合依然频繁出现。这不禁让人疑惑：既然有公认更优的CBC、CTR模式，以及PKCS#7这样的标准填充，为什么这个“过时”的组合生命力如此顽强？

我最初接触AES时也踩过这个坑，后来在维护一个老旧的网络设备固件时，发现其配置文件的加密就是用的ECB+ZeroPadding。为了兼容和升级，我不得不深入研究这套机制。今天，我们就来彻底拆解这个现象背后的原因，并给出一个完整的、可直接编译运行的C语言示例。你会发现，它的“常见”并非偶然，而是由历史惯性、实现复杂度、特定场景需求共同决定的。理解它，不仅能帮你读懂老代码，更能让你在“该用”和“不该用”的抉择上，做出更清醒的判断。

2. 核心概念拆解：ECB与ZeroPadding的“功”与“过”

在深入代码之前，我们必须先厘清这两个核心组件的工作原理和它们各自的优缺点。只有明白了它们的本质，才能理解其应用场景的局限性。

2.1 ECB模式：简单的并行加密

ECB（Electronic Codebook，电子密码本）是AES加密中最基础的模式。它的工作方式非常直观：将明文数据按AES块大小（128位，即16字节）切分成若干个独立的块，然后对每个块 独立地 使用相同的密钥进行加密。

工作原理类比 ：想象一本巨大的密码本（Codebook），每一页记录着一个16字节明文块对应的16字节密文块。加密就是查这本“书”，找到明文块对应的那一页，把上面的密文抄下来。每个块的加密过程互不干扰。

核心优势 ：

1. 算法简单，易于理解和实现 ：没有复杂的初始化向量（IV）或反馈机制，逻辑清晰。
2. 支持并行计算 ：由于块之间独立，可以同时对多个块进行加密或解密，这在某些硬件或并行计算环境下有速度优势。
3. 无错误传播 ：一个密文块在传输中出错，只会影响对应的一个明文块解密，不会“污染”后续数据。

致命缺陷 ：

1. 不能隐藏数据模式 ：这是ECB最被诟病的一点。相同的明文块必然产生相同的密文块。如果明文存在大量重复或规律性结构（比如一张BMP位图的纯色背景区域），密文中也会出现明显的重复模式，安全性大打折扣。
2. 不适合加密长消息或结构化数据 ：由于上述缺陷，ECB模式不应单独用于加密任何有语义或模式的数据。

注意 ：ECB模式的不安全性是结构性的，与密钥强度无关。即使使用256位超强密钥，ECB加密一张企鹅图片，密文依然能看出企鹅的轮廓。因此，在需要保密性的场景中，ECB基本不被采用。

2.2 ZeroPadding：最朴素的填充方案

AES是块加密算法，要求输入数据必须是块大小（16字节）的整数倍。但实际数据长度往往是任意的，因此需要在末尾进行“填充”（Padding）。ZeroPadding（也称ZeroByte Padding或ANSI X.923）是其中最简单的一种。

工作方式 ：

1. 加密（填充） ：计算需要填充的字节数 pad_len = block_size - (data_len % block_size) 。如果 data_len 正好是块大小的倍数，则填充一个完整的块（16字节）。然后，在数据末尾追加 pad_len 个值为 0x00 的字节。
2. 解密（去填充） ：解密后，从数据末尾向前扫描，移除所有连续的 0x00 字节，直到遇到第一个非零字节。

核心优势 ：

1. 实现极其简单 ：几行代码即可完成，计算开销几乎为零。
2. 确定性 ：填充内容固定（全零），无需生成随机字节。

显著问题 ：

1. 歧义问题（Ambiguity） ：如果原始明文的最后一个字节本身就是 0x00 ，解密时就无法区分这个 0x00 是原始数据还是填充字节。例如，明文 "hello\x00" （6字节）和 "hello" （5字节）经过填充加密再解密后，都可能得到 "hello" ，造成了数据丢失。虽然可以通过记录原始长度等方式规避，但这增加了复杂性。
2. 非标准 ：它不是像PKCS#7那样被广泛接受和严格定义的标准。不同的库或实现可能在处理边界情况时（如全零块）有细微差别，导致互操作性问题。

为什么它俩常一起出现？ 因为“简单”是共同的基因。在早期，或者对安全性要求不苛刻、更追求代码简洁和运行效率的嵌入式或工具类场景中，开发者很自然地选择了最简单的加密模式（ECB）和最简单的填充方式（ZeroPadding）。OpenSSL作为历史悠久、应用广泛的库，其早期示例和API设计也深受这种“简单至上”思维的影响，留下了大量的历史代码。

3. 为什么在OpenSSL中这个组合依然常见？

尽管有诸多缺陷，但ECB+ZeroPadding在OpenSSL生态中并未绝迹。这背后有技术、历史和现实的多重原因。

3.1 历史惯性：API的直观性与遗留代码

OpenSSL的底层 EVP_* 系列API虽然功能强大且支持各种模式和填充，但其学习曲线相对陡峭。对于只想快速实现一个加密功能的开发者来说，直接调用 AES_ecb_encrypt 这样的低级API，再手动写几行ZeroPadding代码，显得更加直接和可控。许多早期的教程、代码片段和开源项目都采用了这种方式，形成了巨大的代码遗产。维护这些项目时，贸然更改加密方式可能导致数据无法兼容，因此即使知道有更好的选择，也常常选择维持原状。

3.2 特定场景下的“够用”与“可控”

并非所有加密场景都要求极高的语义安全性。

1. 加密随机数据或已混淆的数据 ：如果你要加密的数据本身已经是高熵的、无模式的（例如，一个已经用哈希函数处理过的密钥，或者一个随机生成的令牌），那么ECB模式不能隐藏数据模式的缺陷就不再是问题。
2. 固定格式数据的完整性校验前加密 ：有时加密不是为了保密，而是作为某个更大流程（如生成MAC）的一部分。在那种架构下，模式的选择可能不那么关键。
3. 资源极端受限的环境 ：在一些老旧的单片机或嵌入式设备上，内存和计算资源极其宝贵。ECB模式无需存储和传递IV，ZeroPadding无需复杂逻辑，这种组合能节省宝贵的RAM和ROM空间。开发者必须在安全性和资源限制之间做出权衡。
4. 工具类应用的内部格式 ：一些离线工具（如某些旧的归档或配置文件加密工具）使用固定的密钥和模式。它们不涉及网络传输，威胁模型不同，开发者可能认为ECB+ZeroPadding带来的实现简便性比潜在的理论风险更重要。

3.3 OpenSSL API设计的灵活性

OpenSSL提供了不同层次的API。高级的 EVP_* API推荐使用更安全的模式（如CBC）和标准填充（如PKCS#7）。但低级的 AES_* API（如 AES_ecb_encrypt ）则把选择和责任完全交给了开发者。这种灵活性是一把双刃剑：它允许专家进行高度定制化，但也让新手容易掉入使用不安全默认组合的陷阱。由于低级API的存在，ECB+ZeroPadding这种组合在代码层面就一直有存在的土壤。

3.4 作为教学和调试的“透明”示例

在教学或调试加密算法时，ECB+ZeroPadding因其简单性而具有独特价值。它的过程是完全确定的、可逐步验证的。你可以手动计算一个块的加密结果，并与OpenSSL的输出逐字节比对，这对于理解AES的底层运算非常有帮助。相比之下，带有随机IV的CBC模式，每次输出都不同，不利于教学演示和静态测试。

4. 完整C语言示例：实现与剖析

下面，我将展示一个使用OpenSSL低级API实现AES-128-ECB + ZeroPadding加密解密的完整C程序。请注意， 此示例仅用于学习和理解原理，或在明确接受其风险的特定兼容性场景中使用，不应用于新的、要求保密性的生产环境。

4.1 环境准备与代码框架

首先，你需要一个安装了OpenSSL开发库的环境。在Ubuntu上可以通过 sudo apt-get install libssl-dev 安装。代码主要包含以下几个部分：

• 密钥定义（示例中硬编码，实际应从安全渠道获取）
• ZeroPadding的添加与移除函数
• 使用 AES_ecb_encrypt 进行加密和解密
• 主函数演示流程

#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#include <openssl/aes.h>

// AES-128 密钥长度是16字节
#define AES_KEYLENGTH 16
// AES块大小是16字节
#define AES_BLOCK_SIZE 16

// 示例密钥 (绝对不要在真实项目中硬编码密钥！)
static const unsigned char aes_key[AES_KEYLENGTH] = {
    0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07,
    0x08, 0x09, 0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f
};

// 函数声明
int add_zero_padding(unsigned char *data, int data_len, int block_size);
int remove_zero_padding(unsigned char *data, int data_len);
void print_hex(const char* label, const unsigned char* buf, size_t len);

4.2 ZeroPadding的核心实现

填充逻辑是正确实现的关键，需要仔细处理边界条件。

/**
 * @brief 为数据添加ZeroPadding
 * @param data 指向原始数据的指针的指针。函数内部可能会重新分配内存。
 * @param data_len 原始数据的长度。
 * @param block_size 块大小（对于AES是16）。
 * @return 返回填充后的新数据长度，失败返回-1。
 */
int add_zero_padding(unsigned char **data, int data_len, int block_size) {
    if (!data || !*data || block_size <= 0) {
        return -1;
    }

    // 计算需要填充的字节数
    int pad_len = block_size - (data_len % block_size);
    // 如果原始长度正好是块大小的倍数，则需要填充一整块
    if (pad_len == 0) {
        pad_len = block_size;
    }

    int padded_len = data_len + pad_len;
    // 重新分配内存以容纳填充字节
    unsigned char *new_data = (unsigned char *)realloc(*data, padded_len);
    if (!new_data) {
        return -1; // 内存分配失败
    }
    *data = new_data;

    // 填充0x00
    memset(*data + data_len, 0x00, pad_len);
    return padded_len;
}

/**
 * @brief 移除ZeroPadding
 * @param data 解密后的数据（包含填充）。
 * @param data_len 解密后数据的长度（应是块大小的整数倍）。
 * @return 移除填充后的实际数据长度，失败返回-1。
 */
int remove_zero_padding(unsigned char *data, int data_len) {
    if (!data || data_len <= 0 || (data_len % AES_BLOCK_SIZE) != 0) {
        return -1; // 无效输入或长度不是块大小的倍数
    }

    // 从末尾向前找到第一个非零字节
    int i = data_len - 1;
    while (i >= 0 && data[i] == 0x00) {
        i--;
    }
    // 实际数据长度为第一个非零字节的索引 + 1
    int actual_len = i + 1;

    // 重要：这里存在歧义！如果原始数据末尾就是0x00，会被误删。
    // 更健壮的做法是存储原始长度，或使用PKCS#7填充。
    return actual_len;
}

实操心得 ： add_zero_padding 函数接收 unsigned char **data （二级指针）是为了能在函数内部调用 realloc 并更新调用者手中的指针。这是C语言中动态修改指针的常见技巧。如果直接传递一级指针，修改的只是函数内的副本，调用者的指针不会改变，可能导致内存泄漏或访问错误。

4.3 AES-ECB加密解密的完整流程

现在，我们将填充、加密、解密串联起来。

/**
 * @brief 使用AES-128-ECB加密数据
 * @param plaintext 明文数据指针的指针。
 * @param plaintext_len 明文长度。
 * @param ciphertext 用于存放密文的缓冲区指针的指针。
 * @return 密文长度，失败返回-1。
 */
int aes_ecb_encrypt(unsigned char **plaintext, int plaintext_len,
                    unsigned char **ciphertext) {
    AES_KEY encrypt_key;
    // 设置加密密钥
    if (AES_set_encrypt_key(aes_key, 128, &encrypt_key) < 0) {
        fprintf(stderr, "Failed to set encryption key.\n");
        return -1;
    }

    // 1. 添加ZeroPadding
    int padded_len = add_zero_padding(plaintext, plaintext_len, AES_BLOCK_SIZE);
    if (padded_len < 0) {
        fprintf(stderr, "Padding failed.\n");
        return -1;
    }

    // 2. 分配密文缓冲区（长度等于填充后的明文长度）
    *ciphertext = (unsigned char *)malloc(padded_len);
    if (!*ciphertext) {
        fprintf(stderr, "Failed to allocate memory for ciphertext.\n");
        return -1;
    }

    // 3. 逐块进行ECB加密
    for (int i = 0; i < padded_len; i += AES_BLOCK_SIZE) {
        AES_ecb_encrypt(*plaintext + i, *ciphertext + i, &encrypt_key, AES_ENCRYPT);
    }

    return padded_len; // 返回密文长度
}

/**
 * @brief 使用AES-128-ECB解密数据
 * @param ciphertext 密文数据。
 * @param ciphertext_len 密文长度（必须是AES_BLOCK_SIZE的倍数）。
 * @param decryptedtext 用于存放解密后数据的缓冲区指针的指针。
 * @return 解密后（移除填充前）的数据长度，失败返回-1。
 */
int aes_ecb_decrypt(const unsigned char *ciphertext, int ciphertext_len,
                    unsigned char **decryptedtext) {
    if (ciphertext_len % AES_BLOCK_SIZE != 0) {
        fprintf(stderr, "Ciphertext length must be a multiple of block size.\n");
        return -1;
    }

    AES_KEY decrypt_key;
    // 设置解密密钥
    if (AES_set_decrypt_key(aes_key, 128, &decrypt_key) < 0) {
        fprintf(stderr, "Failed to set decryption key.\n");
        return -1;
    }

    // 1. 分配解密缓冲区
    *decryptedtext = (unsigned char *)malloc(ciphertext_len);
    if (!*decryptedtext) {
        fprintf(stderr, "Failed to allocate memory for decrypted text.\n");
        return -1;
    }

    // 2. 逐块进行ECB解密
    for (int i = 0; i < ciphertext_len; i += AES_BLOCK_SIZE) {
        AES_ecb_encrypt(ciphertext + i, *decryptedtext + i, &decrypt_key, AES_DECRYPT);
    }

    // 3. 移除ZeroPadding，并返回实际数据长度
    int actual_len = remove_zero_padding(*decryptedtext, ciphertext_len);
    if (actual_len < 0) {
        fprintf(stderr, "Remove padding failed.\n");
        free(*decryptedtext);
        *decryptedtext = NULL;
        return -1;
    }
    return actual_len;
}

// 辅助函数：打印十六进制数据
void print_hex(const char* label, const unsigned char* buf, size_t len) {
    printf("%s: ", label);
    for (size_t i = 0; i < len; ++i) {
        printf("%02x", buf[i]);
    }
    printf("\n");
}

注意事项 ： AES_ecb_encrypt 函数既用于加密也用于解密，区别在于传入的 AES_KEY 是用 AES_set_encrypt_key 还是 AES_set_decrypt_key 初始化的。这是OpenSSL低级API的一个设计。

4.4 主函数演示与测试

最后，我们编写主函数来测试整个流程。

int main() {
    // 原始明文
    char original_text[] = "This is a test message for AES-ECB-ZeroPadding.";
    int original_len = strlen(original_text);

    printf("Original Text: \"%s\" (Length: %d)\n", original_text, original_len);

    // 准备明文缓冲区（需要动态分配，因为填充函数会realloc）
    unsigned char *plaintext = (unsigned char *)malloc(original_len);
    if (!plaintext) return -1;
    memcpy(plaintext, original_text, original_len);

    unsigned char *ciphertext = NULL;
    unsigned char *decryptedtext = NULL;

    // 加密
    int ciphertext_len = aes_ecb_encrypt(&plaintext, original_len, &ciphertext);
    if (ciphertext_len > 0 && ciphertext) {
        print_hex("Ciphertext", ciphertext, ciphertext_len);
    } else {
        fprintf(stderr, "Encryption failed.\n");
        goto cleanup;
    }

    // 解密
    int decrypted_len = aes_ecb_decrypt(ciphertext, ciphertext_len, &decryptedtext);
    if (decrypted_len > 0 && decryptedtext) {
        // 添加字符串终止符以便打印
        decryptedtext[decrypted_len] = '\0';
        printf("Decrypted Text: \"%s\" (Length: %d)\n", decryptedtext, decrypted_len);
    } else {
        fprintf(stderr, "Decryption failed.\n");
        goto cleanup;
    }

    // 验证
    if (decrypted_len == original_len && memcmp(original_text, decryptedtext, original_len) == 0) {
        printf("\nSUCCESS: Decrypted text matches original!\n");
    } else {
        printf("\nFAILURE: Decrypted text does NOT match original.\n");
    }

cleanup:
    // 释放内存
    free(plaintext);
    free(ciphertext);
    free(decryptedtext);
    return 0;
}

编译与运行 ：

# 假设文件名为 aes_ecb_zeropadding.c
gcc -o aes_demo aes_ecb_zeropadding.c -lssl -lcrypto
./aes_demo

运行后，你会看到明文的十六进制密文，以及成功解密回原文的提示。你可以尝试修改 original_text ，特别是让它的末尾包含 \0 字符（如 "Hello\x00World" ），来观察ZeroPadding的歧义问题如何导致解密后数据丢失。

5. 安全升级：从ECB+ZeroPadding迁移到更佳实践

理解了旧组合的原理和局限后，在新项目或重构旧项目时，我们应该如何选择？OpenSSL的EVP高级API提供了更安全、更便捷的解决方案。

5.1 推荐替代方案：CBC模式 + PKCS#7填充

对于大多数需要保密性的通用场景，AES-CBC模式配合PKCS#7填充是经典且广泛支持的选择。

• CBC模式 ：引入了初始化向量（IV），使得每个块的加密都依赖于前一个块，消除了ECB的模式重复问题。
• PKCS#7填充 ：标准填充方式，填充的每个字节的值等于填充长度，解密时能明确无误地移除填充。

5.2 使用OpenSSL EVP API实现AES-256-CBC

以下是一个使用EVP API的示例，它更安全，代码也更简洁。

#include <stdio.h>
#include <string.h>
#include <openssl/evp.h>
#include <openssl/rand.h>

#define AES_256_KEY_LENGTH 32 // 256位密钥
#define AES_BLOCK_SIZE 16
#define IV_LENGTH 16 // CBC模式需要IV，长度同块大小

int aes_cbc_encrypt(const unsigned char *plaintext, int plaintext_len,
                    const unsigned char *key, const unsigned char *iv,
                    unsigned char *ciphertext) {
    EVP_CIPHER_CTX *ctx = EVP_CIPHER_CTX_new();
    if (!ctx) return -1;

    int len = 0;
    int ciphertext_len = 0;

    // 初始化加密操作
    if (1 != EVP_EncryptInit_ex(ctx, EVP_aes_256_cbc(), NULL, key, iv)) {
        EVP_CIPHER_CTX_free(ctx);
        return -1;
    }

    // 提供明文，获取部分密文
    if (1 != EVP_EncryptUpdate(ctx, ciphertext, &len, plaintext, plaintext_len)) {
        EVP_CIPHER_CTX_free(ctx);
        return -1;
    }
    ciphertext_len = len;

    // 完成加密，处理最后的填充块
    if (1 != EVP_EncryptFinal_ex(ctx, ciphertext + len, &len)) {
        EVP_CIPHER_CTX_free(ctx);
        return -1;
    }
    ciphertext_len += len;

    EVP_CIPHER_CTX_free(ctx);
    return ciphertext_len;
}

int aes_cbc_decrypt(const unsigned char *ciphertext, int ciphertext_len,
                    const unsigned char *key, const unsigned char *iv,
                    unsigned char *plaintext) {
    EVP_CIPHER_CTX *ctx = EVP_CIPHER_CTX_new();
    if (!ctx) return -1;

    int len = 0;
    int plaintext_len = 0;

    // 初始化解密操作
    if (1 != EVP_DecryptInit_ex(ctx, EVP_aes_256_cbc(), NULL, key, iv)) {
        EVP_CIPHER_CTX_free(ctx);
        return -1;
    }

    // 提供密文，获取部分明文
    if (1 != EVP_DecryptUpdate(ctx, plaintext, &len, ciphertext, ciphertext_len)) {
        EVP_CIPHER_CTX_free(ctx);
        return -1;
    }
    plaintext_len = len;

    // 完成解密，移除填充
    if (1 != EVP_DecryptFinal_ex(ctx, plaintext + len, &len)) {
        EVP_CIPHER_CTX_free(ctx);
        return -1;
    }
    plaintext_len += len;

    EVP_CIPHER_CTX_free(ctx);
    return plaintext_len;
}

int main() {
    unsigned char key[AES_256_KEY_LENGTH];
    unsigned char iv[IV_LENGTH];
    // 在实际应用中，密钥和IV必须通过安全的随机数生成器产生！
    // 这里仅为演示，使用固定值。
    memset(key, 0xAA, AES_256_KEY_LENGTH);
    memset(iv, 0xBB, IV_LENGTH);

    char original_text[] = "This is a secure message using AES-CBC.";
    int original_len = strlen(original_text);

    // 计算缓冲区大小：明文长度 + 一个块（用于PKCS#7填充）
    unsigned char ciphertext[original_len + AES_BLOCK_SIZE];
    unsigned char decryptedtext[original_len + AES_BLOCK_SIZE];

    int ciphertext_len = aes_cbc_encrypt((unsigned char*)original_text, original_len, key, iv, ciphertext);
    if (ciphertext_len > 0) {
        printf("CBC Encryption successful. Ciphertext length: %d\n", ciphertext_len);
    }

    int decrypted_len = aes_cbc_decrypt(ciphertext, ciphertext_len, key, iv, decryptedtext);
    if (decrypted_len > 0) {
        decryptedtext[decrypted_len] = '\0';
        printf("CBC Decryption successful. Decrypted text: \"%s\"\n", decryptedtext);
    }

    return 0;
}

EVP API的优势 ：

1. 接口统一 ：加密和解密使用对称的 EVP_Encrypt* 和 EVP_Decrypt* 系列函数。
2. 自动处理填充 ：默认使用PKCS#7填充，无需手动管理。
3. 更安全 ：支持多种模式和认证加密（如GCM），是OpenSSL推荐的使用方式。
4. 未来兼容性好 ：代码更容易迁移到新的算法或模式。

6. 常见问题与排查技巧实录

在实际使用和改造旧代码的过程中，我遇到过不少典型问题。这里总结一份速查表。

踩坑心得 ：在处理加密时， “字节意识” 至关重要。不要想当然地认为字符串就是数据。在C语言中，字符串以 \0 结尾，但这个 \0 在加密时是否算作数据的一部分？这必须明确。我的习惯是，对于文本数据，加密函数接收 unsigned char* 和明确的 length 参数，完全由调用者控制哪些字节需要加密。这能避免很多因编码和终止符引起的诡异问题。

7. 总结与决策指南

回顾开篇的问题，ECB+ZeroPadding在OpenSSL中常见，是历史、简单性与特定场景需求交织的结果。它像编程世界里的“汇编语言”——在高级语言（EVP API）普及的今天，直接使用它的情况变少了，但在需要极致控制、深度调试或维护历史遗产时，你依然需要理解它。

那么，如何决策？

• 绝对不要使用ECB+ZeroPadding的场景 ：

  • 加密任何有语义的、可能包含重复模式的数据（如文本、图片、结构化数据）。
  • 新的、涉及网络传输或长期存储的保密性系统。
  • 你对加密安全没有足够深入的了解。

• 可以谨慎考虑ECB+ZeroPadding的场景 ：

  • 兼容性需求 ：必须与一个使用该方案的旧系统或旧数据格式交互。
  • 资源极端受限 ：在ROM/KB级别的MCU上，每一字节和每一周期都至关重要，且威胁模型允许。
  • 教学与调试 ：用于向初学者演示AES块加密的基本原理，或调试加密算法的中间状态。
  • 加密高熵数据 ：加密的对象本身已经是密码学安全的随机数。

对于绝大多数现代应用，请直接使用OpenSSL的EVP高级API，并选择AES-GCM（认证加密）或AES-CBC with HMAC（加密后认证）模式。让专业的密码学库去处理模式、填充和认证这些复杂问题，把精力集中在密钥管理和系统架构上，这才是更安全、更高效的做法。理解旧技术是为了更好地驾驭新技术，以及妥善处理那些无法回避的“历史包袱”。