基于树莓派Pico的离线密码管理器：硬件加密与嵌入式安全实践

1. 项目概述：当密码保险箱遇上树莓派Pico

如果你和我一样，被各种网站、应用的密码搞得焦头烂额，最后不得不依赖某个云端密码管理器，心里却总有一丝对“把鸡蛋放在一个篮子里”的不安，那么这个项目——Midbar (Raspberry Pi Pico Version)，可能就是你在寻找的答案。简单来说，这是一个运行在售价仅几十元的树莓派Pico微控制器上的离线密码管理器。它不联网，完全由你掌控，将你的密码数据库加密后存储在一块小小的SD卡上，物理上隔绝了网络攻击的风险。

我第一次接触这个想法时，觉得非常酷。市面上成熟的密码管理器很多，但它们要么是云端服务，要么是运行在手机或电脑上的软件。而Midbar Pico版则走了另一条路：利用一块功耗极低、成本极低的硬件，打造一个纯粹的、离线的、可触摸的密码保险箱。你通过一块小屏幕和几个按键来操作它，所有的加密解密运算都在Pico这颗小小的双核ARM Cortex-M0+芯片上完成。这意味着，你的密码库从未离开过这块板子，安全性完全建立在物理隔离和加密算法之上。

这个项目非常适合那些对隐私和安全有极高要求的技术爱好者、极客，或者单纯想拥有一个完全由自己掌控的“数字钥匙串”的人。它不只是一个工具，更是一个有趣的学习项目，你能深入理解对称加密（如AES）、哈希算法、密钥派生等安全概念是如何在一个资源受限的嵌入式环境中实现的。接下来，我会带你从设计思路到代码实现，完整地拆解这个项目，分享我在移植和开发过程中踩过的坑和总结的经验。

2. 核心设计思路与架构解析

2.1 为什么选择树莓派Pico？

选择树莓派Pico作为硬件平台，是经过多方面权衡的结果，绝非偶然。首先，成本与可及性是首要因素。Pico的价格极其亲民，其强大的RP2040微控制器提供了双核132MHz ARM Cortex-M0+处理器、264KB的SRAM以及丰富的GPIO，性能足以应对AES加解密等计算任务。其次，低功耗与离线特性完美契合密码管理器的核心需求。一个离线设备从根本上杜绝了远程网络入侵的可能性，而Pico的低功耗特性使得它可以由电池长时间供电，甚至可以作为一个便携设备使用。最后，丰富的生态系统是关键。Pico支持MicroPython和C/C++ SDK，有成熟的SD卡、显示屏、按键等外设库，极大降低了开发门槛。

与在PC或手机上运行软件相比，硬件方案有本质区别。软件方案依赖操作系统环境，可能受到同一系统上其他恶意软件的威胁。而Midbar Pico版作为一个“固件”，从通电开始就运行唯一的应用程序，没有多任务、没有网络栈，攻击面被缩到最小。它的安全边界就是那块电路板本身。

2.2 系统整体架构设计

Midbar Pico版的架构可以清晰地分为四层，这种分层设计保证了模块化和可维护性。

硬件抽象层（HAL）：这是最底层，负责与Pico的硬件直接对话。包括初始化RP2040芯片、配置GPIO引脚、驱动SPI接口与SD卡通信、通过I2C或SPI驱动OLED/LCD屏幕、读取按键状态等。这一层的代码需要高度稳定和高效，因为所有上层操作都依赖于它。我选择了使用Pico的C/C++ SDK来编写这一部分，以获得对硬件最直接的控制和最佳性能。

外设驱动与存储层：建立在HAL之上，封装了具体外设的操作。例如，一个SDCard类提供了read_block,write_block,list_files等方法；一个Display类封装了绘制文本、矩形、刷新屏幕等操作；一个Keypad类负责扫描矩阵键盘或独立按键并返回键值。存储层是核心之一，它定义了密码数据库在SD卡上的存储格式。通常，我们会将整个加密后的数据库存储为一个单独的文件（如vault.dat），文件内部可能包含加密后的条目数据以及一些元数据（如版本号、加密算法标识、初始化向量IV等）。

核心逻辑与加密层：这是整个系统的大脑。它负责处理用户的业务流程：创建主密码、验证主密码、添加/编辑/删除密码条目、搜索条目等。同时，它集成了加密解密模块。当用户添加一个条目时，逻辑层会收集标题、用户名、密码、备注等信息，将其序列化为一个结构（如JSON或自定义二进制格式），然后调用加密模块，使用由主密码派生的密钥进行加密，最后将密文交给存储层写入SD卡。反之，读取时则先解密再反序列化。

用户界面层（UI）：这是用户直接交互的部分。在小小的屏幕上，我们需要实现菜单系统、文本输入、列表浏览、详情展示等功能。考虑到Pico有限的RAM和屏幕尺寸，UI设计必须极其精简。通常采用层级菜单：主菜单 -> 条目列表 -> 条目详情 -> 编辑界面。文本输入是一个挑战，通常通过方向键移动光标、旋转编码器选择字符或实现一个屏幕软键盘来解决。

这四层之间通过清晰的接口进行调用，下层为上层提供服务。例如，UI层调用逻辑层的add_entry函数，逻辑层则调用加密层的encrypt函数和存储层的write函数。这种设计使得未来替换加密算法（例如从AES-256-GCM换成ChaCha20-Poly1305）或显示驱动（从SSD1306 OLED换成ST7789 LCD）变得相对容易。

3. 关键技术实现细节与难点攻克

3.1 主密码处理与密钥派生

这是整个系统安全性的基石。绝对不能直接使用用户输入的主密码作为加密密钥。原因有二：一是密码长度和熵值可能不足；二是需要将密码固定为加密算法所需的密钥长度（如AES-256需要32字节）。

密钥派生函数（KDF）的选择：我们使用PBKDF2（Password-Based Key Derivation Function 2）算法。它的作用是通过一个伪随机函数（通常是HMAC-SHA256），将主密码和一个盐值（Salt）进行多次迭代哈希，最终输出一个指定长度的、高熵的密钥。迭代次数（例如10万次）大大增加了暴力破解的难度。即使两个用户使用了相同的弱密码，由于盐值不同，派生出的密钥也完全不同，防止了彩虹表攻击。

在Pico上实现PBKDF2需要注意性能。数万次的SHA256迭代对M0+内核来说是一个不小的负担，可能会导致每次解锁有几秒钟的延迟。这是一个必要的安全代价，但我们可以优化：一是使用RP2040的第二个核心（如果UI运行在Core0，可以将KDF计算放在Core1）；二是预先计算并存储一个加盐的密码哈希，但这种方式需要极其小心地设计，避免引入新的漏洞。我最终采用了单核阻塞式计算，并在屏幕上显示“正在解密…”的提示，让用户感知到这个安全过程。

盐值（Salt）的生成与存储：盐值必须是一个密码学安全的随机数，在用户首次设置主密码时生成，并和加密后的数据库一起存储。它不需要保密，但必须唯一。在Pico上，我们可以使用RP2040内置的硬件随机数生成器，或者结合ADC读取未连接的引脚噪声来获取熵源。生成的盐值会明文保存在数据库文件头部。

实操心得：千万不要为了追求解锁速度而随意减少PBKDF2的迭代次数。10万次是一个合理的起点。你可以通过一个简单的测试程序，在Pico上测算不同迭代次数所需的时间，在安全性和用户体验间找到平衡点。我最初设为5万次，后来还是提升到了10万次，解锁延迟约2.8秒，在可接受范围内。

3.2 数据库加密与存储格式设计

确定了密钥后，下一步是选择加密模式。AES-256是可靠的选择，但单纯使用AES-256-CBC（密码分组链接模式）还不够，因为它不提供完整性校验。攻击者可能篡改密文，导致解密出乱码，或者通过精心构造的篡改来窥探信息。

加密模式选择：我推荐使用AES-256-GCM（Galois/Counter Mode）模式。GCM模式同时提供了加密和认证（完整性校验）。它在加密过程中会生成一个认证标签（Authentication Tag），解密时会验证这个标签。如果密文在存储中被篡改，验证会失败，系统会拒绝解密，而不是输出错误数据。这为我们的数据库增加了一道重要的保护层。

存储格式设计：数据库文件需要有一个清晰的二进制格式。下面是一个我设计的简化版结构：

[文件头] - 魔数（4字节）：例如 ‘MIDB’，用于快速识别文件类型。 - 版本号（2字节）：用于未来格式升级兼容。 - 盐值（Salt）（16字节）：用于密钥派生的随机盐。 - 加密算法标识（1字节）：例如 0x01 代表 AES-256-GCM。 - 迭代次数（4字节）：PBKDF2的迭代次数，如100000。 - 预留空间（若干字节）：为未来扩展预留。 [数据区] - 初始化向量IV（12字节）：GCM模式需要的随机数，每次加密都应不同。 - 密文长度（4字节）：加密后的条目数据总长度。 - 密文（N字节）：所有密码条目序列化后，再经GCM加密的数据。 - 认证标签（16字节）：GCM算法生成的完整性校验标签。

当需要添加一个新条目时，系统需要：1. 从SD卡读取整个数据库文件；2. 验证主密码并解密数据区得到明文条目列表；3. 在内存中的列表里新增条目；4. 生成一个新的随机IV；5. 将整个列表重新序列化并加密；6. 将新的IV、密文和认证标签写回文件。这意味着，每次修改都意味着整个数据库的重写加密。对于SD卡来说，这通常是可接受的，因为密码数据库的体积一般很小（几十KB以内）。

注意：务必确保在写入新文件成功并验证后，再删除旧文件。避免在加密或写入过程中断电导致数据库损坏。一种策略是先将新数据库写入一个临时文件（如vault.dat.tmp），写入完成后进行简单的完整性校验（如读取并解密第一条记录），校验无误后再用rename操作原子性地替换旧文件。MicroPython或C SDK的文件操作通常支持这个功能。

3.3 用户交互与输入法实现

在仅有几个按键和一块128x64像素OLED屏的限制下，设计出可用的UI是一大挑战。

菜单导航：我采用了经典的层级式菜单。一个Menu类管理当前菜单项列表、选中索引和回调函数。方向键（上/下）移动高亮条，确认键（OK）进入子菜单或执行操作，取消键（Back）返回上级。状态机模型非常适合描述这种逻辑。

文本输入：这是最复杂的部分。方案有多种：

1. 旋转编码器+屏幕键盘：通过旋转编码器在屏幕显示的字母矩阵中移动光标，按下编码器选择字符。这是最直观但占用屏幕空间的方式。
2. 多按键循环：使用方向键和确认键。例如，左右键移动光标，上下键改变当前光标处的字符（在a-z, A-Z, 0-9, 特殊字符间循环）。这种方式节省屏幕，但输入效率较低。
3. 手机T9风格：如果配备了数字键盘（4x3），可以实现T9预测输入，但这对于英文和复杂密码不太友好。

我最终采用了方案2的增强版。屏幕底部显示当前输入的字符和光标。上下键快速切换字符集（小写、大写、数字、符号），左右键移动光标位置。为了提高效率，我增加了“长按”功能：长按上/下键可以快速连续切换字符。虽然仍不如实体键盘，但对于输入主密码和偶尔编辑条目信息来说，已经足够。

显示优化：由于屏幕小，信息展示要精炼。列表页面只显示条目的核心标题（可滚动）。详情页面分字段显示用户名、密码（默认隐藏，用***表示，按特定键显示）。使用不同的字体大小来区分重要性。

4. 完整构建步骤与代码剖析

4.1 硬件准备与连接

你需要以下硬件组件：

• 树莓派Pico（带焊接好的排针）：主控制器。
• Micro SD卡模块（SPI接口）：用于存储加密数据库。常见型号如Micro SD TF Card Reader SPI。
• OLED显示屏（I2C或SPI接口，128x64）：用于显示界面。SSD1306驱动的I2C接口屏最为常见，接线简单。
• 按键：至少需要4个（上、下、确认、返回）。可以使用独立按键，也可以使用一个摇杆模块（其本质是多个方向按键）。
• 面包板、杜邦线：用于连接。
• Micro SD卡（建议8GB或以下，格式化为FAT32）：存储介质。

接线示意图（以I2C OLED和独立按键为例）：

注意：Pico的3.3V输出引脚（3V3(OUT)）驱动能力有限（约300mA）。同时为屏幕和SD卡供电可能接近极限，尤其在SD卡写入时电流较大。如果出现不稳定情况（如屏幕闪烁、SD卡初始化失败），建议使用外部3.3V稳压电源为外设供电。同时，务必确保所有GND连接到一起。

4.2 软件开发环境搭建与核心库

我们使用C/C++ SDK进行开发，因为它能提供最佳的性能和对硬件的控制，这对于加密运算和响应速度至关重要。

1. 安装工具链：按照树莓派官方文档，在PC上安装arm-none-eabi-gcc交叉编译器和cmake。在Linux或macOS上通过包管理器安装即可，Windows上可以使用MSYS2或WSL。
2. 获取Pico SDK：从GitHub克隆pico-sdk及其依赖。
3. 创建项目：使用SDK提供的模板创建一个新项目。项目结构将包含CMakeLists.txt、pico_sdk_import.cmake以及你的源代码目录。
4. 添加必要的库：我们需要以下几个核心库：
   • 硬件库：pico_stdlib,hardware_spi,hardware_i2c，这些已包含在SDK中。
   • FAT文件系统库：使用fatfs库来操作SD卡。Pico的SDK示例中通常包含一个f_*封装的FatFs版本。
   • 加密库：这是一个关键选择。虽然可以自己实现AES，但更推荐使用经过充分测试的库。TinyCrypt（来自Zephyr项目）或mbed TLS（虽然稍大）都是不错的选择。我们需要从中提取AES-GCM和SHA256（用于PBKDF2的HMAC）的实现。这可能需要一些移植工作，主要是实现随机数生成器（mbedtls_hardware_poll）和内存操作函数。
   • 显示驱动：需要为你的OLED屏编写或移植一个驱动。通常基于hardware_i2c实现ssd1306的初始化、清屏、画点、刷新等函数。网上有很多开源实现可以参考。

4.3 核心模块代码剖析

下面我将分模块解释关键代码结构和逻辑。由于篇幅限制，这里展示的是伪代码和核心逻辑，实际开发需要填充大量细节。

主程序框架 (main.c)：

#include "pico/stdlib.h" #include "vault.h" #include "ui.h" #include "keypad.h" #include "storage.h" int main() { stdio_init_all(); // 初始化标准输入输出（用于调试） ui_init(); // 初始化显示屏 keypad_init(); // 初始化按键 storage_init(); // 初始化SD卡和文件系统 VaultState vault_state = VAULT_LOCKED; char master_key[32]; // 派生出的密钥 while (true) { switch(vault_state) { case VAULT_LOCKED: // 显示解锁界面 if (attempt_unlock(master_key)) { vault_state = VAULT_UNLOCKED; load_and_decrypt_database(master_key); } break; case VAULT_UNLOCKED: // 显示主菜单，并处理用户交互 handle_main_menu(); // 如果用户选择锁定或超时无操作 vault_state = VAULT_LOCKED; secure_wipe(master_key, sizeof(master_key)); // 安全擦除内存中的密钥 break; } sleep_ms(50); // 主循环延迟，降低CPU占用 } }

密钥派生与加密模块 (crypto.c)：

// 使用PBKDF2-HMAC-SHA256派生密钥 int derive_key_from_password(const char *password, const uint8_t *salt, int iterations, uint8_t *output_key) { // 1. 将密码转换为字节数组（考虑UTF-8？这里简单处理） // 2. 调用HMAC-SHA256的PRF函数，进行多次迭代 // 3. 将结果复制到output_key // 返回0成功，非零失败 } // 使用AES-256-GCM加密数据 int encrypt_data(const uint8_t *key, const uint8_t *plaintext, size_t pt_len, uint8_t *iv, uint8_t *ciphertext, uint8_t *tag) { // 1. 生成随机IV（使用硬件RNG或ADC熵源） // 2. 初始化GCM上下文，设置密钥和IV // 3. 调用AES-GCM加密函数 // 4. 获取认证标签 // 返回0成功，非零失败 } // 使用AES-256-GCM解密并验证数据 int decrypt_and_verify(const uint8_t *key, const uint8_t *iv, const uint8_t *ciphertext, size_t ct_len, const uint8_t *tag, uint8_t *plaintext) { // 1. 初始化GCM上下文，设置密钥和IV // 2. 调用AES-GCM解密函数 // 3. 验证认证标签是否匹配 // 如果验证失败，返回错误码，且plaintext内容应视为无效 // 返回0成功（验证通过），非零失败 }

存储与数据库模块 (storage.c)：

typedef struct { char title[32]; char username[64]; char password[128]; // 加密前，明文存储在此结构体中，需及时清除 char notes[256]; } db_entry_t; typedef struct { db_entry_t *entries; int count; int capacity; } database_t; int save_database_to_file(database_t *db, const uint8_t *master_key) { // 1. 序列化db->entries数组为一个大缓冲区（plaintext_buffer） // 2. 生成随机IV // 3. 调用encrypt_data，用master_key加密plaintext_buffer，得到ciphertext和tag // 4. 构建文件头（魔数、版本、盐、算法、迭代次数） // 5. 将文件头、IV、密文长度、密文、tag依次写入临时文件 // 6. 关闭文件，检查完整性（可选：重新打开并解密验证第一条记录） // 7. 如果成功，重命名临时文件为正式数据库文件 // 8. 安全擦除plaintext_buffer等内存中的敏感数据 } int load_database_from_file(database_t *db, const uint8_t *master_key) { // 1. 打开数据库文件，读取文件头，验证魔数和版本 // 2. 读取盐值（用于验证密码时再次派生密钥，或直接从参数传入已派生的key） // 3. 读取IV、密文长度、密文、tag // 4. 调用decrypt_and_verify进行解密验证 // 5. 如果成功，将解密后的缓冲区反序列化到db->entries数组中 // 6. 安全擦除解密过程中的临时缓冲区 }

用户界面模块 (ui.c 伪代码逻辑)：

void draw_unlock_screen() { oled_clear(); oled_draw_string(10, 10, "Midbar Vault Locked"); oled_draw_string(10, 30, "Enter Master Password:"); // 绘制密码输入框和星号掩码 oled_refresh(); } void handle_main_menu() { const char *menu_items[] = {"View Entries", "Add Entry", "Settings", "Lock"}; int selected = 0; while(1) { draw_menu("Main Menu", menu_items, 4, selected); key = get_keypress(); if (key == KEY_UP) selected = (selected - 1 + 4) % 4; if (key == KEY_DOWN) selected = (selected + 1) % 4; if (key == KEY_OK) { switch(selected) { case 0: browse_entries(); break; case 1: add_new_entry(); break; case 2: settings_menu(); break; case 3: return; // 退出循环，返回主函数锁定保险箱 } } if (key == KEY_BACK) { /* 可能无操作或也触发锁定 */ } } }

5. 实际开发中的挑战与解决方案

5.1 内存管理挑战

RP2040只有264KB的RAM，这要求我们必须精打细算。数据库条目、加解密缓冲区、UI渲染缓冲区都会占用大量内存。

动态内存 vs 静态内存：在嵌入式系统中，通常避免使用malloc/free，因为容易产生碎片且行为不可预测。我采用了静态分配和内存池的策略。例如，在database_t结构中，我使用一个静态大小的数组来存储条目指针（或条目本身），而不是动态链表。这限制了最大条目数，但保证了内存可控。我定义了MAX_ENTRIES为50或100，每个条目结构体大小约500字节，那么仅数据库在内存中就可能占用25KB-50KB。

加解密缓冲区：AES-GCM加密需要连续的明文和密文缓冲区。如果数据库序列化后的大小是10KB，那么就需要至少10KB的缓冲区。我们可以定义一个大小固定的全局缓冲区（例如16KB），并确保它足够大。同时，在加解密操作完成后，立即用memset或类似函数安全擦除这些缓冲区中的敏感数据。

栈空间：注意函数调用深度和局部变量大小，避免栈溢出。可以将大的缓冲区（如加解密缓冲区）定义为全局变量或静态变量，而非局部变量。

5.2 电源管理与数据安全

作为一个便携设备，突然断电是必须考虑的风险。如果在重写加密数据库文件时断电，可能导致数据库损坏甚至完全丢失。

写操作原子性：如前所述，使用“写临时文件 -> 验证 -> 重命名覆盖”的策略。FatFs库的f_rename函数在大多数情况下是原子的。这确保了在任何时刻，磁盘上要么是完整的旧文件，要么是完整的新文件。

定期备份：可以实现一个简单的备份功能，例如在每次成功修改后，将数据库文件额外复制一份为vault.backup.dat。或者，用户可以手动通过某个菜单选项导出加密的数据库文件到SD卡另一个位置。

自动锁定与睡眠：为了省电和安全，可以设置无操作自动锁定。在handle_main_menu等函数中记录最后一次按键时间，如果超过设定时间（如5分钟），则自动清除主密钥并返回锁定状态。更进一步，可以让Pico进入深度睡眠（Dormant模式），仅通过按键唤醒，这将极大降低功耗。

5.3 用户体验优化点

密码显示切换：在查看密码条目详情时，密码默认显示为******。可以设计为长按确认键切换明文/密文显示，松开后自动恢复隐藏，防止旁人窥视。

搜索功能：当条目较多时，滚动查找效率低。可以增加一个简单的搜索功能：进入条目列表后，按某个键（如左键）进入搜索模式，然后通过文本输入输入关键字，实时过滤列表。

导入/导出：虽然离线是核心，但初始数据导入和灾难恢复时的导出功能很重要。可以通过串口（UART）实现一个简单的命令行协议，与PC端工具通信，传输加密后的数据库文件。这样用户可以在PC上先用脚本生成一个初始数据库，再导入到Pico中。务必注意，传输的始终是加密后的数据，主密码绝不在任何通信中出现。

按键防抖与长按识别：机械按键存在抖动，需要在驱动层进行软件防抖（例如检测到电平变化后延时20ms再确认）。同时，为了实现长按加速字符输入或快速滚动，需要计时器来区分短按和长按。

6. 测试、调试与安全审计建议

6.1 分模块测试

在集成之前，务必对每个模块进行独立测试。

• SD卡与文件系统：编写测试程序，循环创建、写入、读取、删除文件，验证稳定性和性能。
• 加密模块：在PC上使用OpenSSL或Python生成测试向量（已知密钥、IV、明文、密文、tag），然后在Pico上运行加密解密函数，对比结果是否完全一致。这是验证加密算法实现正确性的黄金标准。
• 用户界面：可以暂时屏蔽加密和存储逻辑，用模拟数据测试菜单导航、文本输入、列表滚动等是否流畅。
• 按键驱动：测试每个按键的响应，以及防抖和长按逻辑。

6.2 集成测试与边界情况

• 首次运行与初始化：在没有数据库文件的情况下，系统应引导用户创建主密码并初始化一个新数据库。
• 错误密码处理：输入错误密码时，应提示错误并清空输入框，不应有任何关于“密码接近正确”或数据库是否存在的提示（防止侧信道攻击）。验证失败后应有一个短暂的延迟（如1秒），以减缓暴力破解尝试。
• 存储空间不足：在写入数据库前，检查SD卡剩余空间。如果不足，应明确提示用户，并中止操作，确保不会写入不完整的文件。
• 文件损坏：尝试读取数据库时，如果文件头魔数不对、版本不支持、或解密验证失败，应提示“数据库损坏”，并询问是否从备份恢复（如果存在）。

6.3 安全自查清单

在项目完成后，请对照以下清单进行自我审计：

• [ ]密钥生命周期管理：主密码只在输入时以明文形式短暂存在，派生出的密钥在使用后是否立即从内存中清除？在锁定状态，内存中是否绝对没有残留的密钥或明文密码？
• [ ]内存清理：是否在所有敏感数据（密码、密钥、明文条目）使用后，立即用memset或类似函数覆盖？注意编译器优化可能会将“无后续读取”的memset调用优化掉，需要使用volatile指针或专用函数（如mbedtls_platform_zeroize）。
• [ ]随机数质量：用于盐值和IV的随机数是否来自可靠的熵源（如RP2040的硬件RNG）？在系统首次启动时，熵是否足够？
• [ ]错误信息：所有错误信息是否都是模糊的、通用的（如“操作失败”），而不会泄露具体细节（如“HMAC验证失败”，这会让攻击者知道文件格式）？
• [ ]物理安全：虽然软件层面安全，但设备丢失的风险呢？可以考虑增加一个“自毁”功能，在连续多次输入错误密码后，自动擦除SD卡上的数据库文件或加密密钥（盐值）。此功能需谨慎设计，并明确告知用户。

开发这样一个项目，最大的收获不仅仅是做出了一个可用的密码管理器，更是对嵌入式系统安全、密码学应用和资源受限编程有了深刻的理解。从担心内存溢出，到精心设计每一个缓冲区；从调试SPI通信失败，到看到屏幕上成功显示第一个字符；从害怕加密算法实现有误，到成功通过所有测试向量——这个过程充满了挑战，但最终的成就感也是巨大的。这个小小的Pico板子，承载的不仅是一串串密码，更是你对数字生活主权的一次坚实实践。