先確認：通訊的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和外部傳送基礎，郵件服務方也會留下副本。 也請確認收件箱和關聯物件的保護、共享設定。
相關報道
