先确认：通信的TLS、终端和服务器的加密保存、E2EE保护的场景不同。 即使同步是E2EE，终端的本地文件和导出的PDF也不一定会持续相同的加密。
最终确认: 。 笔者是SimpleMemo的开发者。 其他公司的产品比较了官方资料，并不是对各个应用程序进行入侵测试和独立安全审计的结果。
TLS・保存时加密・E2EE有什么不同？
通信中：保护到连接目的地的路径
TLS保护应用程序和服务器等的通信路。 连接对象处理的正文，不是从连接对象那里隐藏的结构。 与服务搜索、发送HTTPS发送的备忘录不矛盾。
保存时：用谁的密钥加密哪个文件
终端内的数据库、同步服务器、备份是分开的副本。 即使服务器的磁盘被加密，只要服务管理密钥，在必要的处理时也可以解密。 也区分了终端整体的加密和应用程序对每个备忘录进行加密的机制。
E2EE：同步前不传递正文的解密密钥
在端到端加密中，在对应的终端端进行加密、解密。 但是，标题和时间等元数据、公开链接、向AI功能发送、解密后的导出需要另外确认。 即使应用程序有E2EE功能，也不一定在自己的笔记本上有效。
AES-GCM・AES-CBC・读取零知识
AES-GCM结合了加密和认证，生成用于篡改检测的认证标签。 AES-CBC是提供保密性的模式，仅凭这一点不进行篡改检测。 认证需要与MAC等其他机制适当结合。 仅凭CBC这个名字无法判断产品被破坏了。 NIST的GCM规格、包含CBC的加密模式规格。
“256”是钥匙长度，不说明谁会拿着钥匙和备份设置。 使用AES-GCM的E2EE也有AES-GCM只保护终端内的设计。
零知识是存储产品中“企业无法解密本文”设计的说明词。 不能保证加密方式的名字和所有数据都不会被收集。 因为也有将加密的密钥保存在服务器上的设计，所以不会仅仅判断“密钥在服务器上不存在”，而是确认可以解密的主体和目标数据。
10应用程序：在方式之前，比较范围和设置
可以横向滚动确认“条件”和“另外确认的副本”。 表在键盘上也可以横向移动。
| 应用程序 | 加密范围 | 激活・确认条件 | 另外确认的副本・权限 | 依据 |
|---|---|---|---|---|
| Standard Notes | 在终端端加密内容并同步。 公开规格是XChaCha20-Poly1305。 | 使用账户时，本地数据也会加密。 在没有账户的情况下使用时，需要另外设置密码等的保护。 | 导出的文件和复制到其他应用程序的文章确认保存目的地的条件。 | 加密范围 · 方式 |
| Obsidian Sync | 默认设置用E2EE加密远程Vault。 AES-256-GCM。 | 选择标准加密的远程Vault由Obsidian侧管理钥匙。 确认设置和加密密码。 | 本地Vault的Markdown文件不能被Obsidian本身加密。 终端的磁盘加密和备份是不同的。 | Sync的安全 |
| Notion | 通信是TLS 1.2以上，保存时是AES-256。 | 官方资料说明的是服务方的加密。 与只有使用者拥有解密密钥的笔记本整体的E2EE不同。 | 也确认了传递给公开页面、嘉宾、合作服务的权限。 仅靠加密并不限制公开范围。 | 安全方针 |
| Evernote | 通过TLS通信和Google管理密钥保存AES-256。 选择的文本中也有密码短语加密。 | 选择文本的公开方式是AES-128-CBC。 与将整个笔记、附件一次性E2EE化的功能不同。 | 加密范围之外的正文、标题、附件不作为相同的密码短语保护。 | 保存和通信 · 文本加密 |
| Apple备忘录 / Apple Notes | 通常的iCloud保护是通信、保存时的加密。 在高级数据保护（ADP）中，iCloud备忘录成为E2EE的对象。 | 确认ADP的有效状态和恢复手段。 为了在共享备忘录中维持ADP的E2EE，所有参与者都需要ADP。 | 部分元数据是标准保护。 导出的PDF和邮件附件是与原来的iCloud备忘录不同的副本。 | iCloud的保护范围 |
| Google Keep | 通信中和保存时加密。 为了提供搜索等功能而处理内容。 | 官方资料的保护，不能与只有使用者拥有钥匙的E2EE交换。 | 确认共享对象和Google账户的保护。 在广告中不使用内容的方针和不处理内容的设计是不同的。 | Keep的隐私和保护 |
| Bear | 用Bear Pro对个别笔记进行密码加密。 2.4以后的图片、PDF等附件也是对象。 | 在目标笔记中添加密码，同步终端的应用程序也更新。 与应用程序整体的锁不同。 | 标题显示在笔记一览表中。 iCloud的ADP也包括标题、标签等范围在内进行确认。 | 笔记本的加密 · 2.4的附加对应 · 同步范围 |
| 乔普林 | 激活的同步E2EE。 来自v3.2的新原生方式是AES-256-GCM。 | 在一台上激活加密，等待同步完成，使用其他终端设置密钥的官方程序。 | 本地数据不受这种同步加密的保护。 也确认了终端的磁盘加密。 | 设置步骤 · 新方式 · 终端内数据 |
| 第一天 | 4.2以后新制作的期刊默认为E2EE。 对象是文章和媒体。 | 旧的期刊单独确认状态。 现在的官方FAQ不能直接从标准加密切换，而是复制到新的E2EE日志。 | 也确认了钥匙的保管处。 iCloud Keychain是E2EE，但Day One独有的iCloud钥匙备份即使激活ADP也不会成为E2EE。 写出来的日记也是另外的复印件。 | E2EE的FAQ |
| SimpleMemo / Simple Memo | 终端内的Outbox・发送记录用CryptoKit的AES-GCM加密。 新密钥用256-bit保存在Keychain中。 | 邮件发送不是E2EE。 通过发送API・外部发送基础，在收件箱中留下副本。 | 终端内保护并不能保证邮件服务和合作的Obsidian Vault的保管方法。 | 技术说明 |
如果是在自己的收件箱里留下简短的备忘录的话，SimpleMemo也是选择。 请分别确认终端内的加密和发送邮件的保管、共享设置。
使用前，5点确认设置和副本
- 打开现有数据的设置。 不要只根据应用程序名称来判断，而是使用Vault、日志、共享笔记来确认加密是否有效。 新数据的默认值不一定也适用于旧数据。
- 确保恢复方法。 同步密码、加密密钥、恢复联系方式等，确认产品介绍的方法。 请避免在丢失钥匙的状态下删除终端进行尝试。
- 确认公开、共享、合作的范围。 向公开链接和外部服务发送与保存时加密是分开的。 工作信息与所属单位认可的保存地址、共享范围保持一致。
- 用虚拟的1件确认同步和附加。 内容不使用机密信息，确认是否在其他终端上打开、附件是否对、加密状态如何显示。 仅凭这一点并不能证明加密实施的安全性。
- 确认导出目的地和备份。 Markdown、PDF、邮件、下载文件夹的副本，可能会出现在原应用程序的E2EE之外。 转移确认结束前请不要删除原始数据。
SimpleMemo保护的范围和发送后留下的东西
SimpleMemo用AES-GCM对终端内的发送等待备忘录（Outbox）和发送记录进行加密。 在已公开的应用程序的通用密码器中，新制作的密钥用256-bit保存在Keychain中，用CryptoKit进行加密、解密。 这是保护终端内目标数据的实现。
不是邮件路径整体的E2EE。 从应用程序发送API到HTTPS，通过外部的邮件发送基础到达收件箱。“ 终端内的未发送备忘录被加密”并不是“在发送处理中不处理正文”“不通过外部服务器”的意思。
即使已经发送，Outbox的目标项目被排除在外，发送记录、接收邮件、连接目的地的笔记也不会消失。 文件的删除操作，也不称为存储介质的完全删除。 保存地址和保留期限可以在隐私政策的技术说明和数据通道中确认。
使用Obsidian保存时，与本地Vault同步、备份的保护也取决于自己的设置。 对于企业无法解密本文的用途，请先选择符合该条件的E2EE的保存地址和运用。
常见问题
AES-256的话是E2EE吗？
不。 AES-256表示密码和密钥长度。 是否是E2EE，取决于在哪里加密、解密，谁可以使用钥匙。 服务器管理密钥的AES-256保存和仅在用户的终端上解密的设计是不同的。
AES-GCM和AES-CBC有什么不同？
GCM结合了加密和认证。 CBC仅通过加密无法检测篡改，因此需要适当地组合认证机制。 不能仅凭方式名来排名应用程序整体的安全性。
E2EE的话终端内的文件也会加密吗？
不一定。 Obsidian Sync和Joplin的同步加密不会对终端内的本地文件和数据库进行同样的加密。 请另外确认终端的磁盘加密、应用程序的本地保护、备份。
Bear可以加密包含图像和PDF的笔记吗？
Bear 2.4以后可以用Bear Pro加密包含附件的个别笔记。 在目标笔记中添加密码，同步目的地的应用程序也更新到对应版。 标题显示和未加密的笔记需要另外确认。
Day One的旧期刊也自动变成了E2EE吗？
新的期刊默认为4.2以后的E2EE，但旧的需要单独确认。 目前的官方FAQ介绍了将条目复制到新的E2EE日志的方法，而不是直接切换标准加密的日志。
SimpleMemo发给自己的邮件是E2EE吗？
不。 Outbox和发送记录的终端内加密和邮件发送是分开的。 本文通过发送API和外部发送基础，邮件服务方也会留下副本。 也请确认收件箱和关联对象的保护、共享设置。
相关报道
