Joplin 端到端加密E2EE数据格式深度解析——从同步快照密文看 JED 加密结构与元数据保护【免费下载链接】joplinJoplin - the privacy-focused note taking app with sync capabilities for Windows, macOS, Linux, Android and iOS.项目地址: https://gitcode.com/GitHub_Trending/jo/joplinJoplin 以隐私优先为核心设计其端到端加密E2EE机制让笔记、标签、资源等所有数据在离开设备前即完成加密同步服务器只能看到密文。本文以仓库内 app-cli 测试套件中的一份真实加密同步快照为解剖样本逐字段拆解 Joplin 的密文存储格式JED 头、AES-CCM 参数、PBKDF2 密钥派生、主密钥管理与解密工作流并对照源码给出可验证的底层原理帮助你完整理解 Joplin E2EE 的实现细节也为自研加密同步系统或审计 Joplin 数据安全提供可直接引用的参考。一、快照文件在 Joplin 测试体系中的定位本文分析的样本位于 packages/app-cli/tests/support/syncTargetSnapshots/3/e2ee/c9e46ce958bb4bd5a3d0cfb65855d9d2.md。从目录结构看syncTargetSnapshots下按1/、2/、3/三个版本号划分每个版本内又有e2ee/加密场景与normal/未加密场景两个子目录——这意味着 Joplin 通过跨版本快照 加密/非加密双路径的组合来回归验证同步目标对历史数据格式的兼容性。每个快照目录都配套一份 info.json记录该快照场景的同步配置与主密钥状态。本样本对应场景的关键状态为{ version: 3, e2ee: { value: true, updatedTime: 1628355817270 }, activeMasterKeyId: { value: 1f3b6b71948c4f5d909d1af6588c78bb, updatedTime: 1628355817333 }, masterKeys: [{ id: 1f3b6b71948c4f5d909d1af6588c78bb, encryption_method: 4, ... }] }也就是说这是一份E2EE 已开启、主密钥已建立的同步场景快照。同一目录下的 00dceec04659436196bae6b56eea10ad.md笔记与 07cd0925745b4441b898288f000c93d8.md标签则是与本样本关联的加密笔记与标签条目三者共同构成一组完整的加密关联数据。二、加密条目的逐字段拆解该快照文件正文即为一个加密同步条目的完整序列化结果。先看除密文外的元数据字段字段值说明idc9e46ce958bb4bd5a3d0cfb65855d9d2条目自身 IDnote_id00dceec04659436196bae6b56eea10ad关联笔记 IDtag_id07cd0925745b4441b898288f000c93d8关联标签 IDcreated_time/updated_time空 /2021-08-07T17:03:37.269Z创建与更新时间user_created_time/user_updated_time空用户侧时间戳encryption_cipher_textJED010000...加密后的内容密文见下一节encryption_applied1已应用加密的标记is_shared空共享状态type_6条目类型编号结合note_id与tag_id两个字段可以推断type_为 6 对应的是笔记与标签的关联项NoteTag即某笔记被打上某标签这条关系记录本身也被端到端加密。这体现了 Joplin E2EE 的一个重要设计不仅正文加密所有关联关系与元数据同样进入密文同步端无法从字段结构中反推笔记之间的标签关系。在 packages/lib/services/database/types.ts 中可以看到数据库模型统一以type_字段区分条目类型而 packages/lib/services/e2ee/EncryptionService.ts 的itemIsEncrypted正是通过检查item.encryption_applied isValidHeaderIdentifier(item.encryption_cipher_text)来判断条目是否已加密——加密标记与密文格式校验缺一不可。三、JED 密文格式头标识、长度与元数据载荷encryption_cipher_text的值是本文的核心其完整结构为JED01000022051f3b6b71948c4f5d909d1af6588c78bb0002d8{...base64 JSON...}可以切分为三段JED010000格式标识符。JED是 Joplin Encryption Data 的缩写010000为版本号。在 EncryptionService.ts 中isValidHeaderIdentifier负责校验该前缀任何不符合标识规则的密文都会被判定为实际未加密或非法数据对应Invalid encryption identifier异常。2205紧随标识符的十六进制数表示其后 JSON 元数据部分的字节长度0x2205 8709字节。源码 decodeHeaderSource_ 在读取标识符后会先解析这个长度字段再按该长度截取并解码元数据块。0002d8之后的 base64 JSON即实际加密参数与密文载荷见下节源码 decodeHeaderBytes_ 负责将其还原为结构化对象而 encodeHeader_ 负责在加密时按相同格式反向组装。之所以把加密参数 密文以自描述方式嵌入头部是为了让任何持有密钥的客户端都能独立解密每条数据自带盐、迭代次数、IV 等参数无需依赖外部配置这在多端同步场景下是保证互操作性的关键设计。四、AES-CCM 与 PBKDF2加密参数逐一解读剥离头标识与长度字段后密文 JSON 的明文结构如下基于样本解码{ iv: Ks7In3VNukwOfMigv5aGg, v: 1, iter: 101, ks: 128, ts: 64, mode: ccm, adata: , cipher: aes, salt: tVgmTCWSasM, ct: 5PCqJZzapvNh8PwCONuOoEFRSdY0RKHBCZrgEd5rsBNCDHyW9H9GL7s/... }各参数含义如下参数样本值含义ivbase6416 字节初始化向量AES-CCM 每次加密使用随机 IVv1元数据结构版本iter101PBKDF2 密钥派生迭代次数ks128密钥长度bit本条目为 128 位ts64CCM 认证标签长度bit即 8 字节modeccm加密模式Joplin 使用 AES-CCM带认证加密adata空字符串关联数据Associated Data可绑定上下文防止密文替换cipheraes底层加密算法saltbase64PBKDF2 随机盐ctbase64密文含认证标签这套参数组合意味着Joplin 采用AES-CCM 认证加密同时保证机密性与完整性密钥由PBKDF2从主密钥派生盐与迭代次数逐条目随机/独立记录。iter数值越小单条派生越快而主密钥本身的保护则使用更强的参数见下节。在 EncryptionService.ts 中decodeHeaderString(cipherText)正是从类似本样本的字符串中还原出上述全部参数后才执行后续的密钥派生与解密。五、主密钥与密钥层级从 info.json 看密钥管理配套的 info.json 给出了主密钥的完整形态。activeMasterKeyId指向当前激活的主密钥1f3b6b71948c4f5d909d1af6588c78bb而masterKeys数组中该密钥的content同样是密文其内嵌参数为{ iv: ..., v: 1, iter: 10000, ks: 256, ts: 64, mode: ccm, adata: , cipher: aes, salt: ..., ct: ... }对比可见两个关键差异iter10000 vs 101主密钥本体使用 10000 次 PBKDF2 迭代、256 位密钥保护强度远高于数据条目条目级密钥只需低迭代快速派生用于加解密高频读写的内容。encryption_method: 4显式标记主密钥的加密方案版本解密端据此选择对应的派生与解密算法。这构成了 Joplin E2EE 的典型两层密钥结构用户口令/主密钥密码 → 保护主密钥高迭代派生→ 主密钥 → 派生各条目的内容密钥低迭代、带随机盐与 IV。加密条目中记录的masterKeyId样本中为1f3b6b71948c4f5d909d1af6588c78bb与info.json的activeMasterKeyId完全一致正是把条目与具体主密钥绑定起来的纽带。六、解密工作流与源码对应关系围绕encryption_cipher_textJoplin 的加解密链路在源码中有多处落点与本文样本一一对应加密判定EncryptionService.ts 的itemIsEncrypted校验encryption_applied与 JED 头标识决定条目是否需要解密。头部编解码encodeHeader_ 组装JED010000 长度 JSONdecodeHeaderString / decodeHeaderSource_ 反向解析与样本密文的第三段格式完全吻合。后台解密服务DecryptionWorker.ts 与配套的 DecryptionWorker.test.ts 负责在同步后批量解密加密条目。冲突处理与内存解密loadConflictData.ts、decryptNoteInMemory.ts 表明冲突数据在合并前也需先解密可见 E2EE 贯穿同步、冲突、搜索等全部数据通路。测试验证EncryptionService.test.ts 中通过decodeHeaderString(cipherText)验证头部解析并在 L312 断言解密后的条目携带encryption_cipher_text字段——与本文样本字段结构互为印证。七、快照的工程价值回归测试与格式兼容这份快照文件本身就是 Joplin 工程体系的一部分syncTargetSnapshots目录被用于同步目标的回归快照测试。其价值体现在格式冻结将真实加密条目固化为测试数据任何对加密格式、序列化方式或同步处理的改动都必须保证新旧快照仍能按预期解析与解密防止改一个字段破坏历史数据。跨版本兼容1/、2/、3/三套快照分别代表不同历史阶段的格式e2ee/与normal/双路径则覆盖加密/未加密两种状态确保升级后的代码仍能读写旧版本数据。可读可审计快照以 Markdown 形式明文保存密文与字段便于人工审查加密参数是否合理、字段是否遗漏也为外部研究者提供了无需运行客户端即可研究 E2EE 格式的入口。对于希望深入理解或二次实现 Joplin E2EE 的开发者建议按以下路径阅读仓库加密/解密核心packages/lib/services/e2ee/EncryptionService.ts解密调度packages/lib/services/DecryptionWorker.ts条目类型定义packages/lib/services/database/types.ts加密快照全集packages/app-cli/tests/support/syncTargetSnapshots/3/e2ee/结语通过解剖这份type_ 6的加密快照我们完整还原了 Joplin E2EE 的核心数据格式JED010000头标识 十六进制长度 自描述 JSON 加密参数 密文的四段式结构AES-CCM 认证加密与 PBKDF2 密钥派生的参数体系以及主密钥高迭代保护、条目密钥低迭代派生的两层密钥设计。这些设计共同保证了即使同步服务器完全暴露攻击者也无法还原笔记内容乃至笔记与标签的关联关系。快照文件作为回归测试资产则为这一格式的长期稳定与跨版本兼容提供了工程保障——理解这一份密文也就理解了 Joplin 隐私承诺的技术根基。【免费下载链接】joplinJoplin - the privacy-focused note taking app with sync capabilities for Windows, macOS, Linux, Android and iOS.项目地址: https://gitcode.com/GitHub_Trending/jo/joplin创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
